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

Им твоя библия в рундуке, как зайцу стоп-сигнал в лесу, они читать то не умели.

Вы, кажется, тоже не умеете. Чтобы хранить Библию в рундуке, читать вообще уметь не надо. Но для моряка и пирата это нормально. К современным программистам требования несколько выше.

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

иначе не писал бы такого бреда про С.

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

1. Тесты есть всегда, даже на очень маленьком проекте. Может это просто «ручной» запуск и пониманием того, что все пути отработали. Цель тестов - проверка логики, остальное - побочное. Логических ошибок всегда больше. Почему-то обычно я не выхожу за границы, не течёт ничего и нет прочего use after free, но вот ошибка в логике - легко. Я не верю, что кто-то адекватный пишет какой-то код без всяких тестов и релизит софт на любом ЯП.

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

Ок, давай представим - у нас обычный с++ (не Fil-C++), у нас нет нормального покрытия тестами, мы хотим падать сразу и получать корку, а не непонятная ошибка когда-то там. Что можем сделать?

• шланг поддерживает опцию -Wunsafe-buffer-usage, мы будем получать предупреждения, когда проверить границы нельзя

void f(int *p) {
    ++ p; // warning
    *p = 4;
}

int i;
cin >> i;
int a[3] = {};
cout << a[i] << endl; // warning

• опция _GLIBCXX_ASSERTIONS - вставляет проверки границ в стандартных контейнерах (аля vector_instance[3]), ABI не ломается. Кстати, это дефолт в дебаге.

Вывод: тесты нужны всегда. Проверять границы в рантайме и падать сразу - можно без всяких Fil-C++ и раста

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

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

Если падение программы может принести большой вред, то это учитывается с самого начала проектирования програмно-аппаратного комплекса. Задача процесса — не портить память и файлы на диске. Всё остальное уже задача оркестратора.

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

А ну как перепишут приходи.

Чтобы приходить, нужно сначала уйти. А Rust is here to stay.

Только этого не будет.

Успокойтесь, вашу сишку никто не забирает, ведь на ней столько всего понаписано. C, fortran, cobol — ещё нас всех переживут.

15 человек на сундук мертвеца, про Библию ни слова.

Да что за бзик у хейтерков с списками, этот «довод» давно устарел если чё. Нормально всё со списками в расте и 1 и 2-ух и более связными, и в любом случае получше чем в си, особенно включая те что на сыроуказателях. Просто потому-что что угодно лучше чем на Си, слишком уж убогий и кривой язык.

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

Алё, Маня. А у кого 14,26% мирового рынка десктопов? Нет, это не линукс.

Каждый аргумент убойнее предыдущего. Вы б хоть до пятницы дотянули с алкоголем-то. Так и спиться не долго.

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

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

https://www.opengroup.org/openbrand/register/apple.htm

Выкинули говоришь? 30 лет назад?

А у кого 14,26%

У того, кто умеет делать качественные продукты и не кладёт болт на безопасность.

мирового рынка десктопов?

Ещё рынок игровых приставок посчитайте.

ну у меня здесь безопасный язык, раз скомпилил, значит ок.

Такие разговоры я слышал только от местных сишников. Собственно, на сам rust мне плевать, меня больше ошибки в логике софорумцев забавляют. У сишников раз за разом повторяются аргументы: «избиение соломенного чучела», «аппеляция к авторитету» и «сам дурак». И почти ничего кроме этого. Хотя казалось бы, чисто технические вопросы обсуждаем.

А если и упало, то не упало, а завершилось

В определённом контексте вполне разумный подход.

Не вертись как вошъ на гребешке. Кто прокукарекал «Юникс выкинули на помойку тридцать лет назад. Алё.»?

Не вертись как вошъ на гребешке.

Отчего бы вам самим не последовать своему совету? Юникс — это юникс. Выкинут на помойку и вполне заслужено. А макось и плейстейшн — это макось и плейстйшн — самостоятельные успешные продукты. Не обижайтесь, но это правда.

Под дурочку косишь? Специально для альт. одаренных, макось это и есть сертифицированный юникс.

Под дурочку косишь?

Вас в колхозе воспитывали?

макось это и есть сертифицированный юникс.

В контексте разговора о коде на С, написанном «отцами-оснвателями» — бриллиантово наплевать что там кому сертифицировали. Собственно, то, что вы банальный контекст не способны удержать в памяти и является лучшем аргументом в пользу Rust. Слабый разум нуждается в поддержке и защите.

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

Ко-ко-ко. Тебя конкретно ткнули носом в глупость, которую ты сморозил. «Юникс выкинули на помойку тридцать лет назад. Алё.» Теперь обтекай.

Похоже я и вправду ошибся. Вас в колхозе воспитывали-воспитывали, да не воспитали. Прискорбно.

Так что там со списками? Какими костылями по итогу подперли свой свинарник с боровом внутри?

Ну раз с этим ты согласен, тогда цель раста лично мне не ясна.

Люди тупые, ленивые, невнимательные. Я тут вынужден общаться с человеком, который контекст беседы дольше двух сообщений удержать не способен. Людям нужна помощь и поддержка. Типы и тесты — два мощных оружия современного программиста, которые не противоречат, но помогают один другому. Оба этих средства несовершенны: типы не способны покрыть сложную логику. Тесты покрывают только часть входных значений.

На своих плюсовых тестах я отловлю всё

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

я не выхожу за границы, не течёт ничего и нет прочего use after free, но вот ошибка в логике - легко

Ты легко допускаешь ошибки в логике, но не допускаешь ошибки в логике работы с памятью. Объясни, что в них такого особенного, что тебе не удаётся их допускать?

Ты серьезно? Сложность алгоритмов не ограничена ничем. Это и есть то, чем занимается программист - не борьбой с компилятором, а придумыванием какой-то абстрактной модели и перкладыванием её на ЯП. Не учел то, неправильно подумал там, … . Не думаю, что если язык заставляет чесать гланды через зад, то это как-то позитивно отразится на такой творческой деятельности, это нельзя, там не ходи, …

На своих плюсовых тестах я отловлю всё то, что достаётся растаманам в тяжелых баталиях с компилятором.

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

Сложность алгоритмов не ограничена ничем. Это и есть то, чем занимается программист - не борьбой с компилятором, а придумыванием какой-то абстрактной модели и перкладыванием её на ЯП.

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

Боров подталкивает программиста к тому, чтобы использовать относительно простую модель владения памятью (как метко написал byko3y в своём бложике, "shared read-only state, one way data flow, acyclic data structures"). Если можно уложить программу на эту модель, то зачем с ней бороться?

Боров подталкивает программиста к тому, чтобы использовать относительно простую модель владения памятью (как метко написал byko3y в своём бложике, «shared read-only state, one way data flow, acyclic data structures»). Если можно уложить программу на эту модель, то зачем с ней бороться?

Я вцелом солидарен с этим взглядом, но бывают более сложные случаи, когда так просто не получается. Но! в этих случаях в расте превозмогание борова, а в С/С++ - тонны комментариев описывающих модель и ручная проверка что написанная логика им соответствует. Порядок сложности на мой взгляд ~сопоставим, таким образом аргумент «затратно бороться с боровом» разбивается о то, что «в любом языке тяжело поддерживать сложную архитектуру».

Боров (какбе) строит доказательство, что с памятью всё чики-пуки. А твои тесты - это коллекция примеров, на которых с памятью тоже всё чики-пуки.

Боров строит лишь доказательство, что с памятью чики-пуки в местах, где индексы статичны, а не зависят от входных данных. Для последнего ты получаешь проверку в рантайме с абортом. Нельзя ничего гарантировать в компайл тайме, когда индекс массива приходит от юзера из консоли.

Как ловить ошибки второго типа? Писать тесты. Как ловить логические ошибки? Писать тесты. Значит нужно писать тесты и покрывать ими все ветви? Да!

А твои тесты - это коллекция примеров, на которых с памятью тоже всё чики-пуки.

Нет, конечно. Во-первых, для достижения ветвей и проверки «статичных индексов» (да, раст это делает в компайл тайме, но взамен нужно делать странные и неудобные вещи). Во-вторых, проверка логики. В-третьих, разные входные данные в том числе для проверки «динамических индексов».

В сухом остатке - раст ни сколько не избавляет от написания тестов, ты должен писать их в том же объёме (для проверки логики, и для динамических условий, которые приходят в ран тайме). А раз так, то стоит ли вся эта игра с боровым свеч? (нет)

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

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

Я ни в коем случае не предлагаю отказываться от написания тестов.

Боров не позволит совершить ряд ошибок из числа тех, которые тестами пойманы не будут. Подтолкнет к тому, чтобы написать программу, которая будет корректна по построению. Просто поищи статистику по CVE: какой процент их связан с некорректной работой с памятью (примерно 50%).

И да, если выбирать между падением и remote code execution, то падение гораздо-гораздо лучше.

Повар глянул на свою ладонь.
– Черная метка! Так я и думал, - проговорил он. – Где вы достали бумагу?.. Но что это? Ах вы, несчастные! Вырезали из Библии! Ну, будет уж вам за это! И какой дурак разрезал Библию?
– Вот видите! – сказал Морган. – Что я говорил? Ничего хорошего не выйдет из этого.
– Ну, теперь уж вам не отвертеться от виселицы, – продолжал Сильвер. – У какого дурака вы взяли эту Библию?
– У Дика, – сказал кто-то.
– У Дика? Ну, Дик, молись богу, - проговорил Сильвер, – потому что твоя песенка спета. Уж я верно тебе говорю. Пропало твое дело, накажи меня бог!

Раз они этого не делают, то вся эта возня с боровым смысла не имеет, ничего кроме боли от запретов. Ведь раст заявляет о себе так, что «у нас все безопасно», логично подумать, ну что и тестить тогда не нужно. Но это неверно. А покрытый код тестами и без всякого раста нормально себя чувствует

Ведь раст заявляет о себе так, что «у нас все безопасно»

Со стороны разработчиков раста никогда не заявлялось, что там *всё* безопасно. Они претендуют на «memory-safety and thread-safety», и претензии эти спорны.

логично подумать, ну что и тестить тогда не нужно.

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

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

Это снова логическая ошибка. Тесты не могут гарантировать корректность. Вон openssl и тестируют, и используют широко, и порядок там пытались наводить, и вот что мы имеем из свеженького:

CVE-2025-15467 - Published at 27 January 2026 - Stack buffer overflow in CMS (Auth)EnvelopedData parsing
CVE-2025-68160 - Published at 27 January 2026 - Heap out-of-bounds write in BIO_f_linebuffer on short writes
CVE-2025-69419 - Published at 27 January 2026 - Out of bounds write in PKCS12_get_friendlyname() UTF-8 conversion
CVE-2025-9230 - Published at 30 September 2025 - Out-of-bounds read & write in RFC 3211 KEK Unwrap
CVE-2025-9232 - Published at 30 September 2025 - Out-of-bounds read in HTTP client no_proxy handling