g17hubh4ck/cve-2026-55781-pocNanaZip के UFS handler में attacker-controlled `fs_bsize` field के माध्यम से unbounded memory allocation।
| फ़ील्ड | मान |
|---|
| CVE | CVE-2026-55781 |
| सलाहकारी | GHSA-m34h-jf84-m74h |
| विक्रेता | M2Team / NanaZip |
| प्रभावित | NanaZip <= 6.5 Preview (6.5.1742.0) |
| ठीक किया गया | 6.5.1749.0 |
| वर्ग | Denial of Service (CWE-789: अत्यधिक आकार मान के साथ मेमोरी आवंटन) |
| प्लेटफ़ॉर्म | Windows |
| लेखक | g17hubH4ck |
| प्रकट किया गया | 2026-07-17 |
NanaZip.Codecs.Archive.Ufs.cpp UFS सुपरब्लॉक को पढ़ता है और
fs_bsize को केवल एक निचली सीमा (MINBSIZE) के विरुद्ध मान्य करता है। मान का उपयोग आवंटन के आकार निर्धारण के लिए करने से पहले कोई ऊपरी सीमा लागू नहीं की जाती है।
जब रूट इनोड (#2) एक di_size घोषित करता है जो अप्रत्यक्ष ब्लॉक की आवश्यकता के लिए पर्याप्त बड़ा होता है, तो पार्सर fs_bsize का उपयोग करके प्रत्येक अप्रत्यक्ष स्तर के लिए एक बफ़र आवंटित करता है। fs_bsize = 0x40000000 (1 GiB) और
di_size = 0x10000000000 (1 TiB) सेट करने पर तीन 1 GiB आवंटन
(Ufs.cpp:435-437) बाध्य होते हैं — लगभग 3 GiB सतत मेमोरी — किसी भी सीमा जाँच के चलने से पहले।
परिणाम: मेमोरी की कमी और प्रक्रिया की समाप्ति। कोई कोड निष्पादन नहीं।
| क्षेत्र | ऑफ़सेट | नोट्स |
|---|---|---|
रूट इनोड #2 | 512 | ufs2_dinode, 256 बाइट्स, di_mode = IFDIR, di_size = 1 TiB |
| UFS2 सुपरब्लॉक | 65536 (SBLOCK_UFS2) | struct fs, लिटिल-एंडियन, fs_bsize = 0x40000000 |
| कुल आकार | 66912 बाइट्स | SBLOCK_UFS2 + sizeof(struct fs) |
मुख्य सुपरब्लॉक फ़ील्ड (FreeBSD fs.h में offsetof(struct fs, ...) से ऑफ़सेट):
| ऑफ़सेट | फ़ील्ड | मान |
|---|---|---|
+16 | fs_iblkno | 0 |
+44 | fs_ncg | 1 |
+48 | fs_bsize | 0x40000000 ← दुर्भावनापूर्ण |
+52 | fs_fsize | 1 |
+56 | fs_frag | 1 |
+104 | fs_sbsize | 1376 |
+1000 | fs_sblockloc | 65536 |
+1372 | fs_magic | 0x19540119 (FS_UFS2_MAGIC) |
रूट इनोड पता: GetInodeOffset(2) = fs_iblkno * fs_fsize + 2 * 256 = 512.
python3 poc.py poc.img
स्क्रिप्ट विकृत इमेज लिखती है और यह पुष्टि करने के लिए इसे पुनः पार्स करती है कि प्रत्येक फ़ील्ड वहीं पहुँचा है जहाँ कमज़ोर पार्सर अपेक्षा करता है। कोई नेटवर्क एक्सेस नहीं, कोई सबप्रोसेस नहीं, कोई हथियारीकृत पेलोड नहीं — केवल कैरियर फ़ाइल हानिरहित है।
सत्यापन
उत्पन्न इमेज को NanaZip के बिना निरीक्षण किया जा सकता है:
xxd -s 65536 -l 64 poc.img # superblock header
xxd -s 512 -l 32 poc.img # root inode header
क्रैश देखने के लिए, Windows पर कमज़ोर बिल्ड के साथ poc.img खोलें। 6.5.1749.0 और बाद के संस्करण इनपुट को सही ढंग से संभालते हैं।
नोट: यह PoC NanaZip.Codecs पार्सर के स्थिर विश्लेषण द्वारा बनाया गया था। यह सलाहकारी में प्रलेखित सटीक कमज़ोर पंक्ति तक पहुँचता है, लेकिन इसे चल रहे NanaZip बिल्ड के विरुद्ध निष्पादित नहीं किया गया था।
शमन
· NanaZip >= 6.5.1749.0 में अपग्रेड करें। · यदि अपग्रेड संभव नहीं है, तो अविश्वसनीय स्रोतों से UFS इमेज खोलने से बचें।
संदर्भ
· NanaZip: https://github.com/M2Team/NanaZip · सलाहकारी: GHSA-m34h-jf84-m74h · CWE-789: https://cwe.mitre.org/data/definitions/789.html
अस्वीकरण
यह सामग्री केवल रक्षात्मक अनुसंधान और नियंत्रित वातावरण में भेद्यता पुनरुत्पादन के लिए प्रदान की गई है। इसका उपयोग उन सिस्टमों के विरुद्ध न करें जिनके आप स्वामी नहीं हैं या जिनका परीक्षण करने के लिए आपके पास स्पष्ट अनुमति नहीं है।