The OpenNET Project / Index page

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

Универсальный способ DoS-атаки, затрагивающий PHP, Java, Ruby, Python и различные web-платформы

30.12.2011 10:22

На проходящей в Берлине конференции Chaos Communication Congress (28c3) обнародован новый способ нарушения работоспособности web-сервисов, основанный на особенности реализации структур хэшей, используемых для организации хранения наборов данных в представлении ключ/значение, в широком спектре языков программирования. Манипулируя используемыми в качестве ключей данными, атакующий может затратив минимальные ресурсы инициировать возникновение предсказуемых коллизий в алгоритме хэширования, разрешение которых требует дополнительных значительных процессорных ресурсов.

Большинство web-фреймворков и web-приложений на этапе разбора HTTP POST-запроса автоматически размещают передаваемые пользователем параметры в хэше, что позволяет атакующему контролировать наполнение хэша. В зависимости от языка программирования для достижение 100% загрузки CPU достаточно сформировать поток запросов интенсивностью всего в несколько килобит в секунду. При этом степень создаваемой нагрузки пропорциональна размеру передаваемого в хэш числа ключей с коллизиями. Хэш-функция генерирует на основании строки 64- или 32-разрядное целое число, при возникновении коллизии две разные входные строки дают одинаковое итоговое число. При обнаружении коллизии в хэш-функциях используются различные методы для обеспечения хранения вызывающих коллизии значений, как правило требующие дополнительного перебора и сверки значений (совпадающие значения сохраняются в виде дерева или линейного списка). Трудоёмкость добавления "n" проблемных ключей составляет O(n**2), т.е. на разбор большого числа вызывающих коллизии ключей современному CPU могут потребоваться часы.

Например, при лимите на размер POST запроса в 1 Мб, Python фреймворк Plone тратит около 7 минут процессорного времени на запись в хэш 1 Мб данных (набор специально оформленных ключей), вызывающих коллизии (для успешной DoS-атаки на CPU Core Duo достаточно потока в 20 kbit/s). Для фреймворков на языке Ruby 1.8.7 при лимите на размер POST-запроса в 2 Мб на парсинг двухмегабайтного блока данных на CPU i7 будет потрачено около 6 часов (!), т.е. для поддержания постоянной 100% нагрузки достаточно потока в 850 бит в секунду. Для PHP разбор POST-запроса размером 300 Кб занимает примерно 30 секунд процессорного времени, 500 Кб - минуту, 8 Мб - около 5 часов.

Проблеме подвержены все языки программирования и фреймворки, в которых не используется дополнительная рандомизация значений в функциях хэширования, например, уязвимы Java (Tomcat, Geronimо, Jetty, Glassfish), JRuby, PHP, Python, Rubinius, Ruby 1.8.7, V8 JavaScript Engine и ASP.NET. Проблема не затрагивает язык Perl и ветку Ruby 1.9.x, так как в этих языках уже используется внесение случайных изменений при формировании хэшей. В Perl проблема была устранена ещё в 2003 году, после публикации отчёта о возможности совершения подобной атаки. В PHP уязвимость исправлена в версии 5.4.0RC4, также планируется выпустить корректирующий релиз PHP 5.3.9. Проблема также исправлена в CRuby 1.8.7-p357, JRuby 1.6.5.1, Apache Tomcat 5.5.34/6.0.34/7.0.22, Rack 1.4.0/1.3.6/1.2.5/1.1.3. Эксплуатация проблемы в Python и Ruby имеет дополнительные нюансы, отличающиеся для 64- и 32-разрядных сборок.

Предсказать вызывающие коллизии значения не представляет труда, так как в вышеупомянутых языках как правило используются две реализации хэш-функций DJBX33A и DJBX33X, разработанные Дэниэлом Бернштейном (Daniel Bernstein, автор qmail и djbdns). Хэш-функция DJBX33A используется в PHP5, Ruby 1.8 и Java. DJBX33X в PHP4, ASP.NET, Python и JavaScript (v8). Кроме языков программирования данные хэш-функции применяются в широком спектре проектов, от ядра Linux до социальной сети Facebook, а также в таких языках, как Lua, Erlang и Objective-C, что открывает возможные новые векторы для атак.

В качестве мер для минимизации влияния представленной атаки называется ограничение максимального процессорного времени, затрачиваемого на выполнение скрипта (RLimitCPU в Apache или max_input_time в настройках PHP), ограничение максимального размера POST-запроса (для PHP - post_max_size) и ограничение максимального числа разбираемых параметров (в php 5.4 или suhosin-сборке PHP - suhosin.post.max_vars и suhosin.request.max_vars).

  1. Главная ссылка к новости (https://cryptanalysis.eu/blog/...)
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/32698-hash
Ключевые слова: hash, java, ruby, python, dos, attack, security, web
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (50) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Анонимоус (?), 11:45, 30/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    хмм.. а в Германии, оказывается, куча спецов по компьютерной безопасности
     
     
  • 2.5, Аноним (-), 12:58, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    http://en.wikipedia.org/wiki/Chaos_Computer_Club
     
     
  • 3.16, pavlinux (ok), 15:41, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    4-й рейх? :)
     
     
  • 4.28, Аноним (-), 20:42, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 4-й рейх? :)

    0xC3-й.

     
     
  • 5.45, pavlinux (ok), 03:37, 31/12/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> 4-й рейх? :)
    > 0xC3-й.

    https://en.wikipedia.org/wiki/Chaos_Computer_Club
    The CCC is based in Germany and other German-speaking countries.

    Я вот так, навскидку, сразу и не вспомню "other German-speaking countries" :)
    Австрия если только,...

     
     
  • 6.47, лки Новый Год (?), 06:22, 31/12/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >""Я вот так, навскидку, сразу и не вспомню "other German-speaking countries" :)

    Австрия если только,... ""

    С википедии:

    Germany
    Austria
    Switzerland
    Liechtenstein

    да и в соседних областях той же Чехии и Польши многие жители говорят/понимают по немецки

     
     
  • 7.65, pavlinux (ok), 20:13, 31/12/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > С википедии:

    Ключевое слово "навскидку", то есть из мозга. :)

    А как один из государственных, в Бельгии ещё.

     
  • 6.72, anonymous (??), 09:41, 02/01/2012 [^] [^^] [^^^] [ответить]  
  • +/
    бывшие германские колонии?
     
     
  • 7.73, Линуся (?), 17:20, 02/01/2012 [^] [^^] [^^^] [ответить]  
  • +/
    бывшие немецкие территории, до мировых войн...
     

  • 1.2, Аноним (-), 11:51, 30/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    тоесть в чём суть исправления как я понимаю:

    ...при создании каждого Хэш-объекта (Хэш-словаря) -- в него должно записываться случайная переменная "R" (так её условно назовём)

    затем при помещении/извлечении в каждый такой Хэш-Словарь Key/Value значений -- необходимо делать операцию "Real_Key = Key XOR R"

    вродебы не сложно :-)

     
     
  • 2.23, arisu (ok), 19:24, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    суть исправления в том, чтобы подсаливать хэш рандомными (но, натурально, постоянными для одного сеанса) значениями.
     

  • 1.3, Oleksiy Kovyrin (?), 12:32, 30/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Так как для Ruby EE патча еще нет, то мы портировали решение из последнего Ruby 1.8.7: http://kovyrin.net/2011/12/29/ree-hash-collision-patch/
     
  • 1.4, ЬТЛ (?), 12:53, 30/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    приятно что такие решения "отдают" для фикса, а не используют.
     
     
  • 2.14, const86 (ok), 15:29, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Точно не используют? Может, уже извлекли, так сказать, выгоду и настало время подумать о совести :) Да и после публикации вполне можно использовать, пока везде не пофиксят.
     
     
  • 3.20, oxyum (ok), 18:18, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    ...годика эдак 2... а кое-где и все 5 лет... :(
     
     
  • 4.25, Аноним (-), 19:44, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В новости сказано, что в Perl проблема исправлена уже в 2003 г, т.е. проблема известна 9 лет, а то и больше. Все кому надо успели попользоваться )
     

  • 1.6, YetAnotherOnanym (?), 13:08, 30/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Изящно и утончённо :)
     
  • 1.7, Анонимус 84705648 (?), 13:15, 30/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?
     
     
  • 2.9, Аноним (-), 13:19, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?

    В хэш netfilter произвольное значение не передать, там жестко структурированные значения, типа ip и номера порта.

     
     
  • 3.11, Анонимус 84705648 (?), 13:56, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    ну, можно, например, попробовать зафлудить целевой узел udp-пакетами с поддельными src_ip:src_port, причём src_ip:src_port выбирать так, чтобы хеш в netfilter получался всегда одинаковым
     
     
  • 4.66, XoRe (ok), 04:18, 01/01/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > ну, можно, например, попробовать зафлудить целевой узел udp-пакетами с поддельными src_ip:src_port,
    > причём src_ip:src_port выбирать так, чтобы хеш в netfilter получался всегда одинаковым

    Боюсь, 95% трафика идет с одинаковыми параметрами "src_ip:src_port".
    Как передаются файлы по ftp - договорились насчет src_port+dst_port и понеслась.
    За одно соединение можно миллиарды пакетов передать.
    По UDP тоже самое - nfs и netbios предполагают большое число пакетов с одинаковыми параметрами.
    Ниже указали строчку из исходников nf_conntrack.
    Я думаю, в ядре эту дырку закрыли ещё раньше, чем в perl.

     
  • 3.13, фклфт (ok), 15:29, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вы не поверите но я уже несколько раз за последние года 4 у себя в логах замечал... большой текст свёрнут, показать
     
     
  • 4.29, Аноним (-), 20:45, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > у себя в логах замечал попытку добавления правила на фаере

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

     
     
  • 5.40, Аноним (-), 23:15, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Чувак, я не хочу тебя расстраивать, но у тебя кажется на серваке
    > что-то идет не так. Понимаешь, правила сами по себе добавляться не
    > могут. Добавить их может троянец, хакер, ну или ты сам. Ремотное
    > добавление правил как-то не предусмотрено дизайном айпитаблеса само по себе.

    Есть такая штука - libvirt. Считает, что гораздо лучше админа знает, какие правила должны быть в iptables. Ее происки легко узнать по ключевым словам "192.168.122.0/24" и "virbr0".

     
     
  • 6.44, 12у34 (?), 03:12, 31/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    поясните каким образом связаны библиотека для виртуализации и iptables.
     
     
  • 7.46, Аноним (-), 05:06, 31/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрите на список правил до и после запуска libvirtd.
     
  • 2.17, Аноним (-), 16:34, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?

    Нет, там используются хеши Дженкинса.

     
     
  • 3.24, arisu (ok), 19:36, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >> интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?
    > Нет, там используются хеши Дженкинса.

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

     
     
  • 4.27, Аноним (-), 20:37, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если использовать криптографически стойкое хеширование да еще индивидуальной соли добавить - искать коллизии станет довольно утомительно, разве нет? Правда скорость будет заметно хуже.
     
     
  • 5.49, Аноним (-), 13:45, 31/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Если использовать криптографически стойкое хеширование да еще индивидуальной соли добавить
    > - искать коллизии станет довольно утомительно, разве нет? Правда скорость будет
    > заметно хуже.

    наверно в нашем случае достаточно всего лишь "индивидуальной соли добавить" :-)

    ведь сложновато найти коллизию хэша, если даже само хэш-значение не отображается в наружу :-) :-)

     
  • 4.39, Аноним (-), 23:12, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > я тебе сейчас секрет скажу, только ты присядь сначала: от типа хэш-функции наличие/отсутствие уязвимости не зависит.

    Ну найдите мне хоть коллизию для conntrack tuple, а то языком трепать все горазды :D

     
  • 2.42, Аноним (-), 23:50, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?

    Судя по строчке из nf_conntrack_core.c
    > return jhash2((u32 *)tuple, n, zone ^ nf_conntrack_hash_rnd ^ (((__force __u16)tuple->dst.u.all << 16) | tuple->dst.protonum));

    там используется добавление случайной соли (nf_conntrack_hash_rnd), так что плакали все коллизии :)

     

  • 1.18, vasek (?), 17:52, 30/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    оп, Perl и CRuby молодцом =)
     
  • 1.19, Аноним (-), 18:11, 30/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    для asp.net пофиксили сразу
    давно в винапдейтах
     
     
  • 2.41, Аноним (-), 23:21, 30/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > для asp.net пофиксили сразу

    Не сразу, а с опозданием на 8 лет. Сразу - это в перле пофиксили.
    Мелокософт, как обычно, "заботится" о безопасности.

     

  • 1.35, evgeny_t (ok), 22:37, 30/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    c таким прогрммирование страно что мир ещё работает )
     
     
  • 2.67, XoRe (ok), 04:20, 01/01/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > c таким прогрммирование страно что мир ещё работает )

    Тссс, никому не говорите)

     

  • 1.36, evgeny_t (ok), 22:39, 30/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    да проще взять дерево и всё будет ок )
     
  • 1.43, svn (??), 01:05, 31/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Проще не дерево, а обрабатывать параметны по мере получения. А не так как делает пыхпых читая мегабайты, засовывая их в хешмап, даже если обработчик post запроса вообще не нуждается в параметрах.

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

    Скрипты обязать регистрировать входные параметры ПЕРЕД началом обработки полученных от клиента данных, чтобы все не заявленные данные post запроса игнорировались. Ключи хеша определяются на стороне сервера - значит нет проблемы.

     
     
  • 2.50, Аноним (-), 13:50, 31/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Проще не дерево, а обрабатывать параметны по мере получения. А не так
    > как делает пыхпых читая мегабайты, засовывая их в хешмап, даже если
    > обработчик post запроса вообще не нуждается в параметрах.
    > В стандарт http добавить порядок параметров, чтобы авторизация шла первой.
    > Скрипты обязать регистрировать входные параметры ПЕРЕД началом обработки полученных от
    > клиента данных, чтобы все не заявленные данные post запроса игнорировались. Ключи
    > хеша определяются на стороне сервера - значит нет проблемы.

    всё это предложенное -- замечательно :-) .. но если предположить что уязвимость в хэш-словарях не будет исправлена -- то сёравно найдётся какойто другой (НЕ унивирсальный для каждого сайта) способ её заэксплуатировать!

     
  • 2.51, Аноним (-), 13:58, 31/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В стандарт http добавить порядок параметров, чтобы авторизация шла первой.

    а она первой и идёт там...

    ...там header-поле "WWW-Authenticate: ..." (а уж только потом ниже передаётся тело POST-запроса)

    нужно просто поголовно ВЕЗДЕ использовать AJAX на WWW-страницах. доступ к полю "WWW-Authenticate: ..." у XMLHttpRequest-объекта вполне себе есть, например. а также надо забить на MsIE (для которого AJAX пришлось бы делать индивидуально) и забить на нытиков, которые используют NoScript :)

    получилибы вообще от  AJAX сполшные плюсы! шаблонизировать страницу сайта (на стороне сервера) при каждом запросе не пришлосьбы.. HTTP-данные лишнии при каждом запросе пересылать не пришлосьбы тоже. скорость интернета увеличилась бы, и былобы щастье :-)

     
     
  • 3.52, Аноним (-), 14:02, 31/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    поясню немного глубже...

    header-поле "WWW-Authenticate: ..." не обязательно использовать только для BASIC аудентификации. туда можно (и это НЕ хак!) запихнуть любой вид значения, которое программист щитает что необходим для аудентификации пользователя для авторизации действия.... например можно указать:

    WWW-Authenticate: SESSION_ID 1234abc124acb123abc123abc

     
  • 3.69, terr0rist (ok), 16:36, 01/01/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не пишите ересь. Чем AJAX HTTP-запрос отличается от обычного? вам не приходит в голову, что AJAX - это не протокол, и даже не модификация протокола, а всего лишь способ послать запрос из браузера без перезагрузки страницы? Объект XMLHttpRequest не имеет никакого отношения к методам хеширования, авторизации, разбора заголовков или распития спиртных напитков на сервере.
    > скорость интернета увеличилась бы

    да, конечно, в 100 раз. По 100-мбитной сети сразу до 10Гб. Вы даже не знаете, что интернет - это не только НТТР и "лишние НТТР-данные" (НТТР-заголовки) - это наверно одна квинтиллионная всего трафика. Хотя что говорить, аноним такой аноним.

     
     
  • 4.76, Аноним (-), 14:46, 03/01/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    всмысле если обычный -- это form form -- то отличия весьма очевидны... большой текст свёрнут, показать
     
  • 2.64, Аноним (-), 20:05, 31/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вот всегда находится какой-нибудь <вырезано цензурой>, который предлагает ошибки реализации исправлять переделывая протокол.
     
     
  • 3.71, Аноним (-), 04:27, 02/01/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот всегда находится какой-нибудь <вырезано цензурой>, который путает ошибки реализации с ошибками архитектуры.
     

  • 1.59, Денис (??), 17:17, 31/12/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Для php 5.2 тоже патчи вышли
    https://github.com/laruence/laruence.github.com/tree/master/php-5.2-max-input-
     
     
  • 2.74, Аноним (-), 21:18, 02/01/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Уйдет в порты FreeBSD в 5.2.17_5 http://www.freebsd.org/cgi/query-pr.cgi?pr=163782 и в centos.alt.ru уже есть http://centos.alt.ru/?p=647
     

  • 1.75, Аноним (-), 10:20, 03/01/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я все жду когда в PHP появиться поддержка распарсить параметер по требованию. Что-то вроде $_POST->getParam. А распарсеные параметры уже закешировать в этих ваших HASH и хранить.

    P.S. Кстати проблема только на ключах HASH я так понимаю?!

     
     
  • 2.79, Аноним (-), 19:53, 03/01/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Я все жду когда в PHP появиться поддержка распарсить параметер по требованию.
    > Что-то вроде $_POST->getParam. А распарсеные параметры уже закешировать в этих ваших
    > HASH и хранить.

    Какая хакеру разница, заткнется сервак сам по себе или по твоему требованию :)

     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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