Устранение уязвимостей в компьютерных системах

Устранение уязвимостей в компьютерных системах: исследователь, владелец,
пользователь
Доклад на VII Международной конференции «Право и Интернет»
http://www.ifap.ru/pi/07/
Гордейчик Сергей Владимирович - эксперт портала Securitylab.ru
Все, что сделано руками людей далеко от совершенства. В результате ошибок
проектирования, реализации и эксплуатации в компьютерных системах возникают
уязвимости, т.е. свойства системы, использование которых злоумышленником может
привести к ущемлению интересов владельца этой системы.
Многие уязвимости обнаруживаются производителем на этапе разработки, тестирования и
сопровождения продуктов, однако часть их обнаруживается независимыми
исследователями. В данной работе предлагается обзор существующих регламентов
взаимодействия производителя или владельца ресурса и исследователя, обнаружившего
проблему. Этот вопрос весьма актуален в настоящее время, учитывая широкую
распространенность ситуаций, когда уязвимость в уникальной реализации продукта
(например, Web-сервере) может привести к причинению ущерба большому количеству
субъектов.
В зависимости от целей, ресурсов, моральных устоев и других факторов, лицо,
обнаружившие уязвимость может выбирать различные стратегии поведения. В данной
работе будет рассматриваться та ситуация, когда исследователь решает связаться с
производителем или владельцем системы с целью устранения уязвимости.
Процесс обнаружения уязвимости, выпуска обновлений и устранения уязвимости
довольно часто приводит к возникновению конфликта интересов трех
взаимодействующих сторон: исследователя, владельца системы и пользователя. В
современном мире ситуация усложняется ещё и тем, что владелец ресурса зачастую не в
состоянии самостоятельно оценить и исправить уязвимость, как, например в случае со
сделанным на заказ Web-приложением.
В конце прошлого века основной поддерживаемой производителями политикой была
политика неразглашения (non-disclosure), или как её часто называли – «безопасность через
замалчивание» (security through obscurity). В противовес сложившийся ситуации широкое
распространение получило движение полного разглашения (full-disclosure), согласно
которому полная информация об уязвимости должна быть опубликована в общем доступе,
что повышает активность производителей в области безопасности и помочь
пользователям систем самостоятельно устранить уязвимость, если необходимое
обновление не доступно. Побочным эффектом full-disclosure является появление баз
данных уязвимостей различных продуктов, которые могут быть использованы с
различными целями, например для недопущения подобных ошибок в дальнейшем.
Довольно скоро стало понятно, что нерегулируемое использование full-disclosure
приводит к причинению серьезного ущерба, поскольку, как правило, злоумышленники
гораздо активнее используют информацию о проблемах безопасности чем
администраторы или пользователи систем.
Примером наиболее удачной попытки регулирования является вторая версия политики
разглашения информации об уязвимостях Rain Forest Puppy (RFPolicy) [1]. Согласно ей
лицо, обнаружившее проблему должно попытаться установить связь посредством
электронной почты с владельцем системы и помочь ему в устранении уязвимости.
Владелец, в свою очередь, должен поддерживать контакты с исследователем и
информировать его о ходе решения проблемы. В случае возникновения конфликта
(например, отсутствии реакции со стороны производителя) за исследователем остается
право опубликовать информацию об уязвимости в общедоступном ресурсе. Для
разрешения конфликтов (отсутствие реакции со стороны владельца и т.д.) отводится
период в пять рабочих дней.
Политика RFPolicy легла в основу многих документов. В качестве наиболее значимых из
них можно привести «Responsible Vulnerability Disclosure Process» [2] и
«Guidelines for Security Vulnerability Reporting and Response» [3].
Оба эти документа описывают схожую с RFPolicy процедуру с взаимодействия
исследователя и владельца системы, и устанавливают промежуток в семь календарных
для синхронизации действий сторон. Кроме того, детальная информация об уязвимости
публикуется через некоторое время (от месяца до трех) после выпуска обновления.
Похожего подхода придерживаются авторы документа «Vulnerability Disclosure
Framework»[4] представленного правительству США.
Их основным отличием от RFPolicy кроме менее экстремистского тона, является
появление четвертой стороны – координатора. Цель координатора – разрешение
конфликтов. Ведь в случае, если производитель не отреагировал на сообщение
исследователя или неверно оценил степень риска связанную с уязвимостью, информация
о ней будет опубликована, что может быть использовано злоумышленниками для
нанесения ущерба конечным пользователям. Согласно приведенным рекомендациям, в
случае возникновения конфликта исследователь связывается с третьей доверенной
стороной - координатором, который пытается разрешить конфликт, например,
предпринимает попытки связаться с владельцем ресурсов по альтернативным каналам.
В качестве подобного координатора может выступать CERT/CC [5] или FIRST [6]. Каждая
из этих организаций обладает достаточным авторитетом и придерживается собственной
политики разглашения. Например, CERT публикует информацию об уязвимости, спустя
45 дней после уведомления о ней владельца системы [5].
На настоящий момент различные компании, работающие в области безопасности,
используют одну из этих политик в качестве основы для взаимодействия с
производителями. К примеру, политика компании iDEFENSE основана на RFPolicy [7],
@Stake использует «Responsible Vulnerability Disclosure Process» [8], Appication Security
Inc придерживается политики CERT/CC [9].
Согласно всем перечисленным политикам на производителя или владельца ресурса
ложится ответственность за обеспечения канала взаимодействия с исследователям. Как
минимум, предлагается завести адреса в системе электронной почты, имеющие префиксы
secure@, secalert@ или security-alert@. Кроме того, желательно создать на сервере
страницу security, на которой опубликовать принятую политику обработки уязвимостей и
инцидентов.
Как показывает практика, в мире вполне эффективно работает политика полного или
частичного разглашения, стимулируя производителей к оперативному устранению
уязвимостей и повышая информированность специалистов в области безопасности. В
случае возникновения конфликтов можно воспользоваться отработанным механизмом
взаимодействия с координаторами.
Однако и в России и в мире остается открытым вопрос об публичных Internet-службах.
Например, уязвимость в Web-сервере сотового оператора может причинить ущерб всем
абонентам этой компании, т.е. нескольким миллионам человек. Однако, как правило,
владелец информационного ресурса не является его разработчиком и не обладает
достаточными ресурсами и полномочиями для устранения уязвимостей.
Соответственно открытыми остаются несколько вопросов. Должны ли уязвимости в
Internet-ресурсах быть приравнены к уязвимостям в программном обеспечении? Требуется
ли дополнительные модификации политик разглашения для этих случаев? Должны
координаторы поддерживать устранение этих уязвимостей?
[1] Rain Forest Puppy, “Full Disclosure Policy (RFPolicy) v2.0”.
http://www.wiretrip.net/rfp/policy.html
[2] Steven M. Christey and Chris Wysopal.
“Responsible Vulnerability Disclosure Process (Internet-Draft RFC).”
http://www.vulnwatch.org/papers/draft-christey-wysopal-vuln-disclosure-00.txt.
[3] Organization for Internet Safety. “Guidelines for Security Vulnerability Reporting and
Response, Version 2.0.” http: / /www.oisafety.com/guidelines /secresp.html
[4] NIAC, “Vulnerability Disclosure Framework”,
ttp://www.dhs.gov/interweb/assetlibrary/vdwgreport.pdf
[5] CERT/CC Vulnerability Disclosure Policy, http://www.cert.org/kb/vul_disclosure.html
[6] FIRST, http://www.first.org/
[7] iDEFENSE Vulnerability Disclosure,
http://www.idefense.com/legal_disclosure.jsp?flashstatus=false
[8] @stake Security Vulnerability Reporting Policy, http://www.atstake.com/research/policy/
[9] Application Security Inc. Vulnerability Disclosure Policy,
http://www.appsecinc.com/aboutus/vulndisclosepolicy/