В библиотеке zlib выявлена уязвимость (CVE-2018-25032), приводящая к переполнению буфера при попытке сжатия специально подготовленной последовательности символов во входящих данных. В текущем виде исследователями продемонстрирована возможность вызова аварийного завершения процесса. Может ли проблема иметь более серьёзные последствия ещё не изучено...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56918
Как же одинаковы все эти уязвимости.
спасите мои gz архивы 😱
Разве оно не используется прямо тут, на opennet? Судя по заголовку, тут трафик gzip жмётся.
gzip - это не zlib.
> gzip - это не zlibНу, для начала, не я про gzip сказал. Я же ни слова про zlib не говорил.
Zlib это опенсорс реализация deflate, всё, что не zlib -- часто копия/форк. Тот же zip это (среди прочего) формат архива, использующий этот самый deflate (по появился он до png и zlib). А Gzip это не архив.
Всё это конечно классно и правильно, что ты сказал. Но я советую всё же распаковать исходники Firefox и поискать там файлик deflate.c, который и надо в основном пропатчить.
> советую всё же распаковатьДавно не встречал такого филигранно тонкого троллинга.
Мне интересно, как они получили эту последовательность? А вообще, выглядит довольно опасно, такая уязвимость может быть куда серьёзнее уязвимости в openssl и всего-то надо подставить строку текста под сжатие.
У чувака программа падала при сжатии. Он начал копать и определил, что причина в zlib. А потом и последовательность для повторения бага подобрал.
Адлер сказал да ладно я всё решу(R) и уязвимость фигняhttps://github.com/madler/zlib/issues/605#issuecomment-10798...
> патч с исправлением уязвимости был предложен ещё в 2018 году, но разработчики не обратили на него вниманияОпять... 🤦
Опен сорс пауер во всей красе.
Лицензия AS IS наше всё.
Современным хакерам даже не нужно ничего придумывать, все в закрытых/висящих issue.
Поэтому и появляются вот эти громкие заголовки, только на хайпе можно заставить разработчика пофиксить проблему которая в обычных условиях признается "слишком редкой, мудреной и сложной в применении"
Из таких проблем и состоит, например, libreoffice. Правда только на треть, у второй трети ноги растут из xml, а у третьей -- из использования ООП-наследования.
Так это сразу куча серверов под удар попадают.
Осталось подсунуть файл на сервер и заставить его сжимать...
> Осталось подсунуть файл на сервер и заставить его сжимать...Любой web-сервер по дефолту начнёт сжимать что укажешь.
https://en.wikipedia.org/wiki/HTTP_compressionИли волшебную последовательность можно отправить в любую форму на сайте и СУБД сожмёт их при сохранении, или прислать в числе изменений для Git.
Не факт, иногда серверу надо явно включать модули сжатия. Опять же есть более новые методы, тот же brotli
Переполнение буфера, классика
Ну и как обычно, Rust реализация неуязвима
https://github.com/Frommi/miniz_oxide
Сегфолта может и не будет, но поток же будет повреждён?Windows 10 тоже до сих пор extended разделы портит, если в самом начале EBR встречается дырка. Толку с того, что diskpart не упал, потом все равно ковыряться в hex-редакторе и вручную править смещения для EBR. Хоть на C, хоть на C#, хоть на javascript пиши...
Haiku что-то нехорошее делает с разделами, причём по моему даже если другие были подключены только для чтения.
> Сегфолта может и не будет, но поток же будет повреждён?Переполнение буфера выльется либо в панику (если код не обрабатвает его, проверить можно через инструменты для запрета паник https://docs.rs/no-panic), либо в ошибку
Молча проглотить в Rust будет сложноЯ посмотрел - компрессор статичных блоков везде переполнения переводит в ошибки
https://github.com/Frommi/miniz_oxide/blob/991e3154b49e56cf7...
Ну и пример из уязвимости корректно обрабатывает
А чего же там 68% кода на некошерной Сишке?
C 68.4%
Rust 26.4%
C++ 4.9%
Shell 0.3%
Как обычно, взяли сишный код, обернули слоем раста...
>> 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.
> Как обычно, взяли сишный код, обернули слоем раста...Как обычно, опеннетные эксперты сморозили глупость, ведь сделали там обертку для сишного кода.
Но ЖСники и прочие питонисты опеннета в таких деталях не разбираются, они видят знакомые слова и сразу идут в газовую атаку ...
> А чего же там 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
Чтож этот суперский раст не может сам себя протестировать. Это просто ор.
>> Pure rust Rust replacement 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 без использования последней?> Это просто ор.
С опеннетовского воинствующего ламерья ...
> А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней?Какая же каша в голове.
В таких случаях пишутся заглушки которые обрабатывают запросы.
Использовать реальную библиотеку?Какой версии?
Для какой архитектуры?
В каком окружении?
С какими параметрами собранную?
>> А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней?
> Какая же каша в голове.Какой же юлеж у Военов, которые опять не потрудились глянуть в сорцы, зато готовы заглушками в либе тестировать совместимость, ага.
> В таких случаях пишутся заглушки которые обрабатывают запросы.Ну да, зачем брать и прогонять _готовые_ тесты и примеры из miniz с новой либой, если можно просто написать свои заглушки ...
> Ну да, зачем брать и прогонять _готовые_ тесты и примеры из miniz с новой либой, если можно просто написать свои заглушки ...То есть тестироваться будет на одной архитектуре с одним набором окружения и одним набором параметров сборки.
Красавцы!
У вас все так? Или только это?
> То есть тестироваться будет на одной архитектуре с одним набором окружения и
> одним набором параметров сборки.Т.е., если бы Воен соизволил заглянуть дальше заголока, то знал бы, что тестироваться будет точно так же, как и miniz.
> Красавцы!
> У вас все так? Или только это?У кого "у вас" и кто вообще "вы", Воены-Знатоки?
Хммм... а ведь я не очень давно поимел странный эпизод, когда у меня почему-то при распаковке архива распаковалась только часть одного из файлов. Полдня угробил в поисках ошибки у себя, прежде чем догадался сделать просто tail и увидел, что файл битый. Не удивлюсь, если и в распаковщике какая-нибудь фигня обнаружится.
Воспроизвести не удалось.
Почему-то? Как можно не проверять код завершения? Я только вчера столкнулся (впервые на самом деле), что все архивы с пикабу выдают такую ошибку:error: invalid zip file with overlapped components (possible zip bomb)
Error: extraction wasn't successfullРаспаковался только 100гб архив. Но я проверял код завершения, поэтому rm -rf /* не случился (и да, там много rm-rf в инструкциях, это удобно).
Там унзип в пайп пихал, там скрипт не ждал кода завершения.
Звучит достаточно ненадёжно, большая часть zip архивов идёт в неправильной кодировке. Стримить можно только данные, которые пожаты потоковым компрессором.Но и в таком случае есть всякие set -o pipefail и shopt -s inherit_errexit.
Произошла чудовищная ошибка! Подобная уязвимость в любимом языке stackoverflow заняла бы 10 экарнов коментов
Это фиаско, такого от древнего и изученного алгоритма не ожидаешь!
проблема в реализации, а не алоритме
реализация и есть своего рода алгоритм.
Вы путаете понятие "программирование" и "кодинг".
Алгоритм стоит уровнем выше реализации. Реализации может не быть, а алгоритм будет.
Реализаций может быть несколько, а алгоритм один.
И проблема здесь -- в дырявом Си и псевдобезопасном Расте, который дырявость Си заметает под ковёр ансейва.
Самое плохое решение -- делать вид, что ты умный и красивый таковым не являясь. Го в этом смысле -- гораздо честнее. Старается не лезть в Си и не обещает того, что невозможно.
Сказал А говори Б. Го это второй божественный раст.
Тогда уж java. После лечебного голодания и трудотерапии.* Я ещё помню флэш-моб времён фидонета "перепишем всё с C на Java". И "java-процессоры" (там до 2010 движ продолжался и даже остался кое-какой выхлоп в виде "продвинутого" сборщика мусора).
История повторяется через ≈25 лет. Но, похоже что в виде фарса. Ресурсов нету на новый банкет.
Вот чего у растохейтеров не отнять, так это умение приплести Rust к любой теме.
И да, unsafe (читается "ансейф") - не для заметания под ковёр, а для локализации небезопасных операций, которые всё равно неизбежны. Просто когда нужно убедиться в корректности реализации, в Rust ты вручную проверяешь только блоки unsafe, а в C - весь код. И ничего невозможного Rust не обещает, в документации прямо сказано, что безопасность работы с памятью гарантирована только для той части кода, которая не обёрнута в unsafe. В типичном проекте на Rust это 100% кода, потому что unsafe нужен крайне редко для нетривиальных вещей.Короче, RTFM нубы, надоело уже читать ваш straw man бред.
> Короче, RTFM нубы, надоело уже читать ваш straw man бред.Угу. Ждём дыру в компиляторе, связанную с концепцией владения и гонкой данных.
Всё впереди.
Баги есть в любом ПО. Давайте не будем писать на C тогда, а то вдруг компилятор сгенерит некорректный машинный код.
А чего мелочиться, давайте не использовать ПО вообще.
Просто ты недалекий пыхер. Твой уровень интеллекта это максимум «не использовать ПО ваще». Мне тебя жалко.
Пожалей лучше себя. И при чём тут вообще "пыхер"?
Такие есть и были, но это именно что баги, которые со временем пофиксят, и которые не проявляются при нормальных условияхБаги в borrow чекере позволяют лишь писать некорректный код, но сами по себе баги в коде не создают, т.к borrow checker не влияет на поведение
В данный момент есть 2 давно живущих такие баги:
https://github.com/rust-lang/rust/issues/25860
https://github.com/rust-lang/rust/issues/85099 (Не совсем в borrow checkerе, но близко)
...в unsafe требуется оборачивать даже разыменовывание указателя - эта операция требуется в любой производительной современной программе, чуть сложнее "привет мир". Я как только это увидел, сразу закинул Rust за шкаф, и продолжил дальше на Go.
Вот мне всегда было интересно: каково это - быть упёртым хейтером. Наверное, это сродни религии.Ссылки в Rust - это просто указатели, для которых компилятором даются определённые СТАТИЧЕСКИЕ гарантии (во время компиляции). Разыменование ссылки, явное или неявное (скажем, через вызов метода) - то же самое, что и разыменование указателя. Скептикам - rust.godbolt.org в помощь:
pub fn add1(num: &i32) -> i32 {
*num + 1
}Добавляем флаг -C opt-level=1 (самый слабый уровень оптимизаций) и видим:
example::add1:
mov eax, dword ptr [rdi]
add eax, 1
retНу как, достаточно производительно?
Оптимизации, если что - для краткости листинга. Без оптимизаций (-C opt-level=0) разыменование будет точно такое же, только будет добавлена обработка переполнения при сложении:
example::add1:
push rax
mov eax, dword ptr [rdi]
inc eax
mov dword ptr [rsp + 4], eax
seto al
test al, 1
jne .LBB0_2
mov eax, dword ptr [rsp + 4]
pop rcx
ret
.LBB0_2:
lea rdi, [rip + str.0]
lea rdx, [rip + .L__unnamed_1]
mov rax, qword ptr [rip + core::panicking::panic@GOTPCREL]
mov esi, 28
call rax
ud2.L__unnamed_1:
.quad .L__unnamed_2
.asciz "\017\000\000\000\000\000\000\000\002\000\000\000\005\000\000"str.0:
.ascii "attempt to add with overflow"А сырыми или "сишными" указателями приходится пользоваться КРАЙНЕ редко - скажем, для реализации умных указателей и тому подобных трюков. То есть, практически никогда, если вы не разработчик оных или просто любитель заниматься преждевременными "оптимизациями", если это можно так назвать, учитывая отсутствие практической разницы между сырыми указателями и идиоматическими ссылками.
Но вы и дальше продолжайте собирать мусор на Go и считать, что что-то выиграли. В конечном итоге, с вашим походом к изучению документации и компитятора, ваши знания о Go будут столь же скудны и бесполезны, как и ваши знания о Rust, C и т.д.
Да кому нужно голову морочать с Rust, тратить в 3-5 раз больше времени на язык, который ржавчиной обозвали и сделали в нем синтаксис еще хуже чем в птичьем языке, когда в Go есть всё что надо и указатели нормальные, и они работают как указатели. И В Go наверное уже лучший сборщик мусора в мире среди всех языков. Ваш пример с ассемблером в основной массе никому не нужен, даже для драйверов уже не нужен почти нигде, это удел гиков.
А это точно не на бекдоор наткнулись ? Сложно представить последовательность влияющую на это.
Конечно же нет такого не может быть. Это фантастика. Ты разве когда-нибудь видел чтобы бекдоры вставляли специально. Бред какой-то. Ты смотришь неправильные ТВ каналы, тебя там наймиты зазомбировали. Начиная с этой строчки ты забудешь что такое бекдоры и что они вообще существуют.