Опубликовано обновление системы кэширования данных в оперативной памяти Memcached 1.6.2, в котором устранена уязвимость, позволяющая инициировать крах рабочего процесса через отправку специально оформленного запроса. Уязвимость проявляется начиная с выпуска 1.6.0. В качестве обходного пути защиты можно отключить бинарный протокол для внешних запросов через запуск с опцией "-B ascii"...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52603
> размер определяется на основе параметра, указанного в заголовке запроса
>
> переполнение буфераДетям нельзя давать спички. Алкоголикам нельзя доверить деньги. А сишников ни в коем случае нельзя подпускать к буферу.
> инициировать переполнение буфера, приводящее к краху рабочего процесса.Писали бы на расте, тоже получили бы крах процесса. Хотя переполнения буфера бы не было, конечно. Попытка переполнить его обломалась бы с паникой.
- Дедушка, а бывает раст без unsafe?
- Нет, внучек, это фантастика.
> - Дедушка, а бывает раст без unsafe?
> - Нет, внучек, это фантастика.Мне вот интересно, что надо сказать анониму опеннета, чтобы тот понял наконец, что он не может сказать мне про unsafe в rust'е ничего, чего я бы не знал? Что он вообще мне ничего о расте не может сказать, чего я бы не знал. Какая словесная формулировка может мне помочь пробить дубовый череп анонима с опеннета и донести до него эту простую мысль?
Или я тебя не понял, и ты сам хочешь что-то у меня узнать про unsafe? Если так, то не стесняйся, не ходи вокруг да около, а задай вопрос прямо. Будь мужиком, блеа...
> Писали бы на расте...или на Ada, или на C++, в них тож памятью можно автоматически управлять. но не писали.
> ... тоже получили бы крах процесса. Хотя переполнения буфера бы не было, конечно.
переполнения действительно бы не было, как и ни одной рабочей реализации memcached.
безопасность - это хорошо конечно, но программистам нужны готовые, рабочие инструменты.
> Детям нельзя давать спички. Алкоголикам нельзя доверить деньги. А сишников ни в коем случае нельзя подпускать к буферу.Анонимуса ни в коем случе нельзя пускать в комментарии
Не сишников, а фейсбуковских программистов, учившихся программировать на примере php.У тех сишников, которые изначально разрабатывали мемкеш, подобных проблем не возникало.
Это были ненастоящие шотландцы!!1
Очередная сишная дырень?
И на чём же писать тогда, умный человек?
Rust
А ты или кто-то уже написали годный и полноценный продукт на Rust и можете с уверенностью сказать что было бы лучше.Например (из того что не хватает лично мне и многим кого знаю):
1) Нормальный почтовый клиент, уровня kmail из kde3. Чтобы нормально подхватывал системные темы и настройки, в идеале на выход интерфейс умел и qt и gtk. Кому что больше нравиться.
Не?2) Нормальную IDE на Rust для Rust. Не редактор текста с подсветкой синтаксиса и конфликтующими плагинами, а именно IDE, поставил и работай. С теми же требованиями к интерфейсу?
Не?Брайзер я не упоминаю, браузер у меня уже есть нормальный (не хром и не firefox).
Появиться - дайте знать. С удовольствием посмотрю.
Конечно, у Си есть недостатки, однако, давайте будем вещи называть своими именами.
Виноваты,
во-первых: стандартная библиотека языка Си, а не сам язык Си (а это две абсолютно разные вещи)!
во-вторых:
программист, который не знает то, как правильно использовать элементы стандартной библиотеки (плохому танцору, сами прекрасно знаете что мешает)!
Канеш виновато всё на свете, кроме самого Си. То, что подавляющая часть дыр и багов вообще - следствие некорректной работы с памятью, видимо, вас не смущает.
Прежде чем сваливать вину на стандартную библиотеку сходи и посмотри на патч. Там явно видно, что программист не справился с вычислениями размеров. Он забыл про '\0', и соответственно не увеличил размер буфера на единичку, и потом ещё забыл проверить размер копируемых данных: буфер выделяется на стеке, размер его задан статически, а extlen берётся, как я понимаю из внешних данных, и может оказаться больше допустимого.А прежде чем сваливать вину на программиста, сходи и посмотри на git blame: я сам этого не делал, поэтому не скажу, насколько твои обвинения попадают в цель, но если ты не заглядывал в git blame, то под твоими обвинениями совершенно определённо нет никаких оснований, это взятые с потолка обвинения. Хотя git blame не всегда даёт ответ -- иногда дыра возникает из-за изменений в стороннем коде, который после очередного патча вдруг начинает пропускать невалидные данные.
ДополнюИщещь виноватого? А насколько ты компетентен в вопросе? Покажи свой профиль на github. А то у нас каждая кухарка знает, как управлять государством, и каждый школьник знает, как писать большие проекты
> Он забыл про '\0', и соответственно не увеличил размер буфера на единичкуО каком '\0' ты говоришь? Show me the code.
Нуль-терминатор же, классика. Если у тебя стандартизирована длина строки (например, WPA password не более 63 символов), то размер буфера надо сделать на 1 больше (в частности, 64 байта)
Не спеши рассказывать мне очевидные вещи. Лучше покажи, где в обсуждаемом коде в последний байт буфера extbuf записывается '\0' или ещё что-либо.
Я даже в код не смотрел, так как не использую Memcached нигде -- не заинтересован
А так сорян -- экспертиза анонимуса опеннета в среднем требует объяснения элементарного
>Он забыл про '\0'Там это, нуль только в asciiz и в релевантных функциях работы со строками -- с памятью не обязательно работать как с нуль-терминированными строками (более того, это может быть менее эффективно на больших массивах данных). Нужно только учитывать, что некоторые функции будут помещать нуль последним элементом строки, т.е. твоя строка должна быть либо на 1 байт меньше, либо памяти должно быть на 1 байт больше (последнее зачастую вызывает повышенную фрагментацию и неэффективную работу)