Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
Возможно кому-то сэкономлю время. Все эти уязвимости достигаются большим числом коллизий в хеш таблицах. (Ведь параметры запроса складываются в хеши) Время обработки растёт пропорционально квадрату числа элементов. Отправляют POST запрос с ключами порождающими коллизии. Препроцессинг занимает квадратичное время. DOS.
Мне кстати понравился подход. Простой и красивый. Да и презентация весьма доходчивая.
Мне кстати понравился подход. Простой и красивый. Да и презентация весьма доходчивая.
не понимаю только почему вдруг O(n^2)… Связный список ведь O(n)…
можно ещё поподробнее для тех кто не в курсе?
Я понял примерно так:
В большинстве веб-фреймворков для популярных языков содержимое post-запроса автоматически обрабатывается и скалдывается в хеш-таблицу ($_POST в php, request.POST в django) перед передачей управления обработчику. Алгоримическая сложность получения значения по ключу из хештаблицы O(1), если нет коллизий. Коллизия — это когда у двух или более ключей после прогона через хеш-функцию получаются одинаковые хеши, в таком случае для хранения используется связанный список (алгоритмическая сложность O(n)). В атаке предлагается посылать запрос с как можно большим количеством параметров с именами, имеющими одинаковые хеши для конкретного языка программирования, чтобы как можно больше нагружать процессор при обращении к значениям в хеш-таблице с post-данными.
В большинстве веб-фреймворков для популярных языков содержимое post-запроса автоматически обрабатывается и скалдывается в хеш-таблицу ($_POST в php, request.POST в django) перед передачей управления обработчику. Алгоримическая сложность получения значения по ключу из хештаблицы O(1), если нет коллизий. Коллизия — это когда у двух или более ключей после прогона через хеш-функцию получаются одинаковые хеши, в таком случае для хранения используется связанный список (алгоритмическая сложность O(n)). В атаке предлагается посылать запрос с как можно большим количеством параметров с именами, имеющими одинаковые хеши для конкретного языка программирования, чтобы как можно больше нагружать процессор при обращении к значениям в хеш-таблице с post-данными.
Спасибо, стало понятнее ) Я не большой эксперт в области защиты от дос атак, но на сколько знаю защита ставится на уровне вебсервера. Просто… ну пусть даже работа с $_POST массивом ничего не стоит, но выбранные из POST данные как то потом будут обрабатываться программой, либо отсексться как уличенные в DOS на уровне языка, что само по себе есть приличная нагрузка.
Готовых минусовать вижу, есть готовые объяснить по существу?
> ну пусть даже работа с $_POST массивом ничего не стоит
В атаке предлагается посылать запрос с как можно большим количеством параметров с именами, имеющими одинаковые хеши для конкретного языка программирования, чтобы как можно больше нагружать процессор при обращении к значениям в хеш-таблице с post-данными.
Не понятно, почему веб-приложение станет обращаться к неизвестным ему параметрам POST.
А ему и не надо обращаться к неизвестным параметрам. Ему достаточно обращаться к любым параметрам. Из-за присутсвующих в хэше коллизий просто не будет возможность выполнить эффективный поиск по этому хэшу. Грубо говоря, придется перебирать таки все подряд в поисках того, что нам нужно искать, что жутко неэффективно и занимает очень много времени.
Когда такой запрос 1 в час, это не страшно. Как только нас начинают щупать за вымя хотя бы 500 килобайтами в секунду (не так уж и много, ан самом деле), наш выделенный сервер начинает работать на 100% и нагревать окружающее пространство.
Когда такой запрос 1 в час, это не страшно. Как только нас начинают щупать за вымя хотя бы 500 килобайтами в секунду (не так уж и много, ан самом деле), наш выделенный сервер начинает работать на 100% и нагревать окружающее пространство.
Приложение обращается к параметру $_POST['login'], но тут «случайно» появляется параметр $_POST['gkljgk7s6df78gkjvdhs699gsd6g9sd'] такой что хэши 'login' и 'gkljgk7s6df78gkjvdhs699gsd6g9sd' совпадают. Время поиска увеличивается — сначала нужно найти данный хэш, а потом выбрать среди найденных нужный параметр прямым, как правило, перебором. А если таких коллизий 100500, то обращение к $_POST['login'] займёт 100500 проходов соответствующего цикла.
ыч ыыыыыыыыыыыч
ыч ыыыыыыыыыыыч
Элегантно. Будем ждать патчей.
Местами они уже есть
PHP: svn.php.net/viewvc?view=revision&revision=321040
PHP: svn.php.net/viewvc?view=revision&revision=321040
DOS — операционная система;
DoS — вид атаки.
DoS — вид атаки.
В 2003 году уже были практические применения.
>>На данный момент… ASP.NET являются полностью незащищенными
на момент написания вашей заметки ASP.NET была полностью защищена оперативно вышедшим обновлением
на момент написания вашей заметки ASP.NET была полностью защищена оперативно вышедшим обновлением
use Perl;
из описания бага с сайта Ruby www.ruby-lang.org/en/news/2011/12/28/denial-of-service-attack-was-found-for-rubys-hash-algorithm/
The situation is similar to the one found for Perl in 2003
;)
The situation is similar to the one found for Perl in 2003
;)
В презентации:
«How to fix it?
Use a randomized hash function!
Cruby 1.9 and Perl already do»
«How to fix it?
Use a randomized hash function!
Cruby 1.9 and Perl already do»
> часто обрабатывают POST-запросы в автоматическом режиме
а иногда вручную?
> использовать рандомизированные хеш-функции
абсолютно-рандомные хеши? GUID?
> вызвать коллизию хеш-значений, что может значительно загрузить вычислительные ресурсы сервера.
с каких пор внезапно коллизия в хеш функциях загружает вычислительные ресурсы сервера? в каких алгоритмах?
Почему всё так мутно? в статье ни единого пруфлинка, описано всё из разряда «вы всё равно не поймёте».
а иногда вручную?
> использовать рандомизированные хеш-функции
абсолютно-рандомные хеши? GUID?
> вызвать коллизию хеш-значений, что может значительно загрузить вычислительные ресурсы сервера.
с каких пор внезапно коллизия в хеш функциях загружает вычислительные ресурсы сервера? в каких алгоритмах?
Почему всё так мутно? в статье ни единого пруфлинка, описано всё из разряда «вы всё равно не поймёте».
для тех, кто тоже задумался о словах автора: Речь идёт о хешах aka ассоциативных массивах.
при чём здесь POST — автор, видимо, не пытался понять.
для того, чтобы использовать уязвимость, надо иметь возможность сохранить в хеш несколько предопределённых пар ключ-значение, что само по себе редко встречается в коде. гораздо чаще в хеши строки записываются по предопределённому ключу. отсюда первый самый простой способ — хеши параметров запросов ($_GET и $_POST в php, params в ruby on rails etc), POST авторы привели в качестве примера.
по части ситуации с Ruby, 1.9 не подвержена уязвимости, для 1.8.7 исправление в патчлевеле 357
при чём здесь POST — автор, видимо, не пытался понять.
для того, чтобы использовать уязвимость, надо иметь возможность сохранить в хеш несколько предопределённых пар ключ-значение, что само по себе редко встречается в коде. гораздо чаще в хеши строки записываются по предопределённому ключу. отсюда первый самый простой способ — хеши параметров запросов ($_GET и $_POST в php, params в ruby on rails etc), POST авторы привели в качестве примера.
по части ситуации с Ruby, 1.9 не подвержена уязвимости, для 1.8.7 исправление в патчлевеле 357
Джулиана Вёльде (Julian “zeri” Wälde) — неправильно, надо говорить Вэльде, иначе было бы Wölde
Кто знает когда поправят Python?
Это ддос. Поиск по таблице могут не менять. Проблема в открытости POST GET и HEADERS систем написанных на python, т.к. везде используется dict для данных. Решения два, первое — настроить лимиты на входящие данные. 2-ое сменить алгоритм поиска по таблице для ускорения решения задачи.
Неверный ответ. Для того чтобы решить проблему нужно изменить внутреннюю реализацию хеша. Использовать псевдо-рандомизированную хеш функцию, или Universal hashing как предлагают в статье комментарием ниже.
Никакой проблемы в «открытости POST GET и HEADERS» нет, и использовать что-то другое вместо dict для данных нецелесообразно.
Соответственно мой вопрос был — знает ли кто-то номер тикета где отслеживается фикс этой проблемы в питоне, и когда выйдет апдейт?
Никакой проблемы в «открытости POST GET и HEADERS» нет, и использовать что-то другое вместо dict для данных нецелесообразно.
Соответственно мой вопрос был — знает ли кто-то номер тикета где отслеживается фикс этой проблемы в питоне, и когда выйдет апдейт?
Не выйдет фикса ибо ошибка не в Python. Об этом уже дважды говорили у них в мейллисте.
Я с ними согласен, так как это может сильно нарушить мультипроцессинг, мультитрединг и другие методы, которые полагаются на хеши диктов.
Я с ними согласен, так как это может сильно нарушить мультипроцессинг, мультитрединг и другие методы, которые полагаются на хеши диктов.
Не обязательно менять реализацию всех хэшей. Можно просто для POST/GET использовать «исправленный» словарь с рандомизацией, а во всех остальных — оставить без изменений. Т.е. проблема может быть решена на уровне веб-фреймворков.
Denial of Service via Algorithmic Complexity Attacks
То же самое, немного раньше, и в формате нормального доклада для желающих почитать детали
То же самое, немного раньше, и в формате нормального доклада для желающих почитать детали
В 2003 году были и рабочие примеры, кстати :)
web.archive.org/web/20031119065602/http://www.cs.rice.edu/~scrosby/hash/
web.archive.org/web/20031119065602/http://www.cs.rice.edu/~scrosby/hash/
Зачем постить «новость», если об этом писали уже другие источники? Ладно были бы ещё дополнительные сведения
На секлабе об этом ещё вчера писали:
www.securitylab.ru/news/413125.php
На секлабе об этом ещё вчера писали:
www.securitylab.ru/news/413125.php
Вы такой комментарий ко всем новостям на хабре пишете?
Мне просто непонятно зачем из хабра делать новостной агрегатор? В своё время Секлаб пошёл по этому пути. Из-за недостатка авторских статей. В итоге имеем: куча школоты в комментариях, мало профессионалов.
У хабра нет проблемы с авторскими статьями. Так зачем же идти по стопам секлаба?
У хабра нет проблемы с авторскими статьями. Так зачем же идти по стопам секлаба?
1. Авторских статей на хабре сильно меньше, чем новостей
2. Хабровский рейтинг, по идее, должен гарантировать, что вы увидите только то, что интересно большому количеству людей
3. Многие ценят свое время. Вместо того, чтобы читать 50 различных сайтов (которые и так потсоянно дублируют информацию) можно читать один и оставаться в курсе самых последних событий.
2. Хабровский рейтинг, по идее, должен гарантировать, что вы увидите только то, что интересно большому количеству людей
3. Многие ценят свое время. Вместо того, чтобы читать 50 различных сайтов (которые и так потсоянно дублируют информацию) можно читать один и оставаться в курсе самых последних событий.
И да. То, что новость появилась на хабре:
1. не значит, что автор новости читал об той новости на любом из других 50-и сайтов, которые читаете вы
2. не значит, что автор новости читал ее именно там, где вам кажется, что он ее читал
3. часто не значит, что новость продублирована здесь из других источников, а не наоборот
1. не значит, что автор новости читал об той новости на любом из других 50-и сайтов, которые читаете вы
2. не значит, что автор новости читал ее именно там, где вам кажется, что он ее читал
3. часто не значит, что новость продублирована здесь из других источников, а не наоборот
Я например секлаб не читаю, но очень благодарен jeston за новость. Пойду найду не тестировал ли кто node.js, и если не найду – сам на праздниках потестирую.
Как человек, читающий RSS, могу заметить, что статьи на секлабе зачастую оказываются в фиде спустя сутки после их появления на сайте, а их содержимое крайне часто оказыватеся непрофессиональным бредом либо водой. Таким образом, большинство «опоздавших» (но приличных) статей с хабра в фиде оказываются задолго до их ужасных якобы оригиналов.
может привести к успешной DOS-атаке на веб-серверы с последующим хищением данных
Как именно DoS может привести к хищению данных?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
На Chaos Communication Congress заявили о DoS-уязвимостях в ряде популярных языков веб-программирования