The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимость в zlib, проявляющаяся при сжатии специально оформленных данных

27.03.2022 13:28

В библиотеке zlib выявлена уязвимость (CVE-2018-25032), приводящая к переполнению буфера при попытке сжатия специально подготовленной последовательности символов во входящих данных. В текущем виде исследователями продемонстрирована возможность вызова аварийного завершения процесса. Может ли проблема иметь более серьёзные последствия ещё не изучено.

Уязвимость проявляется начиная с версии zlib 1.2.2.2 и затрагивает в том числе актуальный выпуск zlib 1.2.11. Примечательно, что патч с исправлением уязвимости был предложен ещё в 2018 году, но разработчики не обратили на него внимания и не выпустили корректирующий выпуск (библиотека zlib последний раз обновлялась в 2017 году). Исправление также пока не включено в состава пакетов, предлагаемых дистрибутивами. Проследить за публикацией исправлений дистрибутивами можно на данных страницах: Debian, RHEL, Fedora, SUSE, Ubuntu, Arch Linux, OpenBSD, FreeBSD, NetBSD. Библиотека zlib-ng проблеме не подвержена.

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

Уязвимость может быть эксплуатирована только при использовании стратегии сжатия на основе фиксированных кодов Хаффмана. Подобная стратегия выбирается при явном включении в коде опции Z_FIXED (пример последовательности, приводящей к краху при использовании опции Z_FIXED). Судя по коду стратегия Z_FIXED также может быть выбрана автоматически, если вычисленные для данных оптимальное и статическое деревья имеют одинаковый размер.

Пока не ясно, могут ли быть подобраны условия для эксплуатации уязвимости при использовании стратегии сжатия Z_DEFAULT_STRATEGY, применяемой по умолчанию. Если нет, то уязвимость ограничится отдельными специфичными системами, в которых явно применяется опция Z_FIXED. Если да, то ущерб от уязвимости может быть очень значительным, так как библиотека zlib является стандартом де-факто и применяется во многих популярных проектах, включая ядро Linux, OpenSSH, OpenSSL, apache httpd, libpng, FFmpeg, rsync, dpkg, rpm, Git, PostgreSQL, MySQL и т.д.

Дополнение: Подобраны параметры, при которых уязвимость проявляется при выборе стратегии сжатия по умолчанию Z_DEFAULT_STRATEGY. В реальных условиях совершение атаки по-прежнему оценивается как маловероятное, так как для эксплуатации с использованием выявленной последовательности требуется выставление параметра memLevel в значение 1, в то время как по умолчанию выбирается 8 уровень. Пример последовательности, приводящей к краху при вызове "deflateInit2(&strm, 7, Z_DEFLATED, 15, 1, Z_DEFAULT_STRATEGY)" (level=7, windowBits=15, memLevel=1).

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Первый стабильный выпуск zlib-ng, высокопроизводительного форка zlib
  3. OpenNews: Серьезная уязвимость в Zlib расширении к Python
  4. OpenNews: Уязвимость в KDE Ark, позволяющая перезаписать файлы при открытии архива
  5. OpenNews: Релиз bzip2 и libbz2 1.0.6 с исправлением серьезной уязвимости
  6. OpenNews: Уязвимость Zip Slip, затрагивающая библиотеки для распаковки архивов
Лицензия: CC BY 3.0
Наводку на новость прислал Artem S. Tashkinov
Короткая ссылка: https://opennet.ru/56918-zlib
Ключевые слова: zlib
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, _kusb (ok), 13:32, 27/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Как же одинаковы все эти уязвимости.
     
  • 1.2, васёк (?), 13:39, 27/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    спасите мои gz архивы 😱
     
     
  • 2.5, timur.davletshin (ok), 13:50, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Разве оно не используется прямо тут, на opennet? Судя по заголовку, тут трафик gzip жмётся.
     
     
  • 3.7, Ан2 (?), 14:05, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    gzip - это не zlib.
     
     
  • 4.10, timur.davletshin (ok), 14:13, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > gzip - это не zlib

    Ну, для начала, не я про gzip сказал. Я же ни слова про zlib не говорил.

     
  • 4.12, Аноним (12), 14:14, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Zlib это опенсорс реализация deflate, всё, что не zlib -- часто копия/форк. Тот же zip это (среди прочего) формат архива, использующий этот самый deflate (по появился он до png и zlib). А Gzip это не архив.
     
     
  • 5.16, timur.davletshin (ok), 14:36, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Всё это конечно классно и правильно, что ты сказал. Но я советую всё же распаковать исходники Firefox и поискать там файлик deflate.c, который и надо в основном пропатчить.
     
     
  • 6.20, YetAnotherOnanym (ok), 15:03, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > советую всё же распаковать

    Давно не встречал такого филигранно тонкого троллинга.

     

  • 1.3, Аноним (12), 13:42, 27/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Мне интересно, как они получили эту последовательность? А вообще, выглядит довольно опасно, такая уязвимость может быть куда серьёзнее уязвимости в openssl и всего-то надо подставить строку текста под сжатие.
     
     
  • 2.6, Аноним (6), 13:50, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    У чувака программа падала при сжатии. Он начал копать и определил, что причина в zlib. А потом и последовательность для повторения бага подобрал.
     
  • 2.9, Jajauma (?), 14:13, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Адлер сказал да ладно я всё решу(R) и уязвимость фигня

    https://github.com/madler/zlib/issues/605#issuecomment-1079818721

     

  • 1.4, Аноним (4), 13:43, 27/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > патч с исправлением уязвимости был предложен ещё в 2018 году, но разработчики не обратили на него внимания

    Опять... 🤦

     
     
  • 2.13, Аноним (13), 14:28, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Опен сорс пауер во всей красе.
     
     
  • 3.63, Аноним (63), 16:20, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Лицензия AS IS наше всё.
     
  • 2.25, КО (?), 16:09, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Современным хакерам даже не нужно ничего придумывать, все в закрытых/висящих issue.
     
  • 2.31, Kuromi (ok), 17:07, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Поэтому и появляются вот эти громкие заголовки, только на хайпе можно заставить разработчика пофиксить проблему которая в обычных условиях признается "слишком редкой, мудреной и сложной в применении"
     
     
  • 3.69, adolfus (ok), 11:45, 31/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Из таких проблем и состоит, например, libreoffice. Правда только на треть, у второй трети ноги растут из xml, а у третьей -- из использования ООП-наследования.
     

  • 1.8, commiethebeastie (ok), 14:07, 27/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так это сразу куча серверов под удар попадают.
     
     
  • 2.39, Аноним (39), 23:29, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Осталось подсунуть файл на сервер и заставить его сжимать...
     
     
  • 3.47, Аноним (6), 09:26, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Осталось подсунуть файл на сервер и заставить его сжимать...

    Любой web-сервер по дефолту начнёт сжимать что укажешь.
    https://en.wikipedia.org/wiki/HTTP_compression

    Или волшебную последовательность можно отправить в любую форму на сайте и СУБД сожмёт их при сохранении, или прислать в числе изменений для Git.

     
     
  • 4.70, Kuromi (ok), 20:31, 31/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не факт, иногда серверу надо явно включать модули сжатия. Опять же есть более новые методы, тот же brotli
     

  • 1.14, Аноним (14), 14:28, 27/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Переполнение буфера, классика
     
  • 1.15, Аноним (15), 14:31, 27/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Ну и как обычно, Rust реализация неуязвима
    https://github.com/Frommi/miniz_oxide
     
     
  • 2.22, Аноним (22), 15:26, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Сегфолта может и не будет, но поток же будет повреждён?

    Windows 10 тоже до сих пор extended разделы портит, если в самом начале EBR встречается дырка. Толку с того, что diskpart не упал, потом все равно ковыряться в hex-редакторе и вручную править смещения для EBR. Хоть на C, хоть на C#, хоть на javascript пиши...

     
     
  • 3.33, Kusb (?), 18:04, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Haiku что-то нехорошее делает с разделами, причём по моему даже если другие были подключены только для чтения.
     
  • 3.66, morphe (?), 16:17, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сегфолта может и не будет, но поток же будет повреждён?

    Переполнение буфера выльется либо в панику (если код не обрабатвает его, проверить можно через инструменты для запрета паник https://docs.rs/no-panic), либо в ошибку
    Молча проглотить в Rust будет сложно

    Я посмотрел - компрессор статичных блоков везде переполнения переводит в ошибки
    https://github.com/Frommi/miniz_oxide/blob/991e3154b49e56cf716e51d1abd0f9c8d70

     
     
  • 4.67, morphe (?), 19:30, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и пример из уязвимости корректно обрабатывает
     
  • 2.27, Аноним (27), 16:21, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А чего же там 68% кода на некошерной Сишке?
    C 68.4%
    Rust 26.4%
    C++ 4.9%
    Shell 0.3%
     
     
  • 3.30, Аноним (39), 16:57, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Как обычно, взяли сишный код, обернули слоем раста...
     
     
  • 4.37, Аноним (37), 21:34, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Pure rust Rust replacement for the miniz deflate/zlib encoder/decoder using no unsafe code
    >> This project is organized into a C API shell and a rust crate.
    >> The C API is intented to replicate the api exported from miniz, and in turn also part of zlib.
    > Как обычно, взяли сишный код, обернули слоем раста...

    Как обычно, опеннетные эксперты сморозили глупость, ведь сделали там обертку для сишного кода.
    Но ЖСники и прочие питонисты опеннета в таких деталях не разбираются, они видят знакомые слова и сразу идут в газовую атаку ...

     
  • 3.34, Аноним (-), 18:18, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А чего же там 68% кода на некошерной Сишке?
    > C 68.4%
    > Rust 26.4%
    > C++ 4.9%
    > Shell 0.3%

    С того, что как истинный Опеннетный Воен Супротив Раста - читал опой?
    > miniz_oxide_C_API
    > The C API is intented to replicate the api exported from miniz, and in turn also part of zlib. > The C header is generated using cbindgen

    ...
    > the miniz C code used for tests

    ...
    > or to compare to miniz
    > $ ./travis-after-success.sh

     
     
  • 4.45, Аноним (45), 09:06, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Чтож этот суперский раст не может сам себя протестировать. Это просто ор.  
     
     
  • 5.50, Аноним (50), 11:23, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Pure rust Rust [b]replacement[/b] for the miniz deflate/zlib encoder/decoder using no unsafe code.
    >> The C API is intented to replicate the api exported from miniz,
    > Чтож этот суперский раст не может сам себя протестировать.

    Для неумеющих в английский, переведу: оно написано как замена miniz.
    А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней?

    > Это просто ор.

    С опеннетовского воинствующего ламерья ...


     
     
  • 6.54, Аноним (54), 13:56, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней?

    Какая же каша в голове.

    В таких случаях пишутся заглушки которые обрабатывают запросы.
    Использовать реальную библиотеку?

    Какой версии?

    Для какой архитектуры?

    В каком окружении?

    С какими параметрами собранную?

     
     
  • 7.55, Аноним (55), 14:27, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней?
    > Какая же каша в голове.

    Какой же юлеж у Военов, которые опять не потрудились глянуть в сорцы, зато готовы заглушками в либе тестировать совместимость, ага.
    > В таких случаях пишутся заглушки которые обрабатывают запросы.

    Ну да, зачем брать и прогонять _готовые_ тесты и примеры из miniz с новой либой, если можно просто написать свои заглушки ...

     
     
  • 8.61, Аноним (54), 16:15, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    То есть тестироваться будет на одной архитектуре с одним набором окружения и одн... текст свёрнут, показать
     
     
  • 9.65, Аноним (-), 17:29, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Т е , если бы Воен соизволил заглянуть дальше заголока, то знал бы, что тестиров... текст свёрнут, показать
     

  • 1.18, YetAnotherOnanym (ok), 15:00, 27/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хммм... а ведь я не очень давно поимел странный эпизод, когда у меня почему-то при распаковке архива распаковалась только часть одного из файлов. Полдня угробил в поисках ошибки у себя, прежде чем догадался сделать просто tail и увидел, что файл битый. Не удивлюсь, если и в распаковщике какая-нибудь фигня обнаружится.
    Воспроизвести не удалось.
     
     
  • 2.23, Аноним (12), 15:46, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Почему-то? Как можно не проверять код завершения? Я только вчера столкнулся (впервые на самом деле), что все архивы с пикабу выдают такую ошибку:

    error: invalid zip file with overlapped components (possible zip bomb)
    Error: extraction wasn't successfull

    Распаковался только 100гб архив. Но я проверял код завершения, поэтому rm -rf /* не случился (и да, там много rm-rf в инструкциях, это удобно).

     
     
  • 3.24, YetAnotherOnanym (ok), 16:08, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там унзип в пайп пихал, там скрипт не ждал кода завершения.
     
     
  • 4.28, Аноним (12), 16:22, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Звучит достаточно ненадёжно, большая часть zip архивов идёт в неправильной кодировке. Стримить можно только данные, которые пожаты потоковым компрессором.

    Но и в таком случае есть всякие set -o pipefail и shopt -s inherit_errexit.

     

  • 1.19, Gedweb (ok), 15:01, 27/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Произошла чудовищная ошибка! Подобная уязвимость в любимом языке stackoverflow заняла бы 10 экарнов коментов
     
  • 1.21, Аноним (22), 15:16, 27/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Это фиаско, такого от древнего и изученного алгоритма не ожидаешь!
     
     
  • 2.38, Аноним (38), 21:57, 27/03/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    проблема в реализации, а не алоритме
     
     
  • 3.40, Аноним (39), 00:46, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    реализация и есть своего рода алгоритм.
     
     
  • 4.43, Брат Анон (ok), 07:56, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы путаете понятие "программирование" и "кодинг".
    Алгоритм стоит уровнем выше реализации. Реализации может не быть, а алгоритм будет.
    Реализаций может быть несколько, а алгоритм один.
    И проблема здесь -- в дырявом Си и псевдобезопасном Расте, который дырявость Си заметает под ковёр ансейва.
    Самое плохое решение -- делать вид, что ты умный и красивый таковым не являясь. Го в этом смысле -- гораздо честнее. Старается не лезть в Си и не обещает того, что невозможно.
     
     
  • 5.46, Аноним (45), 09:08, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сказал А говори Б. Го это второй божественный раст.  
     
     
  • 6.49, PnD (??), 11:04, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тогда уж java. После лечебного голодания и трудотерапии.

    * Я ещё помню флэш-моб времён фидонета "перепишем всё с C на Java". И "java-процессоры" (там до 2010 движ продолжался и даже остался кое-какой выхлоп в виде "продвинутого" сборщика мусора).
    История повторяется через ≈25 лет. Но, похоже что в виде фарса. Ресурсов нету на новый банкет.

     
  • 5.56, burjui (ok), 14:46, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вот чего у растохейтеров не отнять, так это умение приплести Rust к любой теме.
     
  • 5.57, burjui (ok), 14:58, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    И да, unsafe (читается "ансейф") - не для заметания под ковёр, а для локализации небезопасных операций, которые всё равно неизбежны. Просто когда нужно убедиться в корректности реализации, в Rust ты вручную проверяешь только блоки unsafe, а в C - весь код. И ничего невозможного Rust не обещает, в документации прямо сказано, что безопасность работы с памятью гарантирована только для той части кода, которая не обёрнута в unsafe. В типичном проекте на Rust это 100% кода, потому что unsafe нужен крайне редко для нетривиальных вещей.

    Короче, RTFM нубы, надоело уже читать ваш straw man бред.

     
     
  • 6.58, Брат Анон (ok), 15:42, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Короче, RTFM нубы, надоело уже читать ваш straw man бред.

    Угу. Ждём дыру в компиляторе, связанную с концепцией владения и гонкой данных.
    Всё впереди.

     
     
  • 7.59, burjui (ok), 16:12, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Баги есть в любом ПО. Давайте не будем писать на C тогда, а то вдруг компилятор сгенерит некорректный машинный код.
     
  • 7.60, burjui (ok), 16:13, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А чего мелочиться, давайте не использовать ПО вообще.
     
     
  • 8.62, Аноним (63), 16:15, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просто ты недалекий пыхер Твой уровень интеллекта это максимум 171 не использ... текст свёрнут, показать
     
     
  • 9.64, burjui (ok), 16:51, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Пожалей лучше себя И при чём тут вообще пыхер ... текст свёрнут, показать
     
  • 7.68, morphe (?), 19:39, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Такие есть и были, но это именно что баги, которые со временем пофиксят, и которые не проявляются при нормальных условиях

    Баги в borrow чекере позволяют лишь писать некорректный код, но сами по себе баги в коде не создают, т.к borrow checker не влияет на поведение

    В данный момент есть 2 давно живущих такие баги:
    https://github.com/rust-lang/rust/issues/25860
    https://github.com/rust-lang/rust/issues/85099 (Не совсем в borrow checkerе, но близко)

     
  • 6.71, Andrew (??), 13:04, 01/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ...в unsafe требуется оборачивать даже разыменовывание указателя - эта операция требуется в любой производительной современной программе, чуть сложнее "привет мир". Я как только это увидел, сразу закинул Rust за шкаф, и продолжил дальше на Go.
     
     
  • 7.72, burjui (ok), 19:34, 01/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вот мне всегда было интересно каково это - быть упёртым хейтером Наверное, это... большой текст свёрнут, показать
     
     
  • 8.73, Andrew (??), 20:03, 03/04/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да кому нужно голову морочать с Rust, тратить в 3-5 раз больше времени на язык, ... текст свёрнут, показать
     

  • 1.48, test (??), 10:34, 28/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А это точно не на бекдоор наткнулись ? Сложно представить последовательность влияющую на это.
     
     
  • 2.51, Аноним (63), 12:03, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Конечно же нет такого не может быть. Это фантастика. Ты разве когда-нибудь видел чтобы бекдоры вставляли специально. Бред какой-то.  Ты смотришь неправильные ТВ каналы, тебя там наймиты зазомбировали. Начиная с этой строчки ты забудешь что такое бекдоры и что они вообще существуют.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру