На Chaos Communication Congress заявили о DoS-уязвимостях в ряде популярных языков веб-программирования

    На международной конференции специалистов по IT-технологиям Chaos Communication Congress был опубликован доклад Александра Клинка (Alexander “alech” Klink) и Джулиана Вэльде (Julian “zeri” Wälde), описывающий ряд серьезных уязвимостей в популярных языках веб-программирования. Большинство проблем исследователи связывают с неверной обработкой веб-форм и возможностью компрометации хэш-таблиц, что может привести к успешной DOS-атаке на веб-серверы с последующим хищением данных, причем значительных ресурсов для организации атаки не требуется.

    Суть уязвимостей исследователи описывают таким образом: языки веб-программирования — такие как PHP, ASP.NET, Java, Python, Ruby — имеют прямой доступ к вычислительным ресурсам компьютера; веб-приложения, написанные на этих языках, часто обрабатывают POST-запросы в автоматическом режиме, при этом, если приложение не может использовать рандомизированные хеш-функции, то злоумышленник может специально организованным запросом вызвать коллизию хеш-значений, что может значительно загрузить вычислительные ресурсы сервера.

    На данный момент PHP 5, Java и ASP.NET (UPD: патч выпущен) являются полностью незащищенными перед описываемой атакой, тогда как PHP 4, Python, Ruby — частично уязвимы (в докладе говорится, что большинство уязвимостей базируются на концепциях, впервые появившихся еще в 2003 году, однако только в Ruby в 2008 году появилось исправление, частично исключающее эксплуатацию), причем степень опасности зависит от используемой 32-х или 64-битной архитектуры.

    Любопытно, что в Microsoft уже признали наличие серьезной проблемы и выпустили экстренный патч, связанный с бюллетенем безопасности Security Advisory 2659883, который как раз и устраняет проблему коллизии хеш-функций в ASP.NET. Выпущенный патч связан с исправлением платформы .NET на всех поддерживаемых сейчас версиях Windows, хотя известных инцидентов, связанных с эксплуатацией проблемы пока не известно.

    Крайне подробный доклад со всеми техническими подробностями можно посмотреть здесь — (pdf)

    UPD: комментарий хабрапользователя kadukmm связан с моей, уже исправленной, неточностью.

    [Источник]
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 48

      +8
      Возможно кому-то сэкономлю время. Все эти уязвимости достигаются большим числом коллизий в хеш таблицах. (Ведь параметры запроса складываются в хеши) Время обработки растёт пропорционально квадрату числа элементов. Отправляют POST запрос с ключами порождающими коллизии. Препроцессинг занимает квадратичное время. DOS.

      Мне кстати понравился подход. Простой и красивый. Да и презентация весьма доходчивая.
        0
        не понимаю только почему вдруг O(n^2)… Связный список ведь O(n)…
          +1
          получить 1 элемент из связного списка — O(m) (где m — кол-во элементов в связном списке); вставляем n элементов в словарь — получаем O(m*n), а раз все элементы идут в один связный список — O(n^2)
          0
          можно ещё поподробнее для тех кто не в курсе?
            +7
            Я понял примерно так:

            В большинстве веб-фреймворков для популярных языков содержимое post-запроса автоматически обрабатывается и скалдывается в хеш-таблицу ($_POST в php, request.POST в django) перед передачей управления обработчику. Алгоримическая сложность получения значения по ключу из хештаблицы O(1), если нет коллизий. Коллизия — это когда у двух или более ключей после прогона через хеш-функцию получаются одинаковые хеши, в таком случае для хранения используется связанный список (алгоритмическая сложность O(n)). В атаке предлагается посылать запрос с как можно большим количеством параметров с именами, имеющими одинаковые хеши для конкретного языка программирования, чтобы как можно больше нагружать процессор при обращении к значениям в хеш-таблице с post-данными.
              +2
              Спасибо, стало понятнее ) Я не большой эксперт в области защиты от дос атак, но на сколько знаю защита ставится на уровне вебсервера. Просто… ну пусть даже работа с $_POST массивом ничего не стоит, но выбранные из POST данные как то потом будут обрабатываться программой, либо отсексться как уличенные в DOS на уровне языка, что само по себе есть приличная нагрузка.
                0
                Готовых минусовать вижу, есть готовые объяснить по существу?
                  0
                  > ну пусть даже работа с $_POST массивом ничего не стоит

                  В атаке предлагается посылать запрос с как можно большим количеством параметров с именами, имеющими одинаковые хеши для конкретного языка программирования, чтобы как можно больше нагружать процессор при обращении к значениям в хеш-таблице с post-данными.
                    0
                    Не понятно, почему веб-приложение станет обращаться к неизвестным ему параметрам POST.
                      0
                      А ему и не надо обращаться к неизвестным параметрам. Ему достаточно обращаться к любым параметрам. Из-за присутсвующих в хэше коллизий просто не будет возможность выполнить эффективный поиск по этому хэшу. Грубо говоря, придется перебирать таки все подряд в поисках того, что нам нужно искать, что жутко неэффективно и занимает очень много времени.

                      Когда такой запрос 1 в час, это не страшно. Как только нас начинают щупать за вымя хотя бы 500 килобайтами в секунду (не так уж и много, ан самом деле), наш выделенный сервер начинает работать на 100% и нагревать окружающее пространство.
                        +3
                        Приложение обращается к параметру $_POST['login'], но тут «случайно» появляется параметр $_POST['gkljgk7s6df78gkjvdhs699gsd6g9sd'] такой что хэши 'login' и 'gkljgk7s6df78gkjvdhs699gsd6g9sd' совпадают. Время поиска увеличивается — сначала нужно найти данный хэш, а потом выбрать среди найденных нужный параметр прямым, как правило, перебором. А если таких коллизий 100500, то обращение к $_POST['login'] займёт 100500 проходов соответствующего цикла.
                        ыч ыыыыыыыыыыыч
                          +1
                          «ыч ыыыыыыыыыыыч» пёс написал, положив голову на клаву :)
                            0
                            Ну вот, теперь уже и собаки пишут комментарии на Хабр :(
                            Лишь бы они не начали хорошие топики минусовать.
              +1
              Элегантно. Будем ждать патчей.
                0
                Местами они уже есть
                PHP: svn.php.net/viewvc?view=revision&revision=321040
                  0
                  Спасибо за линк. Увы, придётся перебиться, пока патч доберется до релизных версий — не хотелось бы собирать на продакшне, а дома никсов временно нет.
                    +1
                    Suhosin это лечит
                  +7
                  DOS — операционная система;
                  DoS — вид атаки.
                    +2
                    В 2003 году уже были практические применения.
                      +2
                      >>На данный момент… ASP.NET являются полностью незащищенными

                      на момент написания вашей заметки ASP.NET была полностью защищена оперативно вышедшим обновлением
                        +1
                        use Perl;
                          0
                          из описания бага с сайта 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
                          ;)
                            +3
                            То есть в перле её нашли и исправили ещё в 2003?
                              +2
                              Похоже, в презентации:

                              «Thank you!

                              Perl for fixing this in 2003»

                              «The hash seed feature was added in Perl 5.8.1»
                            0
                            В презентации:

                            «How to fix it?
                            Use a randomized hash function!
                            Cruby 1.9 and Perl already do»
                              0
                              Я как раз об этом.
                            –4
                            > часто обрабатывают POST-запросы в автоматическом режиме
                            а иногда вручную?

                            > использовать рандомизированные хеш-функции
                            абсолютно-рандомные хеши? GUID?

                            > вызвать коллизию хеш-значений, что может значительно загрузить вычислительные ресурсы сервера.
                            с каких пор внезапно коллизия в хеш функциях загружает вычислительные ресурсы сервера? в каких алгоритмах?

                            Почему всё так мутно? в статье ни единого пруфлинка, описано всё из разряда «вы всё равно не поймёте».
                              –2
                              UPD: увидел ссылку на pdf, сейчас посмотрим.
                                0
                                В топике у меня ссылка на более чем подробный технический отчет и иллюстрациями кода на разных языках.
                                +2
                                для тех, кто тоже задумался о словах автора: Речь идёт о хешах aka ассоциативных массивах.
                                при чём здесь POST — автор, видимо, не пытался понять.

                                для того, чтобы использовать уязвимость, надо иметь возможность сохранить в хеш несколько предопределённых пар ключ-значение, что само по себе редко встречается в коде. гораздо чаще в хеши строки записываются по предопределённому ключу. отсюда первый самый простой способ — хеши параметров запросов ($_GET и $_POST в php, params в ruby on rails etc), POST авторы привели в качестве примера.

                                по части ситуации с Ruby, 1.9 не подвержена уязвимости, для 1.8.7 исправление в патчлевеле 357
                                  +1
                                  Джулиана Вёльде (Julian “zeri” Wälde) — неправильно, надо говорить Вэльде, иначе было бы Wölde
                                    0
                                    Кто знает когда поправят Python?
                                      +1
                                      Это ддос. Поиск по таблице могут не менять. Проблема в открытости POST GET и HEADERS систем написанных на python, т.к. везде используется dict для данных. Решения два, первое — настроить лимиты на входящие данные. 2-ое сменить алгоритм поиска по таблице для ускорения решения задачи.
                                        +1
                                        Неверный ответ. Для того чтобы решить проблему нужно изменить внутреннюю реализацию хеша. Использовать псевдо-рандомизированную хеш функцию, или Universal hashing как предлагают в статье комментарием ниже.

                                        Никакой проблемы в «открытости POST GET и HEADERS» нет, и использовать что-то другое вместо dict для данных нецелесообразно.

                                        Соответственно мой вопрос был — знает ли кто-то номер тикета где отслеживается фикс этой проблемы в питоне, и когда выйдет апдейт?
                                          –1
                                          Не выйдет фикса ибо ошибка не в Python. Об этом уже дважды говорили у них в мейллисте.
                                          Я с ними согласен, так как это может сильно нарушить мультипроцессинг, мультитрединг и другие методы, которые полагаются на хеши диктов.
                                            0
                                            Предлагалось два решения, предефайнд сид дикт или же рандом сид дикт.
                                              0
                                              За что минусы-то? Можете в python-dev заглянуть, там тема есть обзор по этому вопросу в котором все еще раз разжевали, от 29 декабря между прочим.
                                              0
                                              Не обязательно менять реализацию всех хэшей. Можно просто для POST/GET использовать «исправленный» словарь с рандомизацией, а во всех остальных — оставить без изменений. Т.е. проблема может быть решена на уровне веб-фреймворков.
                                          +1
                                          Denial of Service via Algorithmic Complexity Attacks

                                          То же самое, немного раньше, и в формате нормального доклада для желающих почитать детали
                                          –7
                                          Зачем постить «новость», если об этом писали уже другие источники? Ладно были бы ещё дополнительные сведения

                                          На секлабе об этом ещё вчера писали:
                                          www.securitylab.ru/news/413125.php
                                            +2
                                            Вы такой комментарий ко всем новостям на хабре пишете?
                                              –1
                                              Мне просто непонятно зачем из хабра делать новостной агрегатор? В своё время Секлаб пошёл по этому пути. Из-за недостатка авторских статей. В итоге имеем: куча школоты в комментариях, мало профессионалов.
                                              У хабра нет проблемы с авторскими статьями. Так зачем же идти по стопам секлаба?
                                                +3
                                                1. Авторских статей на хабре сильно меньше, чем новостей
                                                2. Хабровский рейтинг, по идее, должен гарантировать, что вы увидите только то, что интересно большому количеству людей
                                                3. Многие ценят свое время. Вместо того, чтобы читать 50 различных сайтов (которые и так потсоянно дублируют информацию) можно читать один и оставаться в курсе самых последних событий.
                                                  0
                                                  И да. То, что новость появилась на хабре:
                                                  1. не значит, что автор новости читал об той новости на любом из других 50-и сайтов, которые читаете вы
                                                  2. не значит, что автор новости читал ее именно там, где вам кажется, что он ее читал
                                                  3. часто не значит, что новость продублирована здесь из других источников, а не наоборот
                                                0
                                                Я например секлаб не читаю, но очень благодарен jeston за новость. Пойду найду не тестировал ли кто node.js, и если не найду – сам на праздниках потестирую.
                                                  +1
                                                  Как человек, читающий RSS, могу заметить, что статьи на секлабе зачастую оказываются в фиде спустя сутки после их появления на сайте, а их содержимое крайне часто оказыватеся непрофессиональным бредом либо водой. Таким образом, большинство «опоздавших» (но приличных) статей с хабра в фиде оказываются задолго до их ужасных якобы оригиналов.
                                                  0
                                                  может привести к успешной DOS-атаке на веб-серверы с последующим хищением данных

                                                  Как именно DoS может привести к хищению данных?

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое