
Unbeschränkte Speicherzuweisung im UFS-Handler von NanaZip über ein vom Angreifer kontrolliertes Feld `fs_bsize`.
Unbegrenzte Speicherzuweisung im UFS-Handler von NanaZip über ein vom Angreifer kontrolliertes Feld fs_bsize.
| Feld | Wert |
|---|---|
| CVE | CVE-2026-55781 |
| Advisory | GHSA-m34h-jf84-m74h |
| Hersteller | M2Team / NanaZip |
| Betroffen | NanaZip <= 6.5 Preview (6.5.1742.0) |
| Behoben | 6.5.1749.0 |
| Klasse | Denial of Service (CWE-789: Memory Allocation with Excessive Size Value) |
| Plattform | Windows |
| Autor | g17hubH4ck |
| Offengelegt | 2026-07-17 |
NanaZip.Codecs.Archive.Ufs.cpp liest den UFS-Superblock und validiert
fs_bsize nur gegen eine untere Grenze (MINBSIZE). Es wird keine obere
Grenze erzwungen, bevor der Wert zur Dimensionierung von Zuweisungen verwendet wird.
Wenn der Root-Inode (#2) einen di_size deklariert, der groß genug ist, um
indirekte Blöcke zu erfordern, weist der Parser einen Puffer pro indirekter Ebene
unter Verwendung von fs_bsize zu. Das Setzen von fs_bsize = 0x40000000 (1 GiB) und
di_size = 0x10000000000 (1 TiB) erzwingt drei Zuweisungen von je 1 GiB
(Ufs.cpp:435-437) — etwa 3 GiB zusammenhängender Speicher — bevor eine
Grenzprüfung ausgeführt wird.
Ergebnis: Speichererschöpfung und Beendigung des Prozesses. Keine Codeausführung.
| Bereich | Offset | Hinweise |
|---|---|---|
Root-Inode #2 | 512 | ufs2_dinode, 256 Bytes, di_mode = IFDIR, di_size = 1 TiB |
| UFS2-Superblock | 65536 (SBLOCK_UFS2) | struct fs, Little-Endian, fs_bsize = 0x40000000 |
| Gesamtgröße | 66912 Bytes | SBLOCK_UFS2 + sizeof(struct fs) |
Wichtige Superblock-Felder (Offsets aus offsetof(struct fs, ...) in FreeBSD fs.h):
| Offset | Feld | Wert |
|---|---|---|
+16 | fs_iblkno | 0 |
+44 | fs_ncg | 1 |
+48 | fs_bsize | 0x40000000 ← bösartig |
+52 | fs_fsize | 1 |
+56 | fs_frag | 1 |
+104 | fs_sbsize | 1376 |
+1000 | fs_sblockloc | 65536 |
+1372 | fs_magic | 0x19540119 (FS_UFS2_MAGIC) |
Adresse des Root-Inodes: GetInodeOffset(2) = fs_iblkno * fs_fsize + 2 * 256 = 512.
python3 poc.py poc.img
Das Skript schreibt das fehlerhafte Image und parst es erneut, um zu bestätigen, dass jedes Feld dort gelandet ist, wo der verwundbare Parser es erwartet. Kein Netzwerkzugriff, keine Subprozesse, keine weaponisierte Nutzlast — die Trägerdatei allein ist harmlos.
Verifikation
Das erzeugte Image kann ohne NanaZip inspiziert werden:
xxd -s 65536 -l 64 poc.img # superblock header
xxd -s 512 -l 32 poc.img # root inode header
Um den Absturz zu beobachten, öffnen Sie poc.img mit einem verwundbaren Build unter Windows. 6.5.1749.0 und später verarbeiten die Eingabe korrekt.
Hinweis: Dieser PoC wurde durch statische Analyse des NanaZip.Codecs-Parsers erstellt. Er erreicht die exakt verwundbare Zeile, die im Advisory dokumentiert ist, wurde jedoch nicht gegen einen laufenden NanaZip-Build ausgeführt.
Gegenmaßnahmen
· Aktualisieren Sie auf NanaZip >= 6.5.1749.0. · Falls ein Upgrade nicht möglich ist, vermeiden Sie das Öffnen von UFS-Images aus nicht vertrauenswürdigen Quellen.
Referenzen
· NanaZip: https://github.com/M2Team/NanaZip · Advisory: GHSA-m34h-jf84-m74h · CWE-789: https://cwe.mitre.org/data/definitions/789.html
Haftungsausschluss
Dieses Material wird ausschließlich für defensive Forschung und die Reproduktion von Schwachstellen in kontrollierten Umgebungen bereitgestellt. Verwenden Sie es nicht gegen Systeme, die Ihnen nicht gehören oder für deren Test Sie keine ausdrückliche Erlaubnis haben.