Главная > Uncategorized > Кто на самом деле придумал искать уязвимости методом fault injection

Кто на самом деле придумал искать уязвимости методом fault injection

Вызывает антирес
Ваш технический прогресс:
Как у вас там сеют брюкву —
С кожурою али без?..

Один из самых распространенных способов поиска уязвимостей методом черного ящика является «fault injection». Идея метода крайне проста: а давайте-ка мы в качестве входных данных передадим приложению всякий «мусор» и посмотрим, что будет? Если в выходных данных мы увидим специфические ошибки (например, синтаксические ошибки парсера SQL), то с большей долей вероятности можно делать вывод о наличии уязвимости.

Так вот оказывается (!!!) этот метод придумали ребята из Cenzic всего-то в 2007 году. Об этом свидетельствует патент №7185232 с заголовком «Fault injection methods and apparatus». За прошедшие 4 года вокруг патента разгорелась настоящая война: Cenzic подавала иски на HP и IBM с целью признанения факта незаконного использования Великого Научного Открытия в продуктах этих компаний.

Против патента открыта Интернет-кампания, с ее подробностями можно ознакомиться вот тут: http://stop232patent.com/

p.s. Пора, пора уже патентовать time-based техники, а то опередят!!!

Реклама
  1. 01.03.2011 в 01:04

    Здравствуйте,

    Интересная заметка. Однако, не соглашусь с определением Fault injection. В моем понимании ( а так же в понимании многих авторов, начиная с конца 90-х годов ) fault injection это внедрение ошибки внутрь программы, то искурственный возврат ошибочного значения.
    А «в качестве входных данных передадим приложению всякий «мусор» и посмотрим, что будет» — это самый бездумный fuzzing и все.
    Если ребята запотентовали fuzzing, то добыча их будет еще более внушительная. Если все-таки fault injection, то термин это встречается намного ранее 2007 и они негодяи редкостные.

    Спасибо за заметку. С победой на ructf quals! :)

    • 01.03.2011 в 08:26

      Приветствую!
      Ну во-первых, я не пытался дать определение: в постах с тегом «просто о сложном» я описываю концепты, как говорится, «на пальцах» ;)
      А во-вторых, не могу согласиться с вами: вы путаете концепт и релизацию.
      Поясню. Цель любого тестирования — убедиться в качестве тестируемого объекта. Далее, виды тестирования можно классифицировать в зависимости от точки приложения тестов: есть функциональные тесты, нагрузочные тесты, тесты устойчивости ПО в исключительных ситуациях и т.п.
      Так вот fault injection — это как раз метод реализации тестирования устойчивости ПО в исключительных ситуациях. Реализован может быть по-разному: fuzzing для black-box тестирования, преобразование программ для white-box тестирования и т.п. Такие дела.
      Так что ребята из Cenzic запатентовали реализацию концепта fault injection для black-box тестирования.

      >> С победой на ructf quals! :)
      Спасибо за поздравления! :)

  2. 01.03.2011 в 09:53

    Про тестирование соовсем путаница получилась: функциональная, нагруочная, тест устойчивости — тут скорее классификация не по «точке приложения», а по назначению ( или цели ) тестирования. А вот по точке ввода тестов можно услоно разделить: тестирование через интерфейсные функции, через файлы, через переменные окружения, fault injection.
    Тестируется в конечном счете корректность программы реагировать на внешние воздействия. Воздействия — это нет только входные параметры функций, но и:
    — потоки данных из консолей, сокетов, пайпов и т.д.
    — переменные окружения
    — содержимое файлов
    — значения, возвращаемые системными функциями.
    Считаю, что fault injection относится только к последней категории воздействий. Всем остальным занимаются fuzzers разных типов.
    Black-box, white-box — это совсем другие характеристики. Все вышеперечисленное можно тестировать и так и сяк.
    Вот как-то так :)

    • 01.03.2011 в 12:21

      Да-да-да, конечно, по цели, я уже о следующем чем-то думал, когда это писал )

      Поясню свою позицию, а так же то, что black-box и white-box очень при чем.
      1. Есть цель. В данном случае, тест устойчивости.
      2. Есть ограничения. Это то, как мы можем взаимодействовать с объектом оценки. Это неотъемлемая часть постановки задачи. Мы не всегда вольны выбирать средства взаимодействия, к сожалению. Отсюда, как раз, разделение по тому, что мы можем: black-box, white-box с модификацией кода, white-box с модификацией окружения и т.п. Я еще раз хочу подчеркнуть — ограничения являются неотъемлемой частью задачи.
      3. Дальше в каждой конкретной постановке задачи есть варианты решения. Вот в постановке задачи с ограничениями black-box самый очевидный вариант решения — это fuzzing.

      Примерно так.

      • 01.03.2011 в 14:10

        Нельзя давать обстоятельствам брать вверх :) Нельзя модифицировать код? Нет исходных кодов? Даже в этой ситуации fault inject в возвращаемые значения возможен. Если автор не против, дам ссылку на свой блог здесь http://artem.ufoctf.ru/?p=433. Gray-box с исполняемым кодом.

    • 01.03.2011 в 12:25

      Да, самое главное. Я написал, что очевидный способ — это fuzzing. А идея как раз — это fault injection, т.е. вызвать fault или протестировать обработчики исключительных ситуаций через передачу некорректных данных. Вот :)

      • 01.03.2011 в 14:12

        Передача неверных значений не совсем «inject». Fault pass … или еще как-нибудь. В общем в методологии модульных тестов давным давно принято посылать функциям граничные и заведомо неверные значения. Все равно не согласен, что это fault inject.

  3. 01.03.2011 в 14:19

    Artem Blagodarenko :

    Передача неверных значений не совсем «inject». Fault pass … или еще как-нибудь. В общем в методологии модульных тестов давным давно принято посылать функциям граничные и заведомо неверные значения. Все равно не согласен, что это fault inject.

    Возможно (возможно!), такое употребление повелось в отношении веб-приложений, начиная вот с этой статьи «Web Application Security Assessment by Fault Injection and Behavior Monitoring» (2003 год).

    • 01.03.2011 в 14:46

      Не в ту ветку ответил. Последнее сообщение в эту ветку попало в ветку пониже.

  4. 01.03.2011 в 14:24

    Artem Blagodarenko :

    Нельзя давать обстоятельствам брать вверх :) Нельзя модифицировать код? Нет исходных кодов? Даже в этой ситуации fault inject в возвращаемые значения возможен. Если автор не против, дам ссылку на свой блог здесь http://artem.ufoctf.ru/?p=433. Gray-box с исполняемым кодом.

    Конечно, не против! А я уже вчера прочитал )

    • 01.03.2011 в 14:27

      Это здорово, а то вот я труды вашего коллектива читал ( о taint много интересного, даже заявка на грант от вас попадалась ), а вы мои нет :). Хотя, разумеется по объективным причинам. Не постил я их еще в приличных журналах еще.

    • 01.03.2011 в 14:45

      Да, признаю. Я смотрел на термин с колокольни приложений. Относительно приложений все иначе. В статье ребята, кстати, попытались переложить техники для классических приложений на web-приложения. Наверное пришлось что-то иначе представить. Статью прочитал по горизонтали пока что. Почитаю внимательнее. Спасибо за ссылку.

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: