The OpenNET Project / Index page

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

Google представил OSS-Fuzz, сервис для анализа безопасности открытого ПО

01.12.2016 23:45

Компания Google ввела в строй проект OSS-Fuzz, в рамках которого попыталась адаптировать свой опыт организации непрерывного fuzzing-тестирования Chromium для обеспечения тестирования любых открытых проектов. Суть fuzzing-тестирования в генерации потока всевозможных случайных комбинаций входных данных, приближенных к реальным данным (например, html-страницы с случайными параметрами тегов или изображения с аномальными заголовками), и фиксации возможных сбоев в процессе их обработки. Если какая-то последовательность приводит к краху или не соответствует ожидаемой реакции, то такое поведение с высокой вероятностью свидетельствует об ошибке или уязвимости.

Первый вариант сервиса основан на применении движка libFuzzer, ранее переданного сообществу LLVM, и набора Google Sanitizers, в который входят инструменты AddressSanitizer, MemorySanitizer, LeakSanitizer и ThreadSanitizer, позволяющие на основе выявленных в процессе fuzzing-тестирования проблем, определять наличие типовых уязвимостей, вызванных переполнениями буфера, целочисленными переполнениями, обращением к неинициализированным и освобождённым областям, утечками памяти, разыменованием указателей и проблемами с установкой блокировок.

В будущем в OSS-Fuzz планируется обеспечить поддержку и других движков fuzzing-тестирования, таких как AFL. Для формирования отчётов и распределённого тестирования кода задействован кластер ClusterFuzz, уже применяемый для проверки Chrome. В настоящее время в OSS-Fuzz обеспечивает около 4 триллионов проверок в неделю. Тестирование охватывает 31 открытый проект, среди которых SQLite, PCRE2, openssl, boringssl, coreutils, curl, ffmpeg, freetype2, libjpeg-turbo, libpng, node.js, nss, pidgin и zlib. В процессе проверки данных проектов выявлено 150 ошибок, из которых 92 ошибки уже исправлены.

Разработчики других открытых проектов могут добавить свои репозитории для тестирования, подготовив шаблон fuzzing-тестирования и отправив специальную заявку через pull-запрос. При обнаружении ошибок, разработчикам автоматически отправляется уведомление и создаётся приватная заявка на исправление (чтобы исключить преждевременной утечки сведений об уязвимостях, issue создаётся в системе отслеживания ошибок с ограниченным доступом). ClusterFuzz отслеживает состояние исправления ошибки и сам закрывает issue. Информация о проблеме становится публично доступной спустя 7 дней после исправления или спустя 90 дней с момента выявления ошибки, если проблема остаётся не исправленной.

  1. Главная ссылка к новости (https://opensource.googleblog....)
  2. OpenNews: Проект по продвижению в ядро Linux новых технологий активной защиты
  3. OpenNews: В CERT разработали открытый инструментарий для выявления уязвимостей
  4. OpenNews: Компания Google помогла устранить более тысячи проблем в исходном коде проекта FFmpeg
  5. OpenNews: Проект Mozilla представил Minion, платформу для автоматизированного тестирования безопасности кода
  6. OpenNews: Разработчики Chromium представили кластер для автоматизации выявления уязвимостей
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/45602-fuzzing
Ключевые слова: fuzzing, oss-fuzz
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (32) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, A.Stahl (ok), 00:38, 02/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Шикарная новость! С её помощью мы сможем проверить боты ли пишут всякую муть про OSS/Alsa/Pulsaudio или же это делают живые люди.
     
     
  • 2.6, Устахл (?), 09:13, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Шикарная новость! С её помощью мы сможем проверить Астахлы ли пишут всякую муть про OSS/Alsa/Pulsaudio или же это делают живые люди.
     
  • 2.14, 42 (?), 12:53, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    да
     
  • 2.21, Аноним (-), 16:47, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > муть

    Пример мути, пожалуйста?

     
     
  • 3.26, A.Stahl (ok), 17:26, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    П-ш-ш-ш, например.
     

  • 1.7, Аноним (-), 09:40, 02/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Что только люди не придумают, чтобы не использовать языки с управляемой памятью!
     
     
  • 2.8, angra (ok), 10:58, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +5 +/
    "вызванных переполнениями буфера, целочисленными переполнениями, обращением к неинициализированным и освобождённым областям, утечками памяти, разыменованием указателей и проблемами с установкой блокировок"

    Внимание вопрос: что из этого списка решается языками с управляемой памятью?
    Подсказка: меньше половины.

    Попкорн захватил, жду ответа.

     
     
  • 3.10, freehck (ok), 11:45, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    angra, я конечно понимаю, что это не совсем то место, где стоит задавать такие вопросы (ой налетят сейчас на меня!), но какие собственно языки относят к языкам с управляемой памятью, да и есть ли определение этой самой "управляемой памяти"?

    Я так понимаю, что "язык с управляемой памятью", должен:
    1) осуществлять проверку индексов при работе с буфером
    2) оперировать связываниями, а не переменными
    3) не позволять оперирование указателями вообще

    Но может, я ошибаюсь?

     
     
  • 4.11, angra (ok), 12:13, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не, ну с тобой не интересно, я лучше того анонима подожду, который уверен, что управляемая память позволяет решить даже проблему целочисленного переполнения.

    Но вообще часть операций с указателями языки с управляемой памятью разрешают. Обычно запрещается запись в указатель произвольного значения и адресная арифметика, что по сути одно и то же. Но остается возможность хранения в отдельных переменных и структурах, копирование, сравнение, передача в функцию, обнуление.  

     
     
  • 5.22, Аноним (-), 16:48, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Управляемая память позволяет решить даже проблему целочисленного переполнения!!!!11111
     
  • 4.18, Andrey Mitrofanov (?), 15:40, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > angra, я конечно понимаю, что это не совсем то место, где стоит
    > задавать такие вопросы (ой налетят сейчас на меня!), но какие собственно

    https://duckduckgo.com/?q=language+managed+mamory

    Одна из первых ссылок на MSDN -- что "какбэ намекает"ТМ.  //пусть теперь они отмазываются!

    > языки относят к языкам с управляемой памятью, да и есть ли
    > определение этой самой "управляемой памяти"?

     
     
  • 5.20, freehck (ok), 16:37, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Во. Это определение, пожалуй, и возьму. Ничего более чёткого я не нашёл.

    "The Microsoft definition is that managed memory is cleaned up by a Garbage Collector (GC), i.e. some process that periodically determines what part of the physical memory is in use and what is not."

    Спасибо, Андрей!

     
     
  • 6.24, Andrey Mitrofanov (?), 17:03, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Во. Это определение, пожалуй, и возьму. Ничего более чёткого я не нашёл.
    > "The Microsoft definition is
    > Спасибо, Андрей!

    Вы меня неправильно http://www.opennet.dev/openforum/vsluhforumID3/109204.html#72 поняли, коллега!?  P-))

     
  • 4.31, adolfus (ok), 10:07, 03/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Что это за языки такие, в которых програмист не может контролировать границы изменения индексов и для этого нужны какие-то скрытые от него механизмы? А если есть возможность указать границы, то зачем делать какие-то еще проверки? Вы просто не лезете своими индексами за пределы буфера, размер которого Вам всегда известен, и все. Если Вы не знаете размера буфера, то никакие проверки не помогут.
    Не знаю ни одного насильника, чтобы тот прокалывался с индексами или указателями. Ну разве что на этапе освоения C Library.
    Была такая инструкция у интеловского ЦПУ -- bound -- как почитаешь мануал, сколько тактов она жрет и что после этого случается с кешем, так возникает желание страничку вырвать нахрен, чтобы и соблазна не было.

    А что не так с указателями? В си, например, они имеют типы и отлично проецируются в адресные части инструкций любых процессоров. Как там проколоться можно, я и представить не могу.

     
     
  • 5.32, Аноним (-), 11:11, 03/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >  Как там проколоться можно, я и представить не могу.

    Не только проколоться, но и в ногу выстрелить.

     
  • 5.33, freehck (ok), 10:59, 04/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Адольфус, я намекаю обычно плохо, так что скажу прямо: у Вас словесный понос.

    "Контролировать границы изменения индексов" нужно потому, что когда Вы за них случайно выйдете, Вам бы хотелось, что выдалась большая жирная ошибка "неправильный индекс" весто того, чтобы запортить Вам адрес возврата или кучу.

    Всё.

     
  • 5.35, Ordu (ok), 01:30, 06/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Была такая инструкция у интеловского ЦПУ -- bound -- как почитаешь мануал, сколько тактов она жрет и что после этого случается с кешем, так возникает желание страничку вырвать нахрен, чтобы и соблазна не было.

    А у интеловских процов все сложные древние инструкции узкого специального назначения -- это полнейший отстой в плане производительности. Есть куча инструкций общего назначения, которые можно привлечь к проверке. И, писечка в том, что здравомыслящий программист эти проверки вставляет в код всегда, когда их не вставляет туда компилятор. Раньше было важно вставлять их именно вручную, потому что компилятор не умел оптимизировать. Сегодня же... Гляньте для примера на C++: там проверки на выход за границы массива вставляет даже не компилятор, а библиотека -- STL, -- и это в C++, мастурбирующем на скорость выполнения кода. На каждый вызов оператора [] втыкается проверка выхода за границы массива. Как это возможно? А очень просто: современный оптимизирующий компилятор вполне в состоянии вычислить ненужные проверки и убрать их.

    И на фоне этого, вой современных программистишек, что мол автоматические проверки на выход за границы массива не совместимы с производительностью, выглядит смешно. Ещё смешнее, когда для подтверждения своих тезисов они вытаскивают на свет божий инструкцию bound, которой сто^W сорок лет в обед, и которая существует сегодня (если существует) исключительно ради обратной совместимости и за сорок лет своего существования небось ни разу не оптимизировалась, потому что Intel'у глубоко плевать на то, как быстро она работает, лишь бы работала.

     
  • 2.9, Аноним (-), 11:09, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вопрос на засыпку: А на чём написаны компиляторы и интерпретаторы языков с управляемой памятью?
     
     
  • 3.12, Аноним (-), 12:39, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    За всех не скажу, но вот Roslyn, к примеру, на C#.
     
     
  • 4.13, Аноним (-), 12:53, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А сишарп на чём?
     
     
  • 5.15, Аноним (-), 13:02, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    На английском
     
     
  • 6.23, Аноним (-), 16:54, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Жирно, но доставило :)
     
  • 3.17, Аноним (-), 14:48, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    https://github.com/ghc/ghc
    > Haskell 82.1% C 10.6% Makefile 2.2% Terra 1.7% Logos 0.5% Python 0.5% Other 2.4%

    Вопрос на засыпку: А на чем написаны компиляторы языков с ручным управлением памятью?
    https://github.com/gcc-mirror/gcc/blob/gcc_5_3_0_release/libffi/src/x86/unix64
    https://github.com/gcc-mirror/gcc/blob/gcc_5_3_0_release/libgcc/config/i386/mo
    [CODE]movl %esp,%eax # Current stack,
    subl 8(%esp),%eax # less required stack frame size,
    subl $NON_SPLIT_STACK,%eax # less space for non-split code.
    cmpl %gs:0x30,%eax # See if we have enough space.[/CODE]
    https://github.com/gcc-mirror/gcc
    > C 46.1% Ada 18.4% C++ 15.1% Go 6.4% GCC Machine Description 3.5% HTML 3.4% Other 7.1%

    И что же теперь из этого следует?

     
     
  • 4.25, Аноним (-), 17:09, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос на засыпку: а во что компилируется любой язык с управляемой памятью?
     
     
  • 5.27, Аноним (-), 17:46, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вопрос на засыпку: а во что компилируется любой язык с управляемой памятью?

    И как там, в луже?


     
     
  • 6.28, Аноним (-), 17:59, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И как там, в луже?

    Тепло, комфортно и мокро.

     
  • 5.29, Аноним (-), 22:00, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В байты
     
  • 3.36, Аноним (36), 22:14, 08/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну pypy написан на питоне.
     

  • 1.16, Аноним (-), 13:22, 02/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а что, если рекомендации гугла окажутся вредными для OpenSource ? :) Кто проверит проверяющего?
     
     
  • 2.19, Andrey Mitrofanov (?), 15:43, 02/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а что, если рекомендации гугла окажутся вредными для OpenSource ? :) Кто
    > проверит проверяющего?

    Учёные, безопасники, философы. В MS-Research и на опеннет таковых с избытком!

     
  • 2.30, angra (ok), 01:16, 03/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты удивишься, но авторы кода. Данный сервис лишь показывает наличие потенциальных проблем, никаких рекомендаций кроме очевидной - посмотрите и по возможности исправьте - он не дает. Так что вычитанный тобой афоризм совершенно не подходит к этой ситуации, иди поищи еще умных мыслей для копипасты.
     
     
  • 3.34, Аноним (-), 19:41, 05/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот выдаст гуголь рекомендации, типа вот у вас тут неоптимально. Думаю не менее половины разработчиков не думая влепят предлагаемый солюшн.
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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