·

· if (strcmp( amp;proto[0],"file"))

· return 0;

· else

· WinExec(p+3,SW_SHOW);

·

·}

· else

· WinExec( amp;buff[0],SW_SHOW);

· return 1;

·

·}

·

·

· main(int argc,char **argv)

· {

· if (argc»1) file( amp;argv[1][0]);

·}

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

Если в имени файла присутствует символ “:”, то программа полагает, что имя записано в формате “протокол://путь к файлу/имя файла”, и пытается выяснить какой именно протокол был указан. При этом она копирует название протокола в буфер фиксированного размера, полагая, что при нормальном ходе вещей, его хватит для вмещения имени любого протокола. Но если ввести строку наподобие “ZZZZZZZZZZZZZZZZZZZZZZ:”, то произойдет переполнение буфера со всеми вытекающими отсюда последствиями (см. рисунок 084).

Рисунок 084

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

В первую очередь необходимо отобразить внимание на буфера фиксированного размера, расположенные в стеке. Блоки памяти, выделяемые вызовом alloc, находятся в куче (heap) и их переполнение (даже если и имеет место) не приводит к модификации адреса возврата, сохраненного в стеке.

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

В сложных программах огрехи были, если и будут всегда. Тщательное тестирование миллионов строк кода современных приложений экономически не выгодно и не практикуется ни одной компанией. С другой стороны, анализ чужого кода (а особенно в отсутствии исходных текстов) выполнить в одиночку затруднительно. Большинство ошибок обнаруживаются случайно, а не в результате целенаправленного поиска. Но существует огромное количество злоумышленников, располагающих неограниченным (ну, практически неограниченным) временем для экспериментов, поэтому, новые ошибки обнаруживаются чуть ли не ежедневно (и часто по несколько в день).

Как устроен генератор паролей?

O В этой главе:

O Алгоритмы перебора пароля

O Достоинства и недостатки словарного перебора

O Оценка стойкости пароля

O Расчет количества времени гарантирующего нахождение пароля

O Поиск пароля в худшем и среднем случаях

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

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

Словарный перебор срабатывает часто, но не всегда. Привилегированные пользователи (такие, как, например, администраторы систем) склонны выбирать бессмысленные пароли наподобие “acsW%9*m$”, надежно защищая себя от словарной атаки. В таком случае приходится прибегать к последовательному перебору всех возможных паролей. Такой подход гарантирует, что искомый пароль рано или поздно будет найден, но требует значительного времени на поиск, часто сравнимый со временем жизни планет и звезд.

Поэтому, последовательный перебор целесообразен только в поиске коротких паролей или паролей, состоящих из небольшого количества символов. Некоторые системы аутентификации ограничивают максимальную длину пароля, позволяя гарантированной найти его путем перебора за приемлемое время. Случается, что такое ограничение возникает неявно в результате программной ошибки реализации (например, фактическая длина пароля LAN Manager составляет семь символов, поскольку две половинки четырнадцатисимвольной строки обрабатываются независимо друг от друга [336]).

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

Но что означает «короткий» и «длинный» пароль? Три символа, семь символов, десять символов, семьдесят шесть символов… Пароль какой длины может считаться надежно защищенным от перебора? Строго говоря, ни какой, поскольку любой пароль конечной длины можно подобрать за конечное время. Но в зависимости от скорости перебора и длины пароля время поиска может оказаться очень большим и даже превысить период существования самой Вселенной! Это ограничивает разумную длину пароля сверху. А время актуальности защищаемого ресурса огранивает ее снизу.

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

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