 |
|
|
|
Безопасен ли открытый код?
Безопасен ли открытый код? Сторонники программ с открытым исходным кодом настаивают на его повышенной безопасности, противники же, наоборот, считают, что возможность просмотреть исходники лишь вредит. Попробуем разобраться, кто прав В последнее время явно заметен всплеск публикаций, в которых недвусмысленно намекают, что Open Source отнюдь не так безопасен, как считают его сторонники [1], а сам факт наличия исходного кода никак не влияет на защищенность систем и приложений и даже, более того, вредит. Как подтверждение своих слов авторы приводят самую разнообразную статистику [2], показывающую количество найденных уязвимостей и выигрышную позицию проприетарных приложений, исходный код которых недоступен (безопасность через сокрытие, Security through obscurity). На первый взгляд авторы публикаций полностью правы, но только если не пытаться переосмыслить все проблемы с разных точек зрения. В статье я не буду идти привычным путем, т.е. рассказывать, что какой-то путь более правильный, не буду сужать рамки, а попробую посмотреть на проблему безопасности немного шире. Все сказанное в статье является субъективным мнением автора, которое основано на многолетнем опыте использования Unix/Linux и Windows, устранении последствий вирусных инфекций и анализе причин их возникновения, да и просто здравом смысле. Немного о статистике Есть три вещи в мире: Марк Твен Противоборство Open Source и проприетарных решений продолжается очень давно, во всяком случае, я прочитал первую статью на эту тему еще в прошлом веке, поэтому уже можно, наверное, сделать какие-то выводы. Компьютерный мир, перенесший несколько сотен эпидемий и выдержавший миллионы самых разных вирусов, за это время не рухнул, ни одной идее так и не удалось полностью победить, отвоевав заветные 100%, и, главное, показать преимущество на практике. Но, даже несмотря на все замечания скептиков, Open Source становится все более привлекательным и уже не является уделом энтузиастов: многие проекты поддерживаются фондами, имеют серьезный, в т.ч. финансовый, потенциал и штатных программистов. Все как у коммерческих разработчиков, вот только код они не прячут. Чтобы не быть голословными, обратимся к статистике Netcraft за март и апрель 2012 года [3]. Таблица 1. Количество веб-серверов (по данным Netcraft)
Посмотрим еще, как дела на рабочих столах. По версии Netmarketshare [4] и StatCounter [5]: Windows – 92%, Mac OS X – 7%, Linux – 1%.
Рисунок 1. Статистика использования ОС на ПК по версии Netmarketshare На рабочих столах по-прежнему лидирует Windows, но уже заметна немалая доля Mac OS X. Причем их соотношение по регионам существенно отличается. Так, в России Mac OS X пользуются всего 2,13%, в США – более 10%. Вывод напрашивается сам собой: на критических приложениях, там, где нужна стабильность, скорость, безопасность и масштабируемость, используются приложения с открытым исходным кодом, им доверяют специалисты и они популярны. Где решает пользователь, там лидирует Windows. Вероятно, найдется читатель, который скажет, что по одним лишь веб-серверам такой вывод делать очень опрометчиво, ведь бизнес использует и другие приложения, где соотношение уже не так ярко выражено, и будет полностью прав. Хотя ситуация с почтовыми серверами, СУБД, VoIP, FTP, CMS и некоторыми другими не намного хуже, здесь тоже Open Source-приложения не пасут задних, только нет хорошей статистики. То есть факт остается фактом: наличие открытого исходного кода никоим образом не сказывается отрицательно на популярности продукта, а в некоторых проектах предпочитают именно такие решения, ведь часто стандартной функциональности не хватает, и необходимо серьезное вмешательство в код. Например, всем известный факт: в Twitter, обрабатывающем миллионы запросов, используется переработанная версия СУБД MySQL, которую можно легко найти в Сети. Чуть позже мы еще вернемся к этим цифрам, но вот здесь можно обнаружить игру со статистикой и фактами. Ведь обычно, когда спорят о недостатках Open Source, предпочитают смешивать все аргументы в кучу, не разделяя небольшие проекты и серьезные приложения, рассчитанные на использование под высокой нагрузкой. И что, те и другие имеют одни и те же недостатки? Не можем же мы сравнивать тот же Apache с приложением, написанным энтузиастом и поддерживаемым в свободное время. Очевидный ответ – нет. Более того, если так подходить, то можно поставить в один ряд и любой проприетарный проект, разработанный корпорацией или программистом-одиночкой. На первом же графике [2] мы видим, что по количеству найденных уязвимостей опять же лидируют компании, продвигающие Open Source-проекты – различные Enterprise Linux, Apple, Oracle/Sun, Google. Корпорация Microsoft занимает пятое место в этом антирейтинге с учетом позиции на март 2012-го. Достоверность данных оставим на совести докладчика (доклад прозвучал на RSA Conference 2012), но опять же задумаемся над методом представления. Мы не должны забывать, что под словом «Linux» подразумевается не только ядро, но и ОС со своим составом приложений, разрабатываемых разными программистами, некоторые ставятся «из коробки» или штатной системы пакетов, а поэтому уязвимость в некоторой библиотеке или утилите (фактически пакете) может быть причислена к самому дистрибутиву. То есть безопасность целого часто зависит от частного, и дырявый давно не обновляемый плагин к веб-браузеру может свести на нет все усилия разработчиков дистрибутива. Это, кстати, хорошо показано на графиках в [2], где видно, что количество уязвимостей в ОС на несколько порядков меньше, чем в приложениях. Отличный пример для сравнения OpenBSD: безопасная, с открытым исходным кодом ОС, у которой в установке по умолчанию за время разработки найдено всего две уязвимости, позволяющие выполнить атаку удаленно. И все потому, что базовую систему полностью контролирует основная группа разработчиков: установи веб-сервер, и общая защищенность уже будет зависеть и от этого компонента. Например, недавно обнаруженная уязвимость в OpenSSL (CVE-2012-2110) будет относиться ко всем дистрибутивам Linux/Unix (библиотека используется многими приложениями, а поэтому часто установлена по умолчанию), как Enterprise, так и любым другим, то есть теоретически из одной проблемы мы получим несколько уязвимостей в разных дистрибутивах. А еще добавим старые версии дистрибутивов и приложений, которыми мало кто пользуется. Теперь умело это все посчитаем/обыграем и можем на цифрах убедить кого угодно, что Linux – это проблема безопасности (а уж поверьте, те, кто в этом заинтересован, считают именно «правильно»). В то же время продукты от Microsoft (как и большинство проприетарных решений) идут как бы сами по себе, т.е. «пустые». А если Windows оснастить тем же набором приложений «на все случаи» и затем посчитать их ошибкой самой MS? Как это повлияет на статистику и место в антирейтинге? Если брать во внимание любые другие дистрибутивы Linux, нужно не забывать, что есть стабильные ветки с долгим сроком поддержки (вроде LTS в Ubuntu) – приложения в них отбираются особенно тщательно – и тестовые/промежуточные релизы, в которых обкатываются новые технологии. За обновлениями и стабильностью работы LTS-версий пристально следят, в случае обнаружения критической уязвимости патчи выпускаются в течение одного-двух дней, причем это было характерно для Open Source как в 2007 году [6], так и сегодня. Подход к устранению проблем в решениях с отрытым исходным кодом как минимум вызывает уважение. В промежуточных релизах вполне могут находить уязвимости, которые также портят статистику, но такие версии редко используются в производственной среде и ориентированы больше на энтузиастов. Уязвимость vs Безопасности «...настоящая правда всегда неправдоподобна… Федор Достоевский Наличие уязвимости – это потенциальная возможность для проведения атаки, и здесь статистика [2] для того же RHEL по сравнению с Microsoft выглядит несколько удручающей, если отвлечься от нескольких важных моментов. Достаточно вспомнить, что уязвимости имеют несколько характеристик, важные из которых: опасность, вектор эксплуатации (локальная или удаленная) и наличие эксплоита. Собственно говоря, они связаны, так как если в характеристике сказано, что можно выполнить команду удаленно, да и еще и готов эксплоит, всегда получим высшую категорию опасности. Кроме того, немаловажную роль играет и версия продукта, ведь часто проблема может быть только в определенном релизе, который давно уже не актуален. И в плюсы любой характеристики можно отнести графу – наличие патча. Для любого сисадмина именно последняя графа означает, насколько спокойно он будет спать. Если патч есть, система автоматического обновления сама предложит его установить, и он может даже не знать, что, оказывается, была какая-то серьезная уязвимость. Но вот отчет в [2] эту сторону немного обходит. Для примера сверим данные на Secunia.com для всех дистрибутивов Red Hat и Windows Server 2008. В списке всех решений для Red Hat в графе Unpatched стоит 0, т.е. проблемы если и выявлены, то уже устранены [7], и о них можно забыть. Теперь смотрим состояние в Windows Server 2008 и обнаруживаем, что около 2% уязвимостей до сих пор не устранены [8] (3 из 173), причем, судя по пустому отчету за 2012 год, эти проблемы давние (обнаружены в 2010-м и имеют статус Moderately critical). Для Windows 7 не устранено 5% уязвимостей, причем как минимум одна имеет статус Highly critical. «Окно уязвимости» (т.е. время от обнаружения проблемы до выпуска патча) в проприетарных продуктах занимает по времени до пяти недель (за редким исключением). Понятно, что разработчики должны все проанализировать, протестировать и так далее, но это достаточно большой срок.
Рисунок 2. Отчет Secunia по уязвимостям Windows 7 Скажите, что более безопасно: RHEL, который официально не имеет проблем, или Windows? Чем подход лучше? Причем точно такая ситуация была и год, и два, и пять лет назад – Microsoft всегда был в «должниках», не закрывая все найденные уязвимости. Согласно данным SecurityLab [9], за 2011 год было описано 4733 уязвимостей, из них производители устранили 58%, для 7% доступны инструкции по решению проблемы. Здесь уже вопрос не в том, доступен или нет исходный код, а в отношении разработчика к поддержке своего продукта. А ведь в покупку проприетарного решения вложены средства, и немалые. Более того, если администратор, использующий Open Source, знает о проблеме и не видит патча, он теоретически может сам найти и изменить проблемный кусок кода. Но об это чуть дальше. Вот в итоге и получается, что «червь Conficker по-прежнему опасен» (с) Microsoft [10], а ведь вирус не молодой – в ноябре ему уже будет пять лет. Интересно, что среди продуктов, имеющих уязвимости «нулевого дня» (т.е. те, которые хакеры уже используют, а разработчики еще о ней и знать не знают), судя по отчетам последних лет, нет Open Source-решений. А вот по Windows ситуация такая. «По сравнению с другими операционными системами у продукта от компании Microsoft их было найдено больше всего. Причем линейка ОС Windows держит лидерство как в общем зачете (92 уязвимости), так и в индивидуальном – только у этих ОС в отчетный период было обнаружено две критические уязвимости». При этом важное замечание имеет то, что «При учете уязвимостей во внимание не принимались уязвимости в ПО сторонних производителей». Этот отчет немного не соответствует [2]. Какой более правильный? Поэтому главный вывод делаем такой: статистика – вещь очень тонкая и сложная, одни и те же цифры можно интерпретировать по-всякому. Так давайте не смешивать сухую статистику и безопасность. Выручает ли анализ кода? Противник, вскрывающий ваши ошибки, Леонардо Да Винчи Опыт показывает, что код пишут везде одинаково, как в Open Source, так и закрытых проектах, везде работают люди, имеющие разный опыт и совершающие одинаковые или примерно одинаковые ошибки. Среднестатистически в любом приложении можно найти ошибки вне зависимости от лицензии, доступности исходного кода, количества и опыта разработчиков и так далее. Главный тезис сторонников Open Source – возможность анализа кода всеми желающими, в итоге разработчик не сможет спрятать закладку, а программа гарантировано не будет иметь незадекларированные функции, а если такие есть, их рано или поздно найдут. В принципе все понятно: код открыт, просмотреть его может любой, а значит, спрятать что-то тяжело. Кроме того, в Open Source приходится держать марку, так как плохой код будет виден, что может сказаться на репутации проекта. Как бы там ни было, в открытых проектах пишут хорошо, что подтверждает отчет тестинговой компании Coverity, которая начиная с 2006 года совместно с американским Отделом национальной безопасности проводила исследования ПО с открытым и закрытым исходными кодами. По результатам 2011 года оказалось, что открытый исходный код как минимум не уступает по качеству проприетарному [11]. Но у противников здесь свой аргумент: даже небольшая программа может иметь тысячи строк кода, а поэтому найти закладку или ошибку просто невозможно, это все равно, что искать иголку в стоге сена. Особенно это проблематично человеку со стороны, не имеющему соответствующей подготовки и опыта. Да вообще будет ли этим заниматься среднестатистический сисадмин/пользователь? Логически обе стороны по-своему правы. Я, например, за все время работы с Open Source ни разу не занимался анализом кода на предмет безопасности, в этом просто не было необходимости. Зато примеры собственноручно написанных патчей, упрощающих локализацию, добавляющих некоторые дополнительные функции или устраняющих некоторые ошибки, уже не раз приводили авторы на страницах журнала. На форумах любого Open Source-проекта можно найти сотни страниц кода, представленных сторонними разработчиками. Поэтому, если я не смотрю чужой код, это ведь не значит, что этого не делает кто-то другой, нельзя же подписаться за все шесть миллиардов жителей планеты. Многие специалисты по безопасности в своих высказываниях утверждают, что наличие исходного кода благотворно влияет на защищенность приложения. Например, Винсент Рэймен (Vincent Rijmen), соавтор криптоалгоритма AES/Rijndael, в своем интервью в LinuxSecurity.com заявил, что «считает открытый код полезным, так как больше людей его могут анализировать, а разработчики писать понятный код и соблюдать стандарты» [12]. Вспомним недавнее сообщение Google о том, что россиянин Сергей Глазунов стал первым, кто нашел уязвимости в браузере Chrome в рамках Google Pwnium. То есть если хорошо попросить или заинтересовать, то искать будут (хакера, впрочем, упрашивать не нужно). Но в нашем случае эти уязвимости были сразу же устранены, и взломщики ими уже не воспользуются, хотя, вероятно, это мероприятие хорошо подпортило Google статистику. В свою очередь, исследователи Google обнаружили и опубликовали уязвимость в библиотеке OpenSSL, показав проблемный участок исходного кода. А вот в этом и проявляется основное преимущество Open Source – при обнаружении проблемы пользователь может исправить ее немедленно, не дожидаясь реакции разработчиков или выхода корректирующего пакета в дистрибутиве. Не это ли называется безопасностью? Утечка кода проприетарного проекта не означает проблемы. Здесь показательна реакция VMware, опубликованная после того, как в Сети появился архив с исходными текстами. «Тот факт, что исходные коды могли попасть в открытый доступ, не обязательно означает, что существует повышенный риск для пользователей VMware» [13]. Да и утечка кода Windows, произошедшая несколько лет назад, не поставила на колени корпорацию (хотя пару эпидемий связывают именно с этим событием). Аналогично ничего не меняет недоступность кода, при необходимости программа дизассемблируется, и алгоритм работы восстанавливается. Здесь достаточно вспомнить историю Skype, протокол которого был вскрыт относительно быстро. Чтобы найти уязвимость, взломщику часто даже не нужно анализировать исходный код, он просто подбирает нужную комбинацию, основываясь на уже имеющейся базе проблем. Поэтому будем справедливы: наличие или отсутствие доступного исходного кода никак не должно вызывать чувство ложной безопасности, ошибки допускают все и уязвимость может быть найдена в любом продукте вне зависимости от лицензии. *** Сегодня ошибки в ПО – далеко не основное средство нападения. Многие крупные взломы последних лет были возможны благодаря другим технологиям, и в том числе человеческому фактору. Поэтому заострять внимание на одной проблеме, выпуская из виду остальные, не стоит. Взламывается все, вне зависимости от того, есть или нет исходный код, поэтому здесь более важно помнить о рисках вообще и уметь контролировать их. А время массовых эпидемий Linux, очевидно, еще не пришло. Не интересна эта ОС пока взломщикам, хотя бы потому, что она не стала массовой и для нее характерна фрагментация (наличие множества дистрибутивов и их версий). Хороший пример Mac OS X. Стоило этой ОС набрать свои 7% (это, наверное, и есть тот порог, после которого пользователям Linux стоит начать волноваться), как сразу же получили ботнет на 700 с лишним тысяч ПК, а сообщения об уязвимостях посыпались как из рога изобилия. В том числе подвела пользователей маков и самоуверенность, ведь благодаря активной рекламе многие считали эту ОС не взламываемой, соответственно не было никакого дополнительного ПО, снижающего риски (вроде антивирусов). Сама Apple, кстати, не очень активно реагировала на угрозу, выпуская патчи с опозданием на месяц.
|
СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
