Свободный фаззер Domato нашёл 31 баг в основных браузерах

    Хакеры из проекта Project Zero компании Google выложили в открытый доступ инструмент автоматического тестирования программ на баги — фаззер Domato. Эффективность программы доказана на практике: она нашла 31 баг в пяти популярных браузерах. Результаты тестирования показаны в таблице.
    Вендор
    Броузер
    Движок
    Кол-во багов
    Идентификаторы багов Project Zero
    Google
    Chrome
    Blink
    2
    994, 1024
    Mozilla
    Firefox
    Gecko
    4**
    1130, 1155, 1160, 1185
    Microsoft
    Internet Explorer
    Trident
    4
    1011, 1076, 1118, 1233
    Microsoft
    Edge
    EdgeHtml
    6
    1011, 1254, 1255, 1264, 1301, 1309
    Apple
    Safari
    WebKit
    17
    999, 1038, 1044, 1080, 1082, 1087,
    1090, 1097, 1105, 1114, 1241, 1242,
    1243, 1244, 1246, 1249, 1250
    Всего
    31*
    *Два бага относятся к двум браузерам, поэтому общее количество 31, а не 33, как следует из суммирования цифр в колонке
    **Один из багов на самом деле в графической библиотеке Skia, а не в исходниках самого Firefox. Но поскольку этот код добавлен в браузер разработчиками Firefox, будет честно учесть его в таблице


    Domato специально разработан, чтобы вскрывать баги в DOM-движках браузеров. DOM-движки являются частью движка рендеринга в каждом браузере, и именно в этой части зачастую скрывается много багов. Изредка они даже используются особо продвинутыми злоумышленниками, в том числе из государственных спецслужб. Например, именно баг в DOM-движке Firefox использовали спецслужбы при создании вредоносного эксплоита для браузера Tor. Эксплоит обнаружили специалисты по безопасности в ноябре прошлого года. Точнее, как обнаружили: он случайно утёк из компании Exodus Intel, которая специализируется на покупке и разработке эксплоитов с целью перепродажи их разведывательным агентствам и правоохранительным структурам из разных стран.

    Ребята из Google традиционно сражаются с подобными методами государственной слежки. Возможно, тот случай с браузером Tor и подал идею о создании фаззера для выявления уязвимостей в DOM-движках. Его автором стал известный хакер Иван Фратрич (Ivan Fratric). Впрочем, даже без того случая создание подобного инструмента напрашивалось само собой: Фратрич пишет, что редкое обновление безопасности для какого-нибудь браузера обходится без закрытия багов в DOM-движке, настолько часто они встречаются. Раньше звание главной дыры принадлежало Flash, но по мере отказа от этой технологии это звание постепенно переходит к DOM-движку.

    Теперь Фратрич выложил Domato в открытый доступ с расчётом, что другие усовершенствуют этот полезный инструмент. Кстати, почти все крупные вендоры платят за найденные уязвимости, так что хороший фаззер может заработать вам много тысяч долларов.

    Во время проверки браузеров, результаты которой приведены выше, фаззинг заключался в генерации случайного кода и подаче его браузеру в надежде, что тот обрушится, и так примерно 100 млн раз. По оценке Фратрича, фаззинг такого масштаба в облаке Google Compute Engine стоил бы около $1000.

    Фаззер нашёл примерно одинаковое количество багов в Chrome, Firefox, Internet Explorer и Edge, но намного больше багов в Safari, который выделяется среди остальных. К настоящему моменту все эти баги закрыты, потому что Apple заранее получила доступ к Domato, наняв в штат члена команды Project Zero, который попросил Ивана дать попользоваться фаззером (ранее Фратрич сам предлагал его Apple в связи с большим количеством багов в Safari, но компания гордо отказалась). Фратрич пишет, что слишком большое количество багов в Safari особенно настораживает, учитывая интерес злоумышленников к этой платформе, о чём говорят цены на эксплоиты и недавние таргетированные атаки.

    Ещё интересно сравнить количество багов в браузерах Chrome и Safari, которые ещё несколько лет назад работали на одном движке WebKit, пока Google не форкнула его, создав Blink. Судя по всему, с момента форка в 2013 году в движке Blink устранили большое количество багов либо большое количество багов добавили в движок WebKit.

    Иван Фратрич также отдал должное разработчикам из Microsoft, которые создали сборщик мусора в памяти MemGC для защиты от эксплоитов, использующих баги типа use-after-free. Функция встроена в Edge и Internet Explorer 11. Он говорит, что эффект MemGC очевиден: если через флаг OverrideMemoryProtectionSetting отключить эту функцию, то выявляется намного больше багов, которые реально присутствуют в коде.
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 18
    • +1
      У вас в таблице есть звездочки-сноски, но нет пояснения
      *While adding the number of bugs results in 33, 2 of the bugs affected multiple browsers
      **The root cause of one of the bugs found in Mozilla Firefox was in the Skia graphics library and not in

      У багов огнелиса две звездочки, у общего кол-ва — одна (почему тут наоборот — хз)
      Перевод через транслейт.ру для желающих:
      Перевод
      *Добавляя количество результатов ошибок в 33, 2 из ошибок затронули многократные браузеры
      ** Первопричина одной из ошибок, найденных в Mozilla Firefox, была в библиотеке графики Skia а не в
      • +1
        Большое спасибо, как-то не обратил внимание. Добавил описание.
        • 0

          del

        • +3
          браузерах

          Броузер

          Пора определиться уже.
          • –1
            Я определился — мне пофиг.
          • +2
            А в Servo ошибки искались?
          • +7
            Не совсем понятна критичность багов и их возможная эксплуатация хакерами. Увы, кол-во багов без понимания их реальной угрозы мало что говорит.
            • 0
              фаззинг такого масштаба в облаке Google Compute Engine стоил бы около $1000.

              зачем об этом вообще упомянули? А он на локальном РС запускал или на серваке? С чем сравнивать-то?
              • +3
                Полагаю, речь идёт о том, что 100+млн тестов можно сделать довольно быстро, если юзать клауд и финансовые затраты весьма скромны по меркам корпорации-разработчика браузера.
                • 0
                  Именно. Автор говорит, что сам-то он юзал клауд бесплатно, но по такой цене это может сделать каждый.
              • +1

                Что-то среди идентификаторов багов я вижу только один повтор (1011). Количество чисел в последней колонке соответствует числу в предпоследней. Но в сумме все равно почему-то на один баг меньше. Потом, я как-то не очень понимаю — что значит один и тот же баг, движки-то разные? Если вы залатаете в одном, в другом же сам собой не починится. И еще, почему нельзя сразу дать ссылки на баги вместо каких-то непонятных идентификаторов?

                • +1

                  Как сказано в статье, один из багов Firefox это на самом деле баг в гугловской библиотеке skia, которая используется и в Chrome. Возможно, он является повторением одного из багов Хрома.

                  • 0

                    Я специально отметил в комментарии, что в списках багах есть только один повтор, и он для майкрософтских браузеров. Это еще можно понять, вряд ли они новый движок с нуля писали. Если просуммировать количества, то получим 33 бага, но нам говорят, что 2 бага — это повторы, значит всего 31. Но если посмотреть на идентификаторы багов — то там уникальных 32 значения. Поэтому непонятно, как их все-таки суммировали.

              • 0

                Простите, я один не понимаю, как это — "фаззинг заключался в генерации случайного кода и подаче его браузеру в надежде, что тот обрушится"?

                • +9
                  О, там очень интересная тема. Вначале программа компилируется со специальными настройками в компиляторе (сегодня вроде только clang поддерживается) чтобы можно было детально отслеживать ход его выполнения и возникающие при этом проблемы. Затем фаззер начинает пытаться генерировать входные последовательности которые проведут его по всем ветвям исполняемого кода. Он подает на вход случайную последовательность и следит за тем какие фрагменты исполняемого кода выполнились. Поначалу это скорее всего будет ветка «вы подали на вход неправильную последовательности данных». Затем фаззер берет какое-нибудь из начальных ветвлений где одна из возможных ветвей кода не выполнилась и начинает целенаправленно модифицировать входную последовательность в поиске последовательности обработка которой пойдет по этой ранее не выполнявшейся ветви кода. А как только найден фрагмент входных данных «анлочащий» новую ветку фаззер начинает использовать его чтобы пройти по этой ветке дальше. И так до бесконечности, пытаясь пройти через весь доступный код. В подходящих условиях фаззер даже ничего не зная о программе способен на удивление быстро «нащупать» подобным образом основную структуру входных данных которую ожидает программа. А как показывает вышеприведенный опыт, в процессе подобного перебора находятся некоторое количество ветвлений после прохождения которых софт радостно крэшится.
                • +1
                  Мне очень нравятся такие статьи, в которых написано «всё плохо», но конкретных версий нет.

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

                  Интересные публикации