URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 128821
[ Назад ]
Исходное сообщение
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке сертификатов X.509 "
Отправлено opennews , 01-Ноя-22 20:00 
Опубликован корректирующий выпуск криптографической библиотеки OpenSSL 3.0.7, в котором устранены две уязвимости. Обе проблемы вызваны переполнением буфера в коде проверки поля с email-адресом в сертификатах X.509 и потенциально могут привести к выполнению кода при обработке специально оформленного сертификата. На момент публикации исправления разработчиками OpenSSL не было зафиксировано фактов наличия рабочего эксплоита, способного привести к выполнению кода атакующего...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=58025

Содержание
Сообщения в этом обсуждении
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:00 
Опять ненастоящие Сишники, да что ж такое!
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:02 
Это, конечно, не вебмакаки. Вебмакакам до такого уровня ещё деградировать и деградировать.

Уже массив создать и заполнить не могут.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 02:19 
Ubuntu packages are built with stack protector, reducing the
impact of this CVE from remote code execution to a denial of
service.

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

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено ВлезВТопик , 02-Ноя-22 07:38 
Сишники настолько умные, относительно растоманов, что зачастую брезгуют любыми проверками кода.
Вот вам и результат студенческого уровня..
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 13:58 
Смени топик на майку.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 03-Ноя-22 14:55 
Лучше на зайку
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:16 
> Уязвимости проявляются только в ветке OpenSSL 3.0.x

Что-то последнее время часто появляются "уязвимости" в НОВОМ коде, а в старых версиях всё чисто.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:40 
Деградация, жертвы питона освоили C.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:42 
у дидов обычно уязвимости на уровне спецификации протокола
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 21:08 
то не уязвимость, а закладка от АНБ была.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено another_one , 01-Ноя-22 20:49 
> а в старых версиях всё чисто

Heartbleed такой - ну да, ну да...

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 23:08 
Кстати, его всегда можно было отключать, или это потом уже придумали? Там вообще много чего отключается. Так что страдают в основном хомяки, юзающие предкомпилированные пакеты. Ну ещё хомяки-корпоративные тестеры, как мы видим.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 05:23 
MS'овская многоходовка?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 09:54 
Как только Лёня всплыл в проруби микрософта - уже ничему не удивляешься.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:41 
Не веб-макаки говоришь... Ты фиксы смотрел? Это хуже чем любой вебмакакинг!
- if (written_out > max_out)
+ if (written_out >= max_out)
https://github.com/openssl/openssl/commit/fe3b639dc19b325846...
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 21:10 
растаманы бы написали

if (written_out < max_out)

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 13:30 
Что бы сделали растаманы - твои маняфантазии.
А что сделали сишники - мы все уже увидели.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено microsoft , 02-Ноя-22 22:00 
Но и кода ты растик не показал
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 06:36 
И что здесь такого? Чел забыл, что чек происходит уже после того, как данные пишутся в буффер, а не перед. По вашему было бы лучше обернуть код в кучу for циклов до такой степени, что он перестанет быть читаемым, потому что вам придётся следить за десятками проверок каждого цикла внутри цикла? Или лучше потратить рантайма на бесконечные проверки того, что нам как программисту и так уже известно, но пускай теперь эта проверка будет исполнятся каждую миллисекунду на миллиардах машин по всему миру?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 06:57 
Точно известно? А через неделю не забудешь? Через месяц? А коллегам не забудешь рассказывать?

А для простых переборов всех элементов массива через foreach проверку во время выполнения можно не проводить

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено n00by , 02-Ноя-22 09:33 
Если ограничиться фрагментом из патча и не вникать в остальной код, то written_out инкрементируется на 1. Не понятно, зачем там вообще >. Достаточно было бы ==. В смысле, вместо > < <= >= == != выбор сужается до 2-х вариантов сравнения == или !=, и некорректный сразу не проходит тесты. Такому подходу учит концепция итераторов в плюсах, где operator>() может быть не определён.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 17:10 
> Не понятно, зачем там вообще >. Достаточно было бы ==.

Ты про defensive programming слышал? Опыт программирования, особенно на языках типа C, приучает к такому стилю. Сейчас там может и достаточно было бы ==, а завтра придёт следующий, и за итерацию сделает ++ дважды, а проверку забудет поправить. Поэтому >=.

> Такому подходу учит концепция итераторов в плюсах, где operator>() может быть не определён.

Итератор и int -- это разные вещи, и обращаться с ними надо по-разному.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 03-Ноя-22 04:08 
> Ты про defensive programming слышал?

ты на ник его посмотри и не задавай глупых вопросов

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено n00by , 03-Ноя-22 09:47 
Работает ведь. Особенно зачётно, когда персонаж без имени такое пишет. ;)
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено n00by , 03-Ноя-22 09:29 
>> Не понятно, зачем там вообще >. Достаточно было бы ==.
> Ты про defensive programming слышал?

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

> Сейчас там может и достаточно было бы
> ==, а завтра придёт следующий, и за итерацию сделает ++ дважды,
> а проверку забудет поправить. Поэтому >=.

Очевидно из кода, что не сделает.

> Итератор и int -- это разные вещи, и обращаться с ними надо по-разному.

Если я написал про отсуствие operator>(), наверное, я немного понимаю, что такое итератор. А если не понятно, что итератор приучает машинально писать везде ++i вместо i++, а в сложных случаях, когда это действительно надо, приходится задумываться и избегать вот таких ошибок, так пишите про это прямо.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 06:53 
Ошибиться на 1 символ это самая частая ошибка, у людей нервная система так работает.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 21:13 
> ненастоящие Сишники

Что-то всё чаще и чаще мелькает бубнеж этой мантры. Не надоело?

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено n00by , 02-Ноя-22 09:47 
>> ненастоящие Сишники
> Что-то всё чаще и чаще мелькает бубнеж этой мантры. Не надоело?

Смотрите комментарий над проблемной функцией:


/*-
 * Pseudocode:
 *
 * function ossl_punycode_decode
 *  let n = initial_n
 *  let i = 0
 *  let bias = initial_bias
 *  let output = an empty string indexed from 0
 *  consume all code points before the last delimiter (if there is one)
 *    and copy them to output, fail on any non-basic code point
 *  if more than zero code points were consumed then consume one more
 *    (which will be the last delimiter)
 *  while the input is not exhausted do begin
 *    let oldi = i
 *    let w = 1
 *    for k = base to infinity in steps of base do begin
 *      consume a code point, or fail if there was none to consume
 *      let digit = the code point's digit-value, fail if it has none
 *      let i = i + digit * w, fail on overflow
 *      let t = tmin if k <= bias {+ tmin}, or
 *              tmax if k >= bias + tmax, or k - bias otherwise
 *      if digit < t then break
 *      let w = w * (base - t), fail on overflow
 *    end
 *    let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?)
 *    let n = n + i div (length(output) + 1), fail on overflow
 *    let i = i mod (length(output) + 1)
 *    {if n is a basic code point then fail}
 *    insert n into output at position i
 *    increment i
 *  end
 */

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 01-Ноя-22 22:49 
npm audit fix
https://vuldb.com/?recent.202211
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 01-Ноя-22 22:50 
https://vuldb.com/?recent.202210
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 10:06 
Но вы же не веб-макака и знаете что такое шина адреса (она вообще есть у современных SoC?) и чем отличается гарвардская архитектура от фон Неймановской.
Перепишите со смузихлебного языка js-ts на несмузихлебный... не знаю что Си-GO допустим
Или хотя бы уменьшите количество зависимостей, ведь многих фронтэнд библиотек таких как typescript, react, dart sass, corejs и т.д. нет или почти нет не dev зависимостей.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 13:46 
Я просто возьму Qt/WxWidgets, Pure JS (как макаки называют "отдельную технологию" чистого JS без фреймворков), и это не будет велосипед, т.к. добавлять пады слева и проверять тип объекта я умею руками.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 13:55 
не Pure, Vanilla JS точнее. каких только не развели
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 13:47 
Java Spring, наконец. Это касательно с фронтендом, кроме Go.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 16:28 
Я правильно понимаю вы пишете одновременно на:
1) go
2) qt/c++
3) WxWidgets/c++
4) java/spring
5) Pure C для микроконтроллеров
6) фронтэнд на html/css/javascript без "доширак классов MMMMVVVVCCCC SPA"

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

Например у моей знакомой которая 15 лет программирует с трудом и не до конца удается совмещать 1 бэкэнд на C# и 1 фронтэнд на 1 библиотеке пользовательских интерфейсов Ext JS
Она там один и самых лучших разработчиков.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 16:42 
Женщина-программист? Чего только не выдумывают на опеннете.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 18:55 
У меня была сеньёрша по шарпам. Реально. Просто место работы надо менять, и выбирать жесть жестяную, где уже в 1 месяц от старшИх нахватаешься.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 17:48 
*Если это не просто перечисление всех известных вам названий технологий
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 19:05 
На Java меньше всего, даже забыл. 9 лет назад. Я просто знаю, что жили нормально, всё работало.
А щаз с фаерфокса аликспрэсс глючит, авито глючит, ВК грузит 25МБ шлака, сообщение не отправляется через 2G.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 18:50 
Мне 32. За компом с 9 (игрушки мои компы не тянули). На всём этом приходилось. Начиная с ассемблера 486. Плюс тесно в команде коллеги были на всём этом в разное время. Больше всего работал и поныне с Си и Го. JS только для сборки фронта после мерджа.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 03-Ноя-22 06:14 
Как здорово что на опеннет есть настоящие программисты способные писать сразу на 6-7 и более языках.
Воистину талантливый человек талантлив во всем
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 18:52 
Про схемотехнику, органицию ЭВМ, ПЛИС, ассемблер -- я это всё универ с магистратурой.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 18:53 
Не кикбрейнс же проходил.
И да, PL/SQL Oracle я тоже очень хорошо знал 3 года назад, и даже может быть по-сеньерному.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 18:58 
вот с JS я не осилил, признаюсь. т.к. фрейморки это уже каждый из них космос, который сегодня есть, завтра дырявый и просит обновить с нарушением совместимости. только на чистом для эмбеда.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 18:59 
Еще сайт делал полностью под ключ на PHP + JQuery. 5 лет пашет, никакого вебмакакинга. Загружается весь контент через 2G без gzip на стороне NGINX. Макаки так не могут.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 13:51 
Память у вас хорошая. Касательно эмбеда верно: Си на бэке (Cortex M) или Go (Cortex A) + веб-морда с простейшим JS (НЕ доширак классов MMMMVVVVCCCC SPA). Несколько десятков килобайт даже без вебпаков, упакованных gzip nginx.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 13:56 
кто делает сервер на cortex m, тот конечно тоже не совсем адекват
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 13:51 
Про Раст не скажу, пока наблюдаю
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 13:53 
> typescript, react, dart sass, corejs

это всё нужно для SPA-PWA и прочий клей момент с жирным клиентом.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Без аргументов , 02-Ноя-22 13:57 
и кстати удачи в SEO со своими SPA
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено истина в последней инстанции , 03-Ноя-22 20:40 
> Опять ненастоящие Сишники, да что ж такое!

Опять где же настоящие растоманщики?

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:01 
OpenSSL, который мы заслужили.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:05 
>LibreSSL и BoringSSL, проблеме не подвержены

Ну так для этого и ответвились - всё говно, которое Google не счёл экономически эффективным подвергнуть аудиту, он просто оттуда выпилил.

Что настораживает - про GNU TLS - ни слова! Она тоже подвержена, просто эмбарго не истекло?

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 23:09 
У неё нет пользователей.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 08:42 
Причём тут GnuTLS? Они с OpenSSL ни разу не родственники.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено iZEN , 02-Ноя-22 09:15 
Часть софта при сборке из портов FreeBSD даёт выбор использовать GnuTLS или OpenSSL.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено bOOster , 02-Ноя-22 10:54 
А из исходников, в большинстве случаев, ты можешь использовать что угодно, что LibreSSL, что OpenSSL, что GnuTLS.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 13:14 
В большинстве случаев нет, в софте должна быть явная поддержка в коде. Я делал такую поддержку и понимаю почему не хотят тащить настолько лишнее. LibreSSL вообще нет, потому что он нигде толком не поддерживается.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:02 
>Уязвимости проявляются только в ветке OpenSSL 3.0.x,

А может 1. никто не проверяет просто? Ведь не new shiny shit, прошлый век, непрогрессивно тратить своё время на старьё?

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 05:25 
Скорее всего проверяют, ветка 1.х на приватной поддержке вроде.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:07 
https://github.com/mesalock-linux/mesalink - OpenSSL compatibility layer for the Rust SSL/TLS stack. Перекатываемся?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено DEF , 01-Ноя-22 20:12 
Как же достали эти уязвимости. Пора переходить на RusTLS.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:49 
Russian TLS?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено истина в последней инстанции , 03-Ноя-22 20:42 
Этого никогда не случиться. Потому что вы его никогда не допишете.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:13 
А разве Rust защищает от переполнения буффера/числа?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:24 
Один из багов в FF показал, что в расте надо так же ручками проверять вхождение индекса в массив. Это про тот самый случай, когда растаманы перепутали знаки больше-меньше.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:42 
Пруфы в студию.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 21:11 
см. багтрекер Мозилы
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 21:15 
Хаха, что и требовалось ожидать. Ты только языком трепаться можешь.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 09:00 
Не осиливаешь в поиск? Как ты вообще русский язык в прошлом году в 8-ом классе сдал?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Анонн , 01-Ноя-22 20:47 
А что происходит когда в расте ты таки обращаешься с массиву по неверному индексу?
Тоже RCE получаешь, или прога просто паникует?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 21:12 
в конкретно том случае всё делалось руками, в т.ч. кидание паники (неуместное, естественно, из-за перепутанного знака сравнения).
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 09:00 
Число просто переполняется и становится отрицательным больше ничего интересного не происходит.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 09:50 
> больше ничего интересного не происходит

интересное происходит ПОТОМ, когда оно используется в вычислении смещений...

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено freecoder , 03-Ноя-22 23:27 
Смотря как обращаешься. Если вызываешь 
.get(i)
 то этот метод возвращает опциональный результат. Если используешь синтаксис с прямоугольными скобками, то будет паника. Если вызываешь 
.get_unchecked(i)
 то в случае выхода за границу произойдет UB (этот метод unsafe).
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 23:41 
> Один из багов в FF показал, что в расте надо так же

Один из ветров показал, что они дуют, потому что деревья качаются.
https://git.openssl.org/gitweb/?p=openssl.git;a=blobdiff;f=c...
> ручками проверять вхождение индекса в массив. Это про тот самый случай,

Это тот самый случай, когда местные экспертусы-ламерье палятся по полной.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Rev , 01-Ноя-22 20:32 
Это одна из основных фитч, так-то.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:35 
читай выше.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 07:02 
Ты же ссылку не привел, что читать?
Твои больные фантазии?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:50 
> When you’re compiling in debug mode, Rust includes checks for integer overflow that cause your program to panic at runtime if this behavior occurs. Rust uses the term panicking when a program exits with an error; we’ll discuss panics in more depth in the “Unrecoverable Errors with panic!” section in Chapter 9.
>When you’re compiling in release mode with the --release flag, Rust does not include checks for integer overflow that cause panics. Instead, if overflow occurs, Rust performs two’s complement wrapping. In short, values greater than the maximum value the type can hold “wrap around” to the minimum of the values the type can hold. In the case of a u8, the value 256 becomes 0, the value 257 becomes 1, and so on. The program won’t panic, but the variable will have a value that probably isn’t what you were expecting it to have. Relying on integer overflow’s wrapping behavior is considered an error.

Что-то не работают основные фичи... Тогда спрашивается чем debug mode от динамического анализатора для Си/Цпп отличается? Его можно также не запускать и ошибки уйдут в релиз версию.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Анонн , 01-Ноя-22 20:53 
Работают если знаешь как: ошибка будет логическая, а не порча памяти.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 22:28 
А почему ты объединяешь эти проблемы? Переполнение числа и переполнение буфера абсолютно раные вещи.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено anonymous , 01-Ноя-22 20:19 
"от него кровопролитиев ждали, а он чижика съел". Ну и хорошо что так, зря только народ пугали таинственным эмбарго.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено ryoken , 02-Ноя-22 08:00 
>>"от него кровопролитиев ждали, а он чижика съел"

Салтыков-Щедрин, "Медведь на воеводстве". :)

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Самый умный из вас , 01-Ноя-22 20:20 
Хочешь не хочешь, а уже начинаешь верить в теории заговора, почему этот кусок критического г*вна не решились все же переписывать с нормальным проектированием и покрытием всевозможными тестами
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 02:24 
Дорого... плюс конеретно этот кусок используют все подряд, в нем уже залатали все что только можно и нельзя... и баг только в 3-й версии (новой), и проводит только к DoS в серверных дистрибутивах.  
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 02:26 
Иксы уже переписали... теперь имеется куча багов в новом модном wayland... решение которых очень простое, надо всего-лишь пользоватся иксами. 10 лет как делают, а все не готов.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:25 
Пустозвимость, из-за которой задержали выпуск новой Федоры.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено ryoken , 02-Ноя-22 08:01 
RawHide в помощь, и ваша Федора всегда будет настолько новой, что прям дальше некуда :D
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:37 
ну наконец-то libressl может похвастаться что хотя бы этой проблемы у них нет (правда, в любой древней версии ее точно так же нет)

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 08:46 
Вообще-то немало выявленных в OpenSSL уязвимостей не проявляются в LibreSSL. Обратное, кажется, всего один раз имело место.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено bOOster , 02-Ноя-22 08:58 
И это нам показывает реальное положение дел, что вообще много всяких помоев в Linux, невозможно в различных BSD.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 20:44 
Ахаха, впрочем ничего нового.
Фикс с ">" vs ">=" просто шикарен! И это в штуке, на которой пол-инета держится.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 21:08 
Дали сишнику два буфера: за один он вышел, а второму use-after-free сделал.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 21:25 
У Пети было 32 байта в буфере. 24 он отдал Маше, а оставшиеся 128 — Ване.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 01-Ноя-22 21:54 
у этой истории есть продолжение ... там где Петькины 24 байта застряли в Машкиных буферах.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Онаним. , 01-Ноя-22 23:57 
Хочешь сказать у Вани буфера больше, чем у Маши?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 10:18 
> У Пети было 32 байта в буфере. 24 он отдал Маше, а оставшиеся 128 — Ване.

Петя вставил данных Маше на 24, а Ване - на 128. На каком языке пишет Петя?

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 16:06 
скорее всего руби
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено penetrator , 01-Ноя-22 22:03 
В Ф36 будет пакет openssl-3.0.5-2.fc36, а не 3.0.7

Получается что это бэкпорт, и кстати, пакет еще не готов, а CVE уже раскрыли.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено анонимус , 01-Ноя-22 23:12 
Пусть страдают!
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Онаним. , 01-Ноя-22 23:56 
Кросавчеги.
У любителей тащить в рот сертификаты автоматом очко на минус уже наверняка сыграло.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Онаним. , 01-Ноя-22 23:58 
Хотя там и клиентского будет достаточно. К счастью, дело ограничилось 4 байтами.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 09:46 
> дело ограничилось 4 байтами

Эх, недоработали современные вебмакаки... В версии 4 сделают побольше переполнения.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 01:46 
А нельзя как-то добавить в C типы данных вроде срез и проверять переполнение, а еще типы данных список, вектор и т.д.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 02:21 
Зачем что-то добавлять оно уже давно есть, зовется с++.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 07:11 
Из с++ нужно как-то убрать сишные указатели на начало последовательности элементов которые они называют массивом. И указатель на начало последовательности char которые они называют строкой

Например изобрести unsafe

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 08:18 
std::span
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 08:53 
Если для ваших задач не нужен именно C++, это не значит, что и всем остальным для их задач он тоже не подходит.

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

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 09:39 
>>> никто для вашего душевного спокойствия менять не будет <<<

как говорится никогда не говорите никогда: master, slave, blacklist... и кто знает что они придумают ещё.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 10:15 
Причем здесь терминология? Паскаль например тоже больше 50 лет назад появился. Но там почему-то уже были настоящие строки с размером и настоящие массивы (а не указатели на начало) с границами.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 10:21 
А в С++ строки и вектора они появились только в стандарте C++ 2003
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 10:24 
В 2012 на С++ еще в каждой крупной библиотеке еще изобретали свои строки вместо std:string
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 10:50 
> изобретали свои строки вместо std:string

Кутэ тому пример.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 16:04 
ладно qt, свои строки были даже в Ogre 3D и вроде бы wxwidget
Ну вот зачем библиотеке для 3D графики собственный аналог std:string?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 18:48 
Когда Qt разрабатывали std:string ещё небыло.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 13:28 
Это просто показывает насколько удобна, продумана и универсальна эталонная реализация в std
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 18:50 
Или то насколько сложно перевести уже существующий продукт на новую библиотеку с полностью другим API.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 09:41 
> как-то убрать сишные указатели

Очень простой рецепт: не используй указатели :)

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 18:44 
Зачем убирать? Просто не используй.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено iZEN , 02-Ноя-22 09:18 
Многого хотите - в Си ещё строки не определены в базовых типах. До сих пор пользуются последовательностью байтов, конец которой обозначается нулём, и алгоритмом маляра Шлемиля для определения конца и добавления новых данных.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 09:45 
А паскаль-то не так уж и плох, как его ругают сишники...
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 03-Ноя-22 16:14 
Просто в Паскале компилятор самолично высчитывает длину строки. А в Си компилятор не высчитывает длину строки, длину строки считает программсит.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено n00by , 03-Ноя-22 17:25 
На самом деле Си транслятор точно так же знает длину «строки» на этапе трансляции. Иначе он бы не смог бы разместить её в объектном файле.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Ivan_83 , 02-Ноя-22 11:09 
Потому что строки это синтаксический сахар.
Есть только области памяти с данными, большего не надо.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 12:03 
> строки это синтаксический сахар

Ошибаешься...

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 03-Ноя-22 16:12 
> строки это синтаксический сахар
>>Ошибаешься...

Он не ошибается. А твоё умозаключение приведёт тебя прямиком в ООП языки.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 04-Ноя-22 02:00 
фу фу фу, не надо тогда нам этого сахара. сегодня сахарка поюзал, а завтра уже с женщинами спишь и об ооп думаешь. фуу гадость
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 10:09 
Уязвимость не стали признавать критической только потому что в ubuntu и redhat включили защиту стэка в настройках компилятора?
Какое вообще отношение настройки компилятора имеют к уязвимостям в openssl?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 10:12 
> Уязвимость не стали признавать критической только потому что в ubuntu и redhat

И всё, точка.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 10:35 
Лично мне кажется что чем больше выполняется проверок компилятором и статическим анализатором тем лучше.
Органическая нейросеть работающая на химических реакциях и движении ионов, какой бы недостижимо большой она не была, всегда будет скована этой самой химической природой.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 10:48 
> Органическая нейросеть работающая на химических реакциях и движении ионов, какой бы недостижимо большой она не была, всегда будет скована

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

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 11:58 
мне всё равно что там не смогли сделать "растоманы"
в kotlin очень много проверок на стадии компиляции и меня это устраивает.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 12:02 
софта на котлине - как на брейнфаке.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 14:30 
Это ты так решил?
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 17:16 
Это котлята столько написали.
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 16:00 
Значительная часть мобильных приложений для андроид, некоторые для ios через kotlin mmp и бэкэнд много где написан на котлине.

Например в нашей организации мобильное приложение и часть биллинга, то есть больше чем среднестатистический opennet эксперт написал за всю свою жизнь.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 17:18 
> Например в нашей организации

В моей организации 100500 работников и 9000 манагеров - и никто котлин не использует.

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 02-Ноя-22 16:27 
Переходим на bearssl! Долой выделение памяти!
"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 03-Ноя-22 08:12 
Братья сишники спасайте, мне что теперь, от телефона отказываться?

In Android, Kleidermacher says a lot of encryption-key-management features are now written in Rust, as is the private internet communication feature DNS over HTTPS, a new version of the ultra-wideband chip stack, and the new Android Virtualization Framework used in Google's custom Tensor G2 chips. He adds that the Android team is increasingly converting connectivity stacks like those for Bluetooth and Wi-Fi to Rust because they are based on complex industry standards and tend to contain a lot of vulnerabilities. In short, the strategy is to start getting incremental security benefits from converting the most exposed or vital software components to Rust first and then working inward from there.
https://www.wired.com/story/rust-secure-programming-language.../

"Переполнение буфера в OpenSSL, эксплуатируемое при проверке ..."
Отправлено Аноним , 03-Ноя-22 15:32 
Переходить на iphone, там нет ненавистного местным экспертам раста