Hacker News Digest

Разработчик выложил на Hacker News фреймворк на C, и я, как исследователь безопасности, сразу заметил три классические ошибки: не проверяемый Content-Length, переполнение при копировании тела запроса и переполнение при записи ответа. Пример кода показывает, как непроверенное поле Content-Length используется как размер для malloc и memcpy, что может привести к утечке памяти или чтению за пределы буфера. Подобные проблемы встречаются везде, где C-фреймворки принимают ввод из сети или файловой системы.

• Обсуждение крутится вокруг того, что «хороший код на C» должен минимизировать выделение памяти и избегать atoi() и strdup() без проверки ошибок, что приводит к уязвимостям.
• Участники спорят о том, насколько критичны эти проблемы в контексте обучения и использования ИИ-помощи, и о том, что новички в C могут не осознавать эти ловушки.
• Обсуждается влияние ИИ на качество кода и безопасность, а также то, что влияние ИИ на обучение языкам может маскировать проблемы, которые иначе были бы очевидны.
• Участники также обсуждают, что влияние ИИ на обучение языкам и на то, что это может привести к проблемам, если человек не понимает, что делает ИИ, и что это может быть опасно.
• В обсуждении также поднимается вопрос о том, что ИИ может быть использован для аудита кода и нахождения проблем, и о том, что это может быть использовано для улучшения качества кода.

В задаче Google CTF 2025 webz исследуется уязвимость в патче Google-zlib, который увеличивает размер таблицы Хаффмана и убирает проверки на переполнение. Это позволяет обойти защиту от oversubscription и incomplete set, что ведёт к использованию неинициализированной памяти в таблице.

Уязвимость проявляется в функции inflate_fast, где неверно построенная таблица Хаффмана приводит к чтению за пределами буфера или использованию мусорных данных. Это позволяет перезаписать указатели и выполнить код, манипулируя сжатыми данными. Эксплуатация требует точного контроля над структурой Deflate-блока для управления содержимым таблицы.

• Обсуждается уязвимость в модифицированной версии zlib, созданной специально для CTF-задачи Google, а не в основной библиотеке.
• Участники отмечают сложность и искусственный характер задач Google CTF, но предлагают ресурсы для обучения и тренировки.
• Проводятся параллели между этой уязвимостью и ранее обнаруженной уязвимостью в WebP.
• Подчёркивается, что ошибку можно быстро найти с помощью фаззинга, без необходимости привлечения ИИ.
• Уточняется, что заголовок исходной статьи содержал пометку "[CTF]", указывающую на соревновательный контекст.

GrapheneOS разработала hardened malloc — аллокатор памяти с акцентом на безопасность для защиты от уязвимостей, связанных с повреждением памяти. Он использует расширенное адресное пространство в 48 бит вместо стандартных 39 бит в Android, что увеличивает энтропию ASLR до 33 бит. Это позволяет эффективнее изолировать структуры данных и выделения памяти через mmap, усложняя атаки.

Аллокатор применяет строгие меры защиты: размещает небольшие объекты в отдельных регионах с защитными страницами, добавляет канарейки для обнаружения переполнений и использует рандомизацию размещения метаданных. Эти механизмы значительно затрудняют эксплуатаюцию уязвимостей, таких как переполнение буфера или использование-after-free, делая GrapheneOS одной из самых защищённых мобильных ОС.

• Критика "усиленных" аллокаторов: снижают производительность, не предотвращают удаленное выполнение кода и их возможности часто преувеличивают.
• Предложение альтернативы: Apple kalloc_type с MTE и аппаратными изменениями для обеспечения целостности памяти.
• Упоминание другого подхода: аллокатор Solaris SPARC ADI.
• Отмечено, что решения от Apple более впечатляющие и продемонстрировали влияние на известные эксплойты.