`unpack-pbp`: unvalidated PBP offsets → silent file clobbering and attacker-sized write; `psp-prxgen`: unbounded `strcpy` of section name
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start with tools/unpack-pbp.c and tools/psp-prxgen.c, then inspect the header and section definitions in tools/elftypes.h. Check how the tools read PBP offsets and ELF section names, and add validation for malformed input as described in the issue. Done means invalid offsets and overlong or unterminated section names are rejected safely; verify with the supplied reproductions or create equivalent malformed inputs.
由索引模型根据 Issue 内容生成。
描述
unpack-pbp: unvalidated offsets → attacker-sized output write (up to ~2 GiB per section); psp-prxgen: unbounded strcpy of section name
Two separate input-validation bugs in tools/. I'm reporting them privately rather than
posting full exploit detail: this repo has no SECURITY.md and "Private vulnerability
reporting" is disabled. Could you either enable it or tell me a preferred contact?
Both tools consume untrusted third-party artifacts (PBP / ELF), so the impact lands in
whatever developer machine or packaging pipeline processes such a file.
1. tools/unpack-pbp.c — header offsets are never validated (CWE-400 / CWE-1284)
if (loop0 == 7) size = total_size - header.offset[loop0]; /* :131 */
else size = header.offset[loop0 + 1] - header.offset[loop0]; /* :133 */
if (!size) continue; /* :140 */
...
readsize = size; /* :169 */
fread(buffer, readsize, 1, infile); /* :174 */
fwrite(buffer, readsize, 1, outfile); /* :182 */
} while (size); /* :189 */
The eight offsets come straight from the file and are never checked for monotonicity or
against the real file size; if (!size) is the only length gate, and it rejects exactly
zero. Two consequences, both reproduced by compiling the file as-is in a sandbox:
- Attacker-sized output write. A 140-byte PBP with
offset[7] = 0x7FFFFFF0makes the
tool write aDATA.PSPwith no relation to the input size: the loop runs
ceil(size / 16 MiB)times, so the section tops out at ~2 GiB and the tool then exits
0.freadreturns 0 at EOF, but the return value is only tested asresult < 0on a
size_t— always false — so short reads go unnoticed and the stale 16 MB buffer keeps
being written out (the tail of the file is unrelated heap content). - Negative length.
offset[i+1] < offset[i]gives a negativesize; on glibc the
freadcall then fails withEOVERFLOWand the tool silently writes a 0-byte file.
No memory corruption there — I want to be precise about that, since it's the kind of
thing that gets miscategorised.
Net effect: attacker-controlled disk consumption (~2 GiB per crafted section, and eight
sections are unpacked in one run) and silent clobbering of files in the working directory,
from a 140-byte input. Not a memory-safety bug, but it is a real
availability/integrity issue for anything that auto-processes PBPs.
2. tools/psp-prxgen.c — unbounded strcpy of the section name (CWE-121)
strcpy(g_elfsections[i].szName,
(char *)(g_elfsections[g_elfhead.iShstrndx].pData + g_elfsections[i].iName)); /* :303 */
szName is char[ELF_SECT_MAX_NAME] = char[128] (tools/elftypes.h:20,49); the source
is the shstrtab string at the attacker-controlled sh_name offset, with no length check
and no guarantee of NUL-termination inside the table.
Reproduced: a hand-built 384-byte ELF whose section name is 200 bytes, compiled with
-D_FORTIFY_SOURCE=2, aborts with *** buffer overflow detected *** at :303; the same
file with a 100-byte name runs to the normal "no sceModuleInfo section found" path. Under
ASan the 200-byte name corrupts the adjacent ElfSection entries and faults inside
load_sections. 120 bytes of overflow into a global array — worth fixing regardless of
how the tool is invoked.
Fix for both: validate the PBP offset table right after the signature check
(non-decreasing, >= sizeof(HEADER), <= total_size, and reject short fread), and
bound the section-name copy to ELF_SECT_MAX_NAME - 1 while rejecting over-long names.
Happy to send the two input files and the build commands, and to open a PR against a
branch of your choosing.
Regards,
贵志的猫
- 主要语言
- C
- 星标
- 1.2k
- 派生
- 190
- 平均合并
- 1 天 15 小时
- 30 天内合并 PR
- 12
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
pspdev/pspsdk 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 42/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 25/100
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 45/100
维护者通常 1 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复
-
SPIDevice selects an active-high device as soon as it is created可能已有人在做 @mikeysklar 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 73/100
adafruit/circuitpython#11869 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 78/100
gnif/LookingGlass#1352 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100