Бесплатный сыр без мышеловки?

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

Mеня часто спрашивают, можно ли доверять бесплатному программному обеспечению, или ПО с открытым исходным кодом (Open Source Software, OSS)? Этот вопрос возник задолго до появления в начале 90-х гг. Linux и различных ОС от Berkeley Software Distribution (BSD), когда стало завоевывать популярность программное обеспечение для защиты систем UNIX, например COPS и Tripwire. Привыкнув платить огромные деньги за необходимые им программы, организации с вполне понятным опасением относились к бесплатному программному обеспечению от неизвестных поставщиков.

Ряд последних событий только усилил эти опасения. Оказалось, что несколько сайтов, один из которых был разработан специально для максимально жесткого тестирования систем обнаружения проникновения (Intrusion Detection System, IDS), содержали лазейки в сценариях установки. Каждый, кто устанавливал размещенное там программное обеспечение, подвергал свою систему риску проникновения. Злоумышленники искусно замаскировали эти лазейки, поэтому они казались частью обычного процесса конфигурации.

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

ЧТО ЗА ЛАЗЕЙКОЙ

Программисты добавляют лазейки, чтобы получить контроль над системами, где установлено их ПО. Когда речь идет о коммерческом программном обеспечении, лазейки называют по-другому, например бюджетами для сопровождения, и они хорошо известны владельцам таких систем. Впрочем, далеко не всегда. В конце 80-х гг. Digital Equipment Corporation (DEC, впоследствии она была поглощена Compaq Computers) включила в систему несколько бюджетов системного уровня с паролями по умолчанию, так что инженеры компании с легкостью могли получить доступ ко всей инсталляционной базе ОС VMS. Примерно тогда же в системы Aviion компании Data General было добавлено несколько специальных опций в команду для администрирования принт-сервера. Недокументированные функции позволяли получить доступ к ядру системы. Кроме того, специалисты AT&T по обслуживанию мини-компьютеров 3B2 в офисах заказчиков могли использовать ошибку в программе экспресс-обслуживания для выполнения команд с неограниченными полномочиями. Созданные этими производителями лазейки, вероятнее всего, просуществовали до начала 90-х гг.

Лазейки в UNIX также имеют долгую историю. Кен Томпсон, разработчик ОС UNIX, признался на церемонии вручения ему премии Association for Computing Machinery (ACM) в 1984 г., что у него есть волшебный пароль, с помощью которого он мог войти в UNIX под видом любого пользователя. Томпсон оставил лазейку в программе проверки паролей, а она, как известно, включается в программу регистрации при входе пользователя в систему. Не свободны от таких сюрпризов и новые версии UNIX, поскольку компилятор имеет в своем составе код «троянского коня», который распространяет код лазейки на новые версии компиляторов. Волшебный пароль Томпсона — самый знаменитый и самый сложный код лазейки.

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

В 1982 г. Билл Джой, один из основателей Sun Microsystems, будучи еще студентом университета шт. Калифорния, включил версии sendmail с лазейками в ленту с дистрибутивом и разослал в 50 компаний, создав тем самым первую структуру BSD. Самой вопиющей лазейкой была «дополнительная» команда SMTP, так называемый эксперт, — она предоставляла оболочку с неограниченным доступом (root shell) любому, кто входил с секретным паролем. Последующие усовершенствования sendmail уничтожили пароль, поэтому простое обращение к sendmail с командой wiz приводит лишь к появлению запроса root.

Производители рабочих станций UNIX коммерческого уровня, Sun и Hewlett-Packard, ликвидировали код лазейки-эксперта в sendmail. Однако они как-то упустили из виду другую, debug, с помощью которой любую команду длиной не более одной строки можно было выполнить с полномочиями root. Появившийся в ноябре 1988 г. «червь» Internet использовал команду отладки для загрузки и выполнения короткой программы, обеспечивавшей распространение «червя». Когда, наконец, выяснилось истинное значение отладки, ее также убрали из исходного кода sendmail. При этом третья лазейка, decode, была не более чем псевдонимом в конфигурационном файле, ее удалили еще до этого.

ЛАЗЕЙКА В БУДУЩЕЕ

С 80-х гг. общеизвестная история лазеек в открытом ПО становится весьма скучной. Разработчики UNIX исполнились поистине религиозного рвения и желания, чтобы их ОС получила повсеместное распространение, а наличие лазеек — не лучший способ завоевать признание на коммерческом рынке.

Однако лазейки никуда не исчезли. Наибольшую известность в то время получила, пожалуй, лазейка, автором которой была Microsoft. В Microsoft Excel имелись фотографии разработчиков и различные игры, но доступ к ним становился возможным только тому, кто знал, как открыть «потайную дверь». Она называлась «пасхальные яйца» (см. «Ресурсы Internet»). Сейчас используется множество версий Excel, хотя не все они прячут в себе игры.

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

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

Впрочем, проделать такое для крупных пакетов бесплатного программного обеспечения очень непросто. В версии 8 Berkeley Internet Name Daemon (BIND), свободно распространяемого ПО поддержки DNS, 170 тыс. строк исходного кода. К тому же в последние годы в BIND обнаружено множество ошибок, что привело к появлению многочисленных заплат. Обеспокоенному программисту остается только проанализировать различия между прошлыми и новыми версиями, которые могут сводиться к нескольким строкам кода. Большинство же предпочитает доверять распространителю дистрибутива, вместо того чтобы пытаться читать — и понимать — исходный код. Это доверие, как правило, оправдано, но как пользователь может быть уверен, что работает с аутентичной версией исходного кода?

Весной 2002 г. несколько сайтов с дистрибутивами программного обеспечения оказались взломанными, и пользователи могли загрузить программные пакеты с незаметными модификациями. На двух сайтах распространялось ПО Internet Relay Chat (IRC), на одном, monkey.org, было размещено ПО (fragrouter), написанное известным экспертом в области защиты Дагом Сонгом.

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

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

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

Пользователи открытого программного обеспечения могут защитить себя от модифицированного исходного кода посредством подписей GNU Privacy Guard (GPG), они имеются для большинства подобных пакетов. GPG — это последователь Pretty Good Privacy (PGP), программного обеспечения, опубликованного Филиппом Циммерманом в 1991 г. и впоследствии лицензированного Network Associates.

Каждый, кто посещал сайт открытого ПО, вероятно, видел файлы подписей, хотя, не исключено, не обращал на них внимания. Файлы подписей для программных пакетов могут ввести в заблуждение своими расширениями .asc, что означает ASCII — (текстовая) версия цифровой подписи. В упомянутой в «Ресурсах Internet» статье из Linux Journal дается информация о том, как пользоваться GPG и PGP для проверки подписей пакетов свободно распространяемого ПО. Успешная проверка служит гарантией того, что пакет не изменялся с момента его подписания. Лицо, подписавшее пакет, гарантирует: ключ подписи хранится в секрете, а исходный код не содержал лазеек на момент подписания.

ПРЕДМЕТ ДОВЕРИЯ

Итак, мы возвращаемся к вопросу о том, можно ли доверять открытому коду. Справедливо ли считается, что открытый код в меньшей степени заслуживает доверия, нежели коммерческое ПО? Одним из аргументов против открытого кода является отсутствие юридических лиц, которые можно было бы привлечь к ответственности за ошибки по суду. Между тем наиболее широко используемое коммерческое программное обеспечение предлагается сейчас на условиях лицензии End User License Agreement (EULA). Согласно ее правилам, конечные пользователи должны согласиться с тем, что производитель несет ответственность только за носитель, на котором распространяется ПО. Поэтому соображение об ответственности не выдерживает критики.

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

Мотивация разработчиков, создающих открытое ПО, даже сильнее, по сравнению с теми, кто работает в больших компаниях и не надеется получить персональную известность. Кроме того, когда детище «свободных» программистов — исходные коды — публикуется, они подвергаются детальному анализу со стороны сотоварищей по цеху. Популярность свободно распространяемых программ основывается на их способности решить вполне определенную задачу, обеспечить надежную защиту, причем так же хорошо, или даже лучше, как и коммерческий продукт. Весь маркетинг открытого программного обеспечения ограничивается тем, что программа должна работать в соответствии с обещанными возможностями, и для нее предоставляется поддержка.

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

? CMP Media LLC

Ресурсы Internet

Текст речи Кена Томпсона «Reflections on Trusting Trust» при вручении премии ACM в 1984 г. приведен по адресу: http://www.acm.org/classics/sep95/.

На сайте, посвященном «пасхальным яйцам», содержится список различных лазеек Excel. Адрес сайта: http://www.eeggs.com/tree/279.html.

В работе «Secure Programming for Linux and Unix HOWTO» Дэвида А. Виллера приводится обсуждение преимуществ и недостатков Open Source Security. С ней можно ознакомиться по адресу: http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html#OPENSOURCE-SECURITY.

Страничка Irssi, где разъясняются последствия модификации файла конфигурации, находится по адресу: http://www.irssi.org/?page=backdoor.

Майкл Д. Байер в первой части своей работы «Paranoid Penguin: GPG: The Best Free Crypto You Aren?t Using» объясняет, как пользоваться GNU Privacy Guard (GPG) для проверки файла подписи для загружаемого архива. Она расположена по адресу: http://www.linuxjournal.com/article.php?sid=4828.

назад