
Неограниченное выделение памяти в обработчике UFS в NanaZip через контролируемое злоумышленником поле `fs_bsize`.
Неограниченное выделение памяти в обработчике UFS NanaZip через контролируемое атакующим поле fs_bsize.
| Поле | Значение |
|---|---|
| CVE | CVE-2026-55781 |
| Рекомендация | GHSA-m34h-jf84-m74h |
| Производитель | M2Team / NanaZip |
| Затронуто | NanaZip <= 6.5 Preview (6.5.1742.0) |
| Исправлено | 6.5.1749.0 |
| Класс | Отказ в обслуживании (CWE-789: выделение памяти с чрезмерным размером) |
| Платформа | Windows |
| Автор | g17hubH4ck |
| Раскрыто | 2026-07-17 |
NanaZip.Codecs.Archive.Ufs.cpp читает суперблок UFS и проверяет
fs_bsize только по нижней границе (MINBSIZE). Верхняя граница
не применяется до того, как значение используется для определения размера выделений.
Когда корневой inode (#2) объявляет di_size, достаточно большой для
использования косвенных блоков, парсер выделяет по одному буферу на каждый
косвенный уровень, используя fs_bsize. Установка fs_bsize = 0x40000000 (1 ГиБ) и
di_size = 0x10000000000 (1 ТиБ) вызывает три выделения по 1 ГиБ
(Ufs.cpp:435-437) — примерно 3 ГиБ непрерывной памяти — до выполнения
любой проверки границ.
Результат: исчерпание памяти и завершение процесса. Выполнение кода отсутствует.
| Область | Смещение | Примечания |
|---|---|---|
Корневой inode #2 | 512 | ufs2_dinode, 256 байт, di_mode = IFDIR, di_size = 1 ТиБ |
| Суперблок UFS2 | 65536 (SBLOCK_UFS2) | struct fs, little-endian, fs_bsize = 0x40000000 |
| Общий размер | 66912 байт | SBLOCK_UFS2 + sizeof(struct fs) |
Ключевые поля суперблока (смещения от offsetof(struct fs, ...) в FreeBSD fs.h):
| Смещение | Поле | Значение |
|---|---|---|
+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) |
Адрес корневого inode: GetInodeOffset(2) = fs_iblkno * fs_fsize + 2 * 256 = 512.
python3 poc.py poc.img
Скрипт записывает некорректный образ и повторно разбирает его, чтобы убедиться, что каждое поле оказалось там, где его ожидает уязвимый парсер. Без сетевого доступа, без подпроцессов, без боевой полезной нагрузки — сам файл-носитель безвреден.
Проверка
Сформированный образ можно исследовать без NanaZip:
xxd -s 65536 -l 64 poc.img # заголовок суперблока
xxd -s 512 -l 32 poc.img # заголовок корневого inode
Чтобы наблюдать сбой, откройте poc.img уязвимой сборкой в Windows. 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
Отказ от ответственности
Данный материал предоставляется исключительно для защитных исследований и воспроизведения уязвимостей в контролируемых средах. Не используйте его против систем, которыми вы не владеете или на тестирование которых у вас нет явного разрешения.