На проходящей в Берлине конференции Chaos Communication Congress (28c3) обнародован (http://www.ocert.org/advisories/ocert-2011-003.html) новый способ нарушения работоспособности web-сервисов, основанный (https://cryptanalysis.eu/blog/2011/12/28/effective-dos-attac.../) на особенности реализации структур хэшей, используемых для организации хранения наборов данных в представлении ключ/значение, в широком спектре языков программирования. Манипулируя используемыми в качестве ключей данными, атакующий может затратив минимальные ресурсы инициировать возникновение предсказуемых коллизий в алгоритме хэширования, разрешение которых требует дополнительных значительных процессорных ресурсов.
Большинство web-фреймворков и web-приложений на этапе разбора HTTP POST-запроса автоматически размещают передаваемые пользователем параметры в хэше, что позволяет атакующему контролировать наполнение хэша. В зависимости от языка программирования для достижени...URL: https://cryptanalysis.eu/blog/2011/12/28/effective-dos-attac.../
Новость: http://www.opennet.me/opennews/art.shtml?num=32698
хмм.. а в Германии, оказывается, куча спецов по компьютерной безопасности
http://en.wikipedia.org/wiki/Chaos_Computer_Club
4-й рейх? :)
> 4-й рейх? :)0xC3-й.
>> 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" :)
Австрия если только,...
>""Я вот так, навскидку, сразу и не вспомню "other German-speaking countries" :)Австрия если только,... ""
С википедии:
Germany
Austria
Switzerland
Liechtensteinда и в соседних областях той же Чехии и Польши многие жители говорят/понимают по немецки
> С википедии:Ключевое слово "навскидку", то есть из мозга. :)
А как один из государственных, в Бельгии ещё.
бывшие германские колонии?
бывшие немецкие территории, до мировых войн...
тоесть в чём суть исправления как я понимаю:...при создании каждого Хэш-объекта (Хэш-словаря) -- в него должно записываться случайная переменная "R" (так её условно назовём)
затем при помещении/извлечении в каждый такой Хэш-Словарь Key/Value значений -- необходимо делать операцию "Real_Key = Key XOR R"
вродебы не сложно :-)
суть исправления в том, чтобы подсаливать хэш рандомными (но, натурально, постоянными для одного сеанса) значениями.
Так как для Ruby EE патча еще нет, то мы портировали решение из последнего Ruby 1.8.7: http://kovyrin.net/2011/12/29/ree-hash-collision-patch/
приятно что такие решения "отдают" для фикса, а не используют.
Точно не используют? Может, уже извлекли, так сказать, выгоду и настало время подумать о совести :) Да и после публикации вполне можно использовать, пока везде не пофиксят.
...годика эдак 2... а кое-где и все 5 лет... :(
В новости сказано, что в Perl проблема исправлена уже в 2003 г, т.е. проблема известна 9 лет, а то и больше. Все кому надо успели попользоваться )
Изящно и утончённо :)
интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?
> интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?В хэш netfilter произвольное значение не передать, там жестко структурированные значения, типа ip и номера порта.
ну, можно, например, попробовать зафлудить целевой узел udp-пакетами с поддельными src_ip:src_port, причём src_ip:src_port выбирать так, чтобы хеш в netfilter получался всегда одинаковым
> ну, можно, например, попробовать зафлудить целевой узел 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.
>> интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?
> В хэш netfilter произвольное значение не передать, там жестко структурированные значения,
> типа ip и номера порта.Вы не поверите но я уже несколько раз за последние года 4 у себя в логах замечал попытку добавления правила на фаере, с тех пор как первый раз это заметил теперь стоит полный запрет на добавление изменение правил iptables - все идет только через конфиг во время загрузки
Конечно не удобно, что бы добавить или удалить правило на фаере приходится менять конфиг и ребутить сервак, за то надежноЕсли у вас болье менее посещаемый сервер то сделайти полное логирование всего что происходит, не удивлюсь что у вас типа сами по себе добавляются/удаляются правила
Кстати не надо забывать про то что несколько месяцев назад нашли багу в апаче благодаря которой можно было через веб гулять по всей корпоративной сети, тут с iptables примерно тоже самое только в реализации nat_iptables
> у себя в логах замечал попытку добавления правила на фаереЧувак, я не хочу тебя расстраивать, но у тебя кажется на серваке что-то идет не так. Понимаешь, правила сами по себе добавляться не могут. Добавить их может троянец, хакер, ну или ты сам. Ремотное добавление правил как-то не предусмотрено дизайном айпитаблеса само по себе.
> Чувак, я не хочу тебя расстраивать, но у тебя кажется на серваке
> что-то идет не так. Понимаешь, правила сами по себе добавляться не
> могут. Добавить их может троянец, хакер, ну или ты сам. Ремотное
> добавление правил как-то не предусмотрено дизайном айпитаблеса само по себе.Есть такая штука - libvirt. Считает, что гораздо лучше админа знает, какие правила должны быть в iptables. Ее происки легко узнать по ключевым словам "192.168.122.0/24" и "virbr0".
поясните каким образом связаны библиотека для виртуализации и iptables.
Посмотрите на список правил до и после запуска libvirtd.
> интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?Нет, там используются хеши Дженкинса.
>> интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?
> Нет, там используются хеши Дженкинса.я тебе сейчас секрет скажу, только ты присядь сначала: от типа хэш-функции наличие/отсутствие уязвимости не зависит.
Если использовать криптографически стойкое хеширование да еще индивидуальной соли добавить - искать коллизии станет довольно утомительно, разве нет? Правда скорость будет заметно хуже.
> Если использовать криптографически стойкое хеширование да еще индивидуальной соли добавить
> - искать коллизии станет довольно утомительно, разве нет? Правда скорость будет
> заметно хуже.наверно в нашем случае достаточно всего лишь "индивидуальной соли добавить" :-)
ведь сложновато найти коллизию хэша, если даже само хэш-значение не отображается в наружу :-) :-)
> я тебе сейчас секрет скажу, только ты присядь сначала: от типа хэш-функции наличие/отсутствие уязвимости не зависит.Ну найдите мне хоть коллизию для conntrack tuple, а то языком трепать все горазды :D
> интересно, а те хеши, которые используются в 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), так что плакали все коллизии :)
оп, Perl и CRuby молодцом =)
для asp.net пофиксили сразу
давно в винапдейтах
> для asp.net пофиксили сразуНе сразу, а с опозданием на 8 лет. Сразу - это в перле пофиксили.
Мелокософт, как обычно, "заботится" о безопасности.
c таким прогрммирование страно что мир ещё работает )
> c таким прогрммирование страно что мир ещё работает )Тссс, никому не говорите)
да проще взять дерево и всё будет ок )
Проще не дерево, а обрабатывать параметны по мере получения. А не так как делает пыхпых читая мегабайты, засовывая их в хешмап, даже если обработчик post запроса вообще не нуждается в параметрах.В стандарт http добавить порядок параметров, чтобы авторизация шла первой.
Скрипты обязать регистрировать входные параметры ПЕРЕД началом обработки полученных от клиента данных, чтобы все не заявленные данные post запроса игнорировались. Ключи хеша определяются на стороне сервера - значит нет проблемы.
> Проще не дерево, а обрабатывать параметны по мере получения. А не так
> как делает пыхпых читая мегабайты, засовывая их в хешмап, даже если
> обработчик post запроса вообще не нуждается в параметрах.
> В стандарт http добавить порядок параметров, чтобы авторизация шла первой.
> Скрипты обязать регистрировать входные параметры ПЕРЕД началом обработки полученных от
> клиента данных, чтобы все не заявленные данные post запроса игнорировались. Ключи
> хеша определяются на стороне сервера - значит нет проблемы.всё это предложенное -- замечательно :-) .. но если предположить что уязвимость в хэш-словарях не будет исправлена -- то сёравно найдётся какойто другой (НЕ унивирсальный для каждого сайта) способ её заэксплуатировать!
> В стандарт http добавить порядок параметров, чтобы авторизация шла первой.а она первой и идёт там...
...там header-поле "WWW-Authenticate: ..." (а уж только потом ниже передаётся тело POST-запроса)
нужно просто поголовно ВЕЗДЕ использовать AJAX на WWW-страницах. доступ к полю "WWW-Authenticate: ..." у XMLHttpRequest-объекта вполне себе есть, например. а также надо забить на MsIE (для которого AJAX пришлось бы делать индивидуально) и забить на нытиков, которые используют NoScript :)
получилибы вообще от AJAX сполшные плюсы! шаблонизировать страницу сайта (на стороне сервера) при каждом запросе не пришлосьбы.. HTTP-данные лишнии при каждом запросе пересылать не пришлосьбы тоже. скорость интернета увеличилась бы, и былобы щастье :-)
поясню немного глубже...header-поле "WWW-Authenticate: ..." не обязательно использовать только для BASIC аудентификации. туда можно (и это НЕ хак!) запихнуть любой вид значения, которое программист щитает что необходим для аудентификации пользователя для авторизации действия.... например можно указать:
WWW-Authenticate: SESSION_ID 1234abc124acb123abc123abc
Не пишите ересь. Чем AJAX HTTP-запрос отличается от обычного? вам не приходит в голову, что AJAX - это не протокол, и даже не модификация протокола, а всего лишь способ послать запрос из браузера без перезагрузки страницы? Объект XMLHttpRequest не имеет никакого отношения к методам хеширования, авторизации, разбора заголовков или распития спиртных напитков на сервере.
> скорость интернета увеличилась быда, конечно, в 100 раз. По 100-мбитной сети сразу до 10Гб. Вы даже не знаете, что интернет - это не только НТТР и "лишние НТТР-данные" (НТТР-заголовки) - это наверно одна квинтиллионная всего трафика. Хотя что говорить, аноним такой аноним.
> Чем AJAX HTTP-запрос отличается от обычного?всмысле если "обычный" -- это <form ...>...</form> -- то отличия весьма очевидны. одно из отличий -- например в том что AJAX (XMLHttpRequest) более гибко может работать с HTTP-headers, а вот <form ...>...</form> никакой гибкости не предоставляет :-D
> вам не приходит в голову, что AJAX - это не протокол, и даже не модификация протокола, а всего лишь способ послать запрос из браузера без перезагрузки страницы
а вам в голову не приходит что какимбы словом вы это не обозвалибы "протокол" или "не протокол" или "способ" -- суть это не поменяет. AJAX это набор определённых действий. а уж называйте (классифицируйте) эти "действия" словом каким хотите :-)
> способ послать запрос из браузера без перезагрузки страницы
при этом заметьте что с сервера перекладываются часть работы на клиента. например серверу (в наиболее качественной реализации принципа AJAX) -- не придётся заниматься шаблонизированием www-странички ВООБЩЕ, это будет делатсья при помощщи шаблонизатора на клиентской стороне. а ещё серверу не придётся заниматься маршрутизацией URL`ов. функциональная нагрузка с сервера уходит -- значит сложность за DDoS`ить сервер возрастает.
> Объект XMLHttpRequest не имеет никакого отношения к методам хеширования, авторизации, разбора заголовков или распития спиртных напитков на сервере.
уже выше было написанно что Объект XMLHttpRequest имеет доступ к HTTP-заголовкам, в том числе к заголовку связанной с аудентификацией. и хотите сказать что аудентификация не связанна с авторизацией клиента на сервере? :-) ну этоже нонсенс. например, пока сервер не получил верных аудентифицирующих данных, он не станет разбирать тело HTTP-запроса.
> да, конечно, в 100 раз. По 100-мбитной сети сразу до 10Гб.
к сожелению нет :-( :-( . не такие цыфры.
> Вы даже не знаете, что интернет - это не только НТТР ...
ну да.. интернет это ещё и Jabber например.. и даже SMTP и IMAP... а кроме HTTP есть ещё например и HTTPS (и с ним ТОЖЕ XMLHttpRequest вполне работает, кстате).. ну и много там всяких разных использований интернета, но причём тут всё это?
Вот всегда находится какой-нибудь <вырезано цензурой>, который предлагает ошибки реализации исправлять переделывая протокол.
Вот всегда находится какой-нибудь <вырезано цензурой>, который путает ошибки реализации с ошибками архитектуры.
Для php 5.2 тоже патчи вышли
https://github.com/laruence/laruence.github.com/tree/master/...
Уйдет в порты FreeBSD в 5.2.17_5 http://www.freebsd.org/cgi/query-pr.cgi?pr=163782 и в centos.alt.ru уже есть http://centos.alt.ru/?p=647
Я все жду когда в PHP появиться поддержка распарсить параметер по требованию. Что-то вроде $_POST->getParam. А распарсеные параметры уже закешировать в этих ваших HASH и хранить.P.S. Кстати проблема только на ключах HASH я так понимаю?!
> Я все жду когда в PHP появиться поддержка распарсить параметер по требованию.
> Что-то вроде $_POST->getParam. А распарсеные параметры уже закешировать в этих ваших
> HASH и хранить.Какая хакеру разница, заткнется сервак сам по себе или по твоему требованию :)