Недекларированные возможности ПО Опции

[Altair]

Есть какие-либо материалы по поиску недекларированных (для Юты: это пишется слитно!)) возможностей в ПО?

В сети очень мало информации, толком- ничего, только введение.
Хотелось бы узнать какие существуют методы поиска и анализа ПО.

[Malice]

Разжуй плиз поподробней что надо то, для нас, для бедных..

[Altair]

Имеется программа. Код ее доступен. Будем считать, что код написан в стиле только функционального программирования.
По ГОСТу, для этой программы есть 5 документов:

• Спецификация (19.202-78)
• Описание программы (19.402-78)
• Описание применения (19.502-78)
• Пояснительная записка (19.404-79)
• Текст программы (19.401-78)

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

Вопрос в том, какие методы есть обнаружения таких недокументированных (недекларированных) возможностей в ПО?

[Malice]

Я так понимаю - эвристический анализ нужен на предмет принадлежности программы к троянам Копать в сторону разработки антивирусов и эмуляции выполнения кода. Или выполнение кода по VM со слежением за результатами работы.. Анализ результатов - попытка подловить код на выполнинии заранее известных тебе функций, заведомо названных недокументированными..

[Altair]

Не годится.
Эвристический анализ основан на том, что существуют какие-либо паттерны, используемые при написании троянов, вирусов и т.п.
Но у меня задача немного другая, заметь, у меня есть описание и сама система. Коротко если, то надо найти то, что не описано!

[volvo]

Коротко если, то надо найти то, что не описано!

Не все так просто... Смотри, простейший пример:

Описание: "... Функция нахождения минимального элемента вектора ..."
Что имеем:

function compare(a, b: integer): integer;
begin
  { ... }
end;

function get_min(V: vector): integer;
begin
  min := maxint;
  for i := 1 to n do
    if compare(min, V[i]) < 0 then min := V[i];
  get_min := min;
end;

compare - не описана... Однако используется в описанной функции. Но МОЖЕТ быть расценена и как недокументированная функция... Что делаем?

[Malice]

Имхо - нельзя найти то, не зная что.. Как вариант - найти карту покрытия кода (коряво выразился, но это то, к чему код обращался и который выполнялся после тестирования кода). Весь оставшийся код (т.е. не используемый по сути, но присутствующий) - подвергнуть анализу на предмет наличия некоего умысла..

[Lapp]

Поскольку вредоносное действие скорее всего нацелено на диск (хотя и не обязательно), я бы попробовал отследить в первую очередь обращения к файловой системе. Если это виндусовый код - то и к реестру. Есть набор названий файлов (или ключей), которые для данной программы являются данными - их можно сразу отсечь, что облегчит поиск.

Но только если автор проги хороший программист, то спрятать обращение можно. Например, вредоносное действие может быть запланировано на один-едиственный момент в месяце - например, в 12:34:56 каждого 14-го числа. Тестирование проги в любой другой день ничего не выявит.. Название файла, естественно, тоже не хранится в коде, а раскодируется "на лету" с применением даты и времени как ключа.

Какой тут можно применить софт, сказать затрудняюсь..

[Altair]

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

compare - не описана... Однако используется в описанной функции.

Нет, это легко проверяется, в описании программы эта функция должна быть поисана (иначе просто сразу на лицо несоответствие ГОСТу и программу просто бракуем)


Что бы более точно приблизить к задаче приведу пример.
Допустим вы - военная организация.
Заказываете разработку некоторого ПО (например ОС)
Вам поставляют Линукс заточенный для ваших нужд.
Как вы сами понимаете, хоть вам и дали исходные коды - гарантии того, что в тысячах строк кода нет недекларированных возможностей просто нет! (а может все данные будут сливаться кому-нибудь?)
Конечно возможно провести ручную верификацию, но стоимость такой проверки будет высокой.
Вообще стоимость ручного поиска таких "фич" системы будет высокой.
Поэтому неплохо бы автоматизировать этот процесс, то, что пока не понятно как, не значит, что это невозможно!

[SKVOZNJAK]

У военных есть своя версия ос. Лучший способ избежать троянов, не заказывать ничего важного сторонним разработчикам Если это линукс, свои разработчики могут без спроса использовать любые общедоступные исходники. Есть вероятность что кто-то узнав о такой практике попытается скормить кривые исходники юзерам и программистам в надежде что они попадут и к военным. Но сделать это будет сложнее.

[hardcase]

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

Т.о. чтобы выяснить - делает ли система то, что нужно, или занимается фигнёй, нам нужно прогнать тесты, запросив их у разработчика, а также написать их самим. Ибо ни одна более менее сложная система не разрабатывается в отрыве от заказчика - в диалоге с ним постоянно модифицируется спецификация софтины и т.п.

За что я люблю .NET, так это зато, что в ней реализовано 2 параллельные системы доступа. Это делегирование прав юзверя, и делегирование прав кода (код-зоны).
Если мы имеем подозрительный код - мы навешиваем ему жесткие атрибуты безопасности, типа запрета доступа к реестру и диску. И даже если этот код будет выполняться с правами админа, он никоем разом не сможет залезть в реестр или записать чегонить на диск. Такая вот магия....

[Altair]

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

Эге-гей, давай не будешь ты за все ПО отвечать!
АСУ в лучшем случае сопровождаются планом наката, документом по описанию доступа и руководствами администратора и пользователя... + различные документы для приемки (протокол приемо-сдаточных испытаний, общее описание системы и т.п.) а работают такие системы с вполне важными вещами, такими, как договора например, и используют такие системы вполне солидные компании (в том числе и банки)...

Ибо ни одна более менее сложная система не разрабатывается в отрыве от заказчика - в диалоге с ним постоянно модифицируется спецификация софтины и т.п.

Конечно, но заказчик следит за выполнением бизнес-требований а не подобных вещей...
Причем в лице заказчика обычно выступает штатный аналитик компании-заказчика.

а вот насчет последнего твоего заявления про .NET - это интересно... честно говоря поставлен в тупик т.к. я сторонник Java... пожалуй даже запрошу консультацию у знающих людей, поэтому постараюсь без ответа не оставить...

[hardcase]

а вот насчет последнего твоего заявления про .NET - это интересно...

вот ссылочка Introduction to Code Access Security

[Dark_Snake]

Как здесь уже было сказано можно использовать "карту программы".
Конечно сложность проверки зависит от размера программы но мы имеем описание функций программы то есть некий тестовый набор. Предположим у нас есть следующая программа:

var 
 i:byte;
begin
 readln(i);
 if i>=3 then i:=i+1;
 case i of
  1: writeln('1');
  2: writeln('2');
  3: writeln('Send data');
  4: writeln('3');
  ....
 end case;
end.

Строчка которую мы должны найти наглядна. Итак, как поступить? Обычно этот сенд дата выполняется не сразу, а при каком то условии, допустим то же условие времени. Некоторая проверка будет где то в программе. Как нам выявить этот кусок. Мы начинаем проходить трассировку кода используя возможные значения или большую их часть. Так проходя значения 1,2,3,4,5 ... мы выявим строчку к которой ни разу не было обращения за время тестирования.

Второй вариант. Мы опять же знаешь порты и файлы с которыми работает программа. Мы идем по коду обнаруживаем допустим строку
assign(f,s);
обращение к файлу идем чуть выше ищем откуда берется s, например, из поля ввода, значит все в порядке и мы пропускаем эту контрольную точку. Если находим что то вроде assign(f,'%windir%\system32\...') или же значение s в ходе отмотки назад остается не известным, или не совпадает с документированным, то следует отметить эту точку как потенциально опасную для ручной проверки.

[SKVOZNJAK]

Против грамотно написанного вин трояна трассировка наврят-ли поможет. Что-то абстрактно нехорошее чувствоваться будет, но конкретно... Вот как выявить уязвимость к вредоносной информации, а что сотворят будущие патчи и обновления системы? Это опять по новому всё проверять. Только полный доступ к исходникам широкого круга лиц и компиляция приложения самим пользователем, на своём компиляторе, даёт какую-то гарантию.

[Abit]

Если вам тупо нужно проверить программу на вредоносность - сдайте её в лабораторию касперского с их сайта - они бесплатно вам проверят всё чего она делает

[hardcase]

Если вам тупо нужно проверить программу на вредоносность - сдайте её в лабораторию касперского с их сайта - они бесплатно вам проверят всё чего она делает

Глупость какая.
Они на наличие известных вирусов в исполняемом файле проверяют, а не производят тестовое покрытие.

[Чужак]

Ребят, ну вы даете. Я прям не знаю....
Хоть я и не программист-профи, но если есть малейшее подозрение
программы на "м@довошки", то первое, что приходит в голову-её надо изолировать.
Даже не так, как предлагал hardcase-в особую среду, а просто-механически.
Не ставить её на комп, где храниться важная информация.
Ставить её на компьютер, НЕ подключенный к Интернету (вдруг она может его сканировать,
а затем куда-то сливать информацию?), вообще не завязанный ни в какую сеть, автономный.
Вот на нем-то и начинать её проверку. Это минимум компьютерной безопастности,
который должен знать любой пользователь.
(А уж на выключенном компьютере не один вирус не работает ).

Сообщение отредактировано: Чужак - 23.08.2007 3:14