The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Обновление Memcached 1.6.2 с устранением уязвимости

24.03.2020 21:40

Опубликовано обновление системы кэширования данных в оперативной памяти Memcached 1.6.2, в котором устранена уязвимость, позволяющая инициировать крах рабочего процесса через отправку специально оформленного запроса. Уязвимость проявляется начиная с выпуска 1.6.0. В качестве обходного пути защиты можно отключить бинарный протокол для внешних запросов через запуск с опцией "-B ascii".

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

  1. Главная ссылка к новости (https://github.com/memcached/m...)
  2. OpenNews: Релиз Memcached 1.6.0 с включением поддержки внешнего хранилища
  3. OpenNews: Компания Apple открыла код распределённой СУБД FoundationDB
  4. OpenNews: Выпуск СУБД Redis 5.0
  5. OpenNews: Критические уязвимости в Memcached
  6. OpenNews: Выпуск документоориентированной СУБД Apache CouchDB 3.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52603-memcached
Ключевые слова: memcached
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (21) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 22:16, 24/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > размер определяется на основе параметра, указанного в заголовке запроса
    >
    > переполнение буфера

    Детям нельзя давать спички. Алкоголикам нельзя доверить деньги. А сишников ни в коем случае нельзя подпускать к буферу.

     
     
  • 2.5, Ordu (ok), 23:28, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > инициировать переполнение буфера, приводящее к краху рабочего процесса.

    Писали бы на расте, тоже получили бы крах процесса. Хотя переполнения буфера бы не было, конечно. Попытка переполнить его обломалась бы с паникой.

     
     
  • 3.8, Аноним (8), 00:48, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    - Дедушка, а бывает раст без unsafe?
    - Нет, внучек, это фантастика.
     
     
  • 4.9, Ordu (ok), 01:15, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > - Дедушка, а бывает раст без unsafe?
    > - Нет, внучек, это фантастика.

    Мне вот интересно, что надо сказать анониму опеннета, чтобы тот понял наконец, что он не может сказать мне про unsafe в rust'е ничего, чего я бы не знал? Что он вообще мне ничего о расте не может сказать, чего я бы не знал. Какая словесная формулировка может мне помочь пробить дубовый череп анонима с опеннета и донести до него эту простую мысль?

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

     
  • 3.11, leap42 (ok), 04:02, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Писали бы на расте...

    или на Ada, или на C++, в них тож памятью можно автоматически управлять. но не писали.

    > ... тоже получили бы крах процесса. Хотя переполнения буфера бы не было, конечно.

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

    безопасность - это хорошо конечно, но программистам нужны готовые, рабочие инструменты.

     
  • 2.6, kai3341 (ok), 23:56, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Детям нельзя давать спички. Алкоголикам нельзя доверить деньги. А сишников ни в коем случае нельзя подпускать к буферу.

    Анонимуса ни в коем случе нельзя пускать в комментарии

     
  • 2.13, Аноним (13), 08:01, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не сишников, а фейсбуковских программистов, учившихся программировать на примере php.

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

     
     
  • 3.17, Аноним (1), 14:03, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это были ненастоящие шотландцы!!1
     

  • 1.2, Fracta1L (ok), 22:31, 24/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    Очередная сишная дырень?
     
     
  • 2.3, Аноним (3), 23:06, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И на чём же писать тогда, умный человек?
     
     
  • 3.4, Анончик9999 (?), 23:27, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Rust
     
     
  • 4.23, deeaitch (ok), 02:22, 27/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ты или кто-то уже написали годный и полноценный продукт на Rust и можете с уверенностью сказать что было бы лучше.

    Например (из того что не хватает лично мне и многим кого знаю):

    1) Нормальный почтовый клиент, уровня kmail из kde3. Чтобы нормально подхватывал системные темы и настройки, в идеале на выход интерфейс умел и qt и gtk. Кому что больше нравиться.
    Не?

    2) Нормальную IDE на Rust для Rust. Не редактор текста с подсветкой синтаксиса и конфликтующими плагинами, а именно IDE, поставил и работай. С теми же требованиями к интерфейсу?
    Не?

    Брайзер я не упоминаю, браузер у меня уже есть нормальный (не хром и не firefox).

    Появиться - дайте знать. С удовольствием посмотрю.

     
  • 2.12, nonamenogame (?), 07:54, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Конечно, у Си есть недостатки, однако, давайте будем вещи называть своими именами.
    Виноваты,
    во-первых: стандартная библиотека языка Си, а не сам язык Си (а это две абсолютно разные вещи)!
    во-вторых:
    программист, который не знает то, как правильно использовать элементы стандартной библиотеки (плохому танцору, сами прекрасно знаете что мешает)!
     
     
  • 3.14, Fracta1L (ok), 08:19, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Канеш виновато всё на свете, кроме самого Си. То, что подавляющая часть дыр и багов вообще - следствие некорректной работы с памятью, видимо, вас не смущает.
     
  • 3.15, Ordu (ok), 10:27, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Прежде чем сваливать вину на стандартную библиотеку сходи и посмотри на патч. Там явно видно, что программист не справился с вычислениями размеров. Он забыл про '\0', и соответственно не увеличил размер буфера на единичку, и потом ещё забыл проверить размер копируемых данных: буфер выделяется на стеке, размер его задан статически, а extlen берётся, как я понимаю из внешних данных, и может оказаться больше допустимого.

    А прежде чем сваливать вину на программиста, сходи и посмотри на git blame: я сам этого не делал, поэтому не скажу, насколько твои обвинения попадают в цель, но если ты не заглядывал в git blame, то под твоими обвинениями совершенно определённо нет никаких оснований, это взятые с потолка обвинения. Хотя git blame не всегда даёт ответ -- иногда дыра возникает из-за изменений в стороннем коде, который после очередного патча вдруг начинает пропускать невалидные данные.

     
     
  • 4.16, kai3341 (ok), 10:58, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дополню

    Ищещь виноватого? А насколько ты компетентен в вопросе? Покажи свой профиль на github. А то у нас каждая кухарка знает, как управлять государством, и каждый школьник знает, как писать большие проекты

     
  • 4.18, Ололо (?), 08:30, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Он забыл про '\0', и соответственно не увеличил размер буфера на единичку

    О каком '\0' ты говоришь? Show me the code.

     
     
  • 5.19, kai3341 (ok), 14:11, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нуль-терминатор же, классика. Если у тебя стандартизирована длина строки (например, WPA password не более 63 символов), то размер буфера надо сделать на 1 больше (в частности, 64 байта)
     
     
  • 6.20, Ололо (?), 14:15, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не спеши рассказывать мне очевидные вещи. Лучше покажи, где в обсуждаемом коде в последний байт буфера extbuf записывается '\0' или ещё что-либо.
     
     
  • 7.21, kai3341 (ok), 15:01, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я даже в код не смотрел, так как не использую Memcached нигде -- не заинтересован
    А так сорян -- экспертиза анонимуса опеннета в среднем требует объяснения элементарного
     
  • 4.22, Аноним (22), 16:29, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Он забыл про '\0'

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру