Уязвимости в проекте Pingora, позволяющие вклиниться

Безопасность, говорили они 🤡🤡🤡

память не пострадала!

память схоронена и освобождена, нету invalid next size (fast).

...на безопасном языке Rust...

Дальше не читал.

https://www.opennet.ru/opennews/art.shtml?num=64957:

Первая уязвимость CVE-2026-2835 присутствует в коде разбора запросов HTTP/1.0 и вызвана некорректной обработкой заголовка «Transfer-Encoding» с несколькими значениями, а также использованием закрытия соединения как признака конца тела запроса (close-delimited). Pingora проверял только вариант «Transfer-Encoding: chunked» и игнорировал данный заголовок, если в нём указывалось несколько значений. В этой ситуации Pingora не учитывал размер в заголовке «Content-Length», а считал телом запроса все данные, полученные до закрытия соединения.

Вторая уязвимость CVE-2026-2833 вызвана некорректной обработкой HTTP-заголовка «Upgrade» в запросах HTTP/1.1. При наличии в запросе заголовка «Upgrade» прокси сразу пробрасывал к бэкенду и остальные данные запроса, следующие за заголовком «Upgrade», не дожидаясь от бэкенда ответа с кодом 101 (Switching Protocols). Из-за этого синхронизация потока между прокси и бэкендом нарушалась и бэкенд воспринимал отправленные после заголовка «Upgrade» данные как отдельный запрос, и отправлял результат выполнения этого запроса в ответ на пришедший следом запрос другого пользователя.

Третья уязвимость CVE-2026-2836 (степень опасности 8.4 из 10) приводит к отравлению кэша (cache poisoning) из-за генерации ключа размещения данных в кэше (CacheKey) только на основе пути из URI, игнорируя содержимое заголовка «Host». Подобная недоработка приводит к формированию одинаковых ключей кэширования для одинаковых HTTP-путей к разным хостам. Уязвимость может использоваться для подмены содержимого кэша при использовании режима кэширования для нескольких хостов. В Pingora кэширование является экспериментальной функцией, не рекомендованной для рабочих внедрений.

Как будто бы всё это не могло быть на любом другом ЯП.
Но лишний раз пнуть Раст даже ленивые не прочь.

Просто умиляет, как с таким супер-пупер-безопасным инструментом макаки умудряются выкидывать CVE 20 из 10 раз за разом.

Прав был Мёрфи: Создайте инструмент, которым сможет пользоваться даже дурак, и только дурак будет им пользоваться.

И безопасной бритвой можно порезаться. Толко всё кричат «безопасная», и все забывают «бритва». Вот это смешит.

И безопасной бритвой можно порезаться. Толко всё кричат «безопасная», и все забывают «бритва». Вот это смешит.

С этим не поспоришь. :)

Все силы были потрачены на борьбу с языком. На тестирование их не осталось.

Вы бы завели тег rust-haters-cicrlejerking, чтобы я например мог добавить в игнор)

Так никто же его не будет добавлять по доброй воле. :)

Так в том и дело, что никакой раст или что бы то ни было ещё не спасёт от логических ошибок, их сделать проще, и их много больше. Только тесты, тесты и ещё раз тесты, которые покрывают желательно все пути выполнения, могут подтвердить корректность программы. А если есть тесты, которые можно запускать с санитарами, нахрен нужен раст? Сражаться героически с его компилятором, а потом всё равно запускать те же тесты? Какая-то ненужная боль

Но если разработчики сабжа (он же не переписан с чего-то?) знают только Раст, какой ещё ЯП им было выбирать?

типичная метрика покрытия тестами - грубо говоря покрыли все вариации значений bool-подвыражений (в том числе в if услових на пути выполнения). Это вполне понятная метрика, подходит для многих языков, с годами совершенствуется.

Хорошее покрытие тестами с подобными bool-метриками по разнообразию путей выполнения как правило позволят выявить в санитайзерах ошибки типа работы с овобождённым объектом.

А вот по какой метрике понять что покрытие тестами достаточно для того чтоб санитайзерами выявить выход за границу массива? Тут уже не пути выполнения считать надо, а какие-то соотношения в исползуемых числах.

В моей практике борьба с компилятором раста занимает примерно столько же времени как планирование+фиксация в комментариях C++ контрактов по владению объектами - то есть 0 в простых/средних случаях и довольно много в запутанных многпоточных системах. Пишу и на том и на другом, последнее время больше на С++.

Только тесты, тесты и ещё раз тесты, которые покрывают желательно все пути выполнения, могут подтвердить корректность программы.

Серьёзно?

Питон. Он и проще и надежней в смысле работы с памятью.

От создателей «юнит тесты не нужны, т.к. потом всё равно остаются баги»

Фишка в том, что ржавчина такая-разтакя надёжная, что тестить то не особо и надо, говорят они. Раз написал переписал (они только переписывают, своего ничего нет), и шмяк, в продакшин.

Просто умиляет, как с таким супер-пупер-безопасным инструментом макаки умудряются выкидывать CVE 20 из 10 раз за разом.

В вопросе разберись для начала, мамкин погромист, блин.

А вот по какой метрике понять что покрытие тестами достаточно для того чтоб санитайзерами выявить выход за границу массива?

Ну давай не будем делать вид, что в расте нельзя выйти за границу массива. Индекс пришёл в ран тайме, обращение мимо, паника. Упавшая программа может повлечь ужасные последствия. Так что твой вопрос для раста не менее актуален

Как будто бы всё это не могло быть на любом другом ЯП.

Апологеты более других языков не бьют себя пяткой в грудь, выкрикивая лозунги о безопасности.

«Упавшая программа это лучшее, что может произойти, если что-то пошло не так.» От создателей эрланга, на котором пишут системы с 9 девятками.

Переврал цитату, да и у эрланга дизайн совершенно противоположный расту

паника. Упавшая программа

Не упавшая, а аварийно завершившая работу в условиях непредусмотренного нарушения инвариантов, корректно определив ситуацию.

Так в эрланге основная парадигма Let it crash, пришедшая с RT-систем.

Ну давай не будем делать вид, что в расте нельзя выйти за границу массива. Индекс пришёл в ран тайме, обращение мимо, паника. Упавшая программа может повлечь ужасные последствия. Так что твой вопрос для раста не менее актуален

ок, аргумент защитан)

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

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

Теперь возвращаемся к вопросу «зачеп нужен раст?.»

Если на внедрении код исполняется в среде с продвинутыми санитайзерами а-ля Fil-C++ или раст - то по крашу будет более понятно что произошло, чем если код исполнялся в среде без санитайзеров и упало через 1000 инструкций после реальной причины, и даже при наличии core-dump разбирательство займёт безумные человеко-дни потому что это будет угадайка на тему «а какой из 10 потоков перезаписал тут данные указателя числом 1 неизвестное количество времени назад». Или хуже того не упало, а внесло ошибку в данные, которая всплывёт через 5 лет

То есть ответ на то «какую безопасность добавляет rust для кода с высоким покрытием тестами?»: добавляет безопасность от незамеченных ошибок выхода за границы массива в уже внедрённом ПО. Заметно меньше чем можно подумать, заметно больше чем ничего.

Fil-C++ кажется даёт этот же эффект. То есть доя кода хорошо покрытого тестами безопасность раст и Fil-C++ одинакова. Тут сложно сказать кто из них будет проще в поддержке/разработке через 15 лет, поскольку при поддержании сложной по архитектуре кодовой базы с хорошим покрытием тестами - большая часть времени уходит на проектирование, а никак на борьбу с компилятором.

И тут мы подходим к другому типу проектов, который по факту встречается многокраьно чаще. Где «написано за 2 недели вдохновения/дедлайна и покрыт тестами только основной сценарий использования, а не ветки ошибок». И вот тут уже в зависимости от типа проекта могут всплыть и плюсы и минусы - или «сильно больше боданий с компилятором, проект заброшен» или «боданий незначительно больше, но на 30% меньше ошибок работы с памятью в коде не покрытом тестами благодаря подсказкам компилятора (оставшиеся 70 это panic выявленный в рантайме)».

Однако, обращаю внимание что это сравнение раста с Fil-C++ с рантаймовыми проверками после внедрения. Если проект, написанный за 2 недели не имеющий нормального покрытия тестами внедряется собранным обычным C++ - то возможность его поддерживать станет вопросительной после первого же бага вида «глючит/падает 1 раз из 10 у пользователя, воспроизвести не вышло, разбирать core-dump 2 недели нет времени, просто объявляем известным багом». Пример такого проекта - QtCreator, там каждая фича запилена побыстрому за 2 недели и половина его версий - глючит/падает раз в 2 дня при работе в нём с большим проектом.

Учитывая что проектов такого вида много боше чем хорошо покрытых тестами - для них раст был бы очень полезен сокращением числа ошибок при условии что структура проекта не слишком сильно вынуждает бороться с компилятором.

Но лишний раз пнуть Раст даже ленивые не прочь.

Никто б его не пинал, если б растофанатики не орали везде про безопасность. Они ж осознанно распространяют миф, что достаточно просто писать на расте, чтобы было БИЗАПАСНА.

+1. Не так страшна ржавчина как её остервенелые евангелисты и горе-переписыватели.

Никто б его не пинал, если б растофанатики не орали везде про безопасность.

Вот прям все? В любом сообществе есть глупые люди, просто не читай их ор. Всегда так делаю. :)

Вот прям все? В любом сообществе есть глупые люди, просто не читай их ор. Всегда так делаю. :)

Да даже здесь если новость про раст, то обязательно будет про бизапаснасть написано.

ржавчина такая-разтакя надёжная, что тестить то не особо и надо, говорят они.

Эти «они» здесь, с нами, в одной комнате?

Да даже здесь если новость про раст, то обязательно будет про бизапаснасть написано.

Я так никогда не писал в новостях об утилитах на Расте! Вот видишь! :-D

Ты исключение :)

память не пострадала!

ну да..:-)

сейчас вздрачивают на memory-safety и путают это с общей безопасностью, а сам термин просто о том что нюб не может просто так упахать память (породить утечку, сорвать/переполнить стек, etc) или получить/передать чужие данные в alloc/free; Его одёрнут на этапе компиляции. Штука полезная, но ни о чём для системных языков.

нимало не сомневаюсь что в каком-нибудь compiled-strong-lisp всё ничуть не хуже с этой точки зрения.

Языки со сборокой мусора играют в отдельной лиге. Как их вообще сравнивать?

нюб не может просто так упахать память

Штука полезная, но ни о чём для системных языков.

Жаль, что всякие полезные проекты типа браузеров, курла, опенссл пишут нюбы, а настоящих профессионалов в эти проекты не пускают.

Только тесты, тесты и ещё раз тесты, которые покрывают желательно все пути выполнения, могут подтвердить корректность программы

Не могут. Тесты в лучшем случае могут подтвердить корректность работы программы на протестированных входных данных.

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

одёрнут на этапе компиляции. Штука полезная, но ни о чём для системных языков

Штука бесполезная и даже вредная, поскольку отнимает массу сил на ублажения тупого компиляторя. Это как в С++ запретить приведение типов через (void*) а заставлять пользоваться исключительно _cast.

В конце концов, если ты настолько туп, что косячишь с указателями и памятью, то может не стоит заниматься системщиной, а пойти в детский сад. Отцы целиком написали промышленный Unix на сырых указателях, а это, минуточку, 30 млн. строк. Расскажи им про раст, они вообще бы не поняли про что это и зачем.

поскольку отнимает массу сил на ублажения тупого компиляторя.

Гораздо больше сил и времени уйдёт на исправление, отладку и поддержку из-за ублажения тупого программиста, который привык кастить/автокастить направо и налево прямо вот как в сишечке. Жалко Страуструп не дожал и сразу не выкинул весь сишный рак с типами(одна вот эта херня с char=int8_t=uint8_t, а если пририсовать * то вообще чему угодно, чего стоит). И именно в системщине типы и касты должны быть строгими и точными настолько насколько это вообще возможно.

И как недавно выяснилось, «отцы» точно так же лажали с памятью как и сейчас, раньше на это внимание просто не обращали

Они бы не поняли как сделать unix когда двусвязные списки не реализуемы.

По вашим словам, они были тупы, как пробка.

Отцы целиком написали промышленный Unix

Да, но есть ньюанс: Восстановлен код UNIXv4, первой ОС с ядром на языке C: „Один из исследователей безопасности обратил внимание на утилиту «su», поставлявшуюся в UNIXv4. Данная утилита включала менее 50 строк кода, устанавливалась с флагом setuid-root и позволяла запустить /bin/sh с правами root при вводе правильного пароля. Код содержал уязвимость, приводящую к переполнению буфера из-за копирования вводимого пользователем пароля в фиксированный 100-символьный массив без проверки размера вводимых данных“.

Сишный говнокод и дырени с самих отцов и начался.

Жалко, что ты не дочитал Страуструпа, где он пишет зачем был создан С++, иначе не писал бы такого бреда про С.

Говорят в эпоху парусных судов каждый моряк держал Библию у себя в рундуке. Потому как сдохнуть во время шторма или от цинги можно очень даже запросто в любой момент. Читать Библию никто, однако, не собирался и гибли моряки пачками. Так вот, книжки Кнута нужно читать, не только держать на столе. А двусвязные списки прекрасно реализуются на массивах.

А я и не писал, что там не было ошибок. Но ты сначала напиши продукт который уже 50+ лет работает и заменить его особо нечем, а потом можешь сказать свое ко-ко-ко. Где безопасные ОС на безопасном расте? Пока мы наблюдаем огромную дырищу в 9.2 по 10 бальной шкале.

А ну понятно. Терпилоиды растаманы таки не смогли в двусвязный список.

Интересно как быть когда нельзя производить аллокацию в том же ядре а вставить элемент в список надо. В си это решается специальным полем в структуре и container_of.

А я и не писал, что там не было ошибок.

Это вы очень мудро поступили. Заранее соломки постелили, чтоб падать не больно было.

Растоманы тоже стелят соломку заранее. Видете, у вас много общего.

который уже 50+ лет работает и заменить его особо нечем

Юникс выкинули на помойку тридцать лет назад. Алё.

Где безопасные ОС на безопасном расте?

Теперь здесь.

А ну понятно.

Не заметно.

Неужели Линукс уже на расте переписали? Или просто обёртку сделали для вызовов?

Начали. ИЧСХ не собираются останавливаться.

Где ты этот бред прочитал? Моряки парусного флота были любителями рома, драк и смазливых юнг. Им твоя библия в рундуке, как зайцу стоп-сигнал в лесу, они читать то не умели. Библия на судне конечно была, у корабельного священника.