[Перевод] При достаточном количестве денег все ошибки выплывают на поверхность
Эрик Рэймонд (Eric Raymond) в своем эссе «Собор и базар» сказал знаменитую фразу: «При достаточном количестве глаз все ошибки выплывают на поверхность».
Имеется в виду, что программное обеспечение с открытым исходным кодом по определению содержит меньше ошибок, чем ПО с закрытым исходным кодом, потому что код доступен для изучения всем и каждому. Рэймонд назвал это наблюдение «законом Линуса».
В некотором смысле, конечно, так и есть. Если исходный код могут увидеть всего 10 штатных программистов вашей компании, вряд ли результаты будут такими же, как если бы этот код лежал на всеобщем обозрении, скажем, на GitHub.
Однако переломным моментом для закона Линуса стало обнаружение уязвимости Heartbleed в OpenSSL — катастрофического эксплойта в результате серьезной ошибки в ПО с открытым исходным кодом. Каковы были масштабы катастрофы? Уязвимыми оказались примерно 18% всех сайтов с включённым HTTPS в мире. В результате злоумышленники могли просматривать весь трафик этих сайтах в незашифрованном виде… в течение двух лет.
Вы считали эти сайты защищёнными? Как же. Эту ошибку не замечали два года.
Два года!
Библиотека OpenSSL, где появилась эта ошибка, — один из наиболее критических элементов интернет-инфраструктуры в мире. На неё полагаются крупные компании для шифрования личных данных своих клиентов для передачи по сети Интернет. OpenSSL использовалась на миллионах серверов и устройств для защиты важной информации, которую надо шифровать и прятать от посторонних глаз, — например паролей, информации о банковских счетах и кредитных картах.
Этот код должен быть одним из самых проверенных в мире. И где были наши глаза?
«На самом деле, исправлять настоящие баги в чем бы то ни было, кроме элементарного ПО с открытыми исходниками, не просто сложно, а мегасложно. Мне, например, редко приходилось это делать, хотя я и опытный разработчик. Что происходит в большинстве случаев? Вы просто сообщаете о проблеме автору кода и ждёте, что он её исправит», — Нил Гантон (Neil Gunton).
«Даже если найдется смелый хакер, который прочитает код, вряд ли он заметит ошибку, которую трудно обнаружить. Почему? Потому что среди хакеров ПО с открытым исходным кодом практически нет экспертов по защите», — Джереми Заводны (Jeremy Zawodny).
«Тот факт, что на программу смотрит много глаз, не сделает её более защищённой, зато заставит многих поверить в то, что она хорошо защищена. В результате мы имеем сообщество разработчиков открытого ПО, которые, кажется, слишком доверчивы, когда речь идет о безопасности», — Джон Виега (John Viega).
Я считаю, что у закона Линуса есть пара недостатков.
1. Глаза пользователя и глаза разработчика — это, как говорится, две большие разницы. То, что вы собрали несколько бинарных пакетов RPM или скомпилировали что-нибудь в Linux или даже нашли ошибки и сообщили о них разработчикам через систему отслеживания багов, еще не означает, что вы как-то помогаете критически просматривать код. Большинство глаз смотрит только на внешнюю сторону кода. И хотя вы как пользователь можете обнаружить проблему с безопасностью, и даже серьезную, самые вредные баги требуют знаний о том, как работает код изнутри.
2. Написать (или вырезать и вставить) свой собственный код проще, чем понять и оценить чужой код на уровне независимого эксперта. С этим связана фундаментальная, неизбежная асимметрия: количество штампуемых в наши дни строк кода — даже если допустить, что лишь малая их часть заслуживает серьезного анализа — в разы превышает количество глаз, которые могут их просмотреть. (Да, это еще один аргумент в пользу того, что надо писать меньше кода)
3. Для просмотра кода не хватает профессиональных глаз. Несомненно, общее количество программистов постепенно растет, но сколько из них имеет достаточную квалификацию и достаточно разбираются в безопасности, чтобы эффективно выполнить верификацию чужого кода? Ничтожно малая часть.
Даже если код открыт на 100%, предназначен для решения критически важных задач и используется крупными компаниям практически во всех внешних веб-серверах для обеспечения безопасности клиентов, дело заканчивается критическими ошибками, которые затрагивают всех. В течение двух лет!
Пора делать выводы. Если мы, как выяснилось, не можем обеспечить достаточное количество глаз для OpenSSL, какие шансы у другого кода? Что же нам делать? Где взять больше глаз?
В краткосрочной перспективе:
• Создавать больше альтернатив OpenSSL, чтобы разнообразить экосистему.
• Совершенствовать поддержку и финансирование OpenSSL.
Обе эти меры эффективны и необходимы. И то, и другое нужно делать для всех критических частей экосистемы с открытым исходным кодом, от которой зависят люди.
Но как решить общую проблему нехватки глаз для открытого исходного кода в долгосрочной перспективе? Это решение вам знакомо, хотя я подозреваю, что Эрик Рэймонд будет от него не в восторге.
Деньги. Много-много денег.
Сегодня все больше компаний обращается к коммерческим программам отлова багов (bug bounty). Эти программы создаются либо самими компаниями, либо сторонними организациями вроде Bugcrowd, Synack, HackerOne и Crowdcurity. Компания платит за каждый обнаруженный баг и чем он больше и страшнее, тем больше сумма выплаты.
Альтернативный способ — принять участие в мероприятии, например Pwn2Own, где каждый год проводится соревнование с наградой в несколько сотен тысяч долларов за эксплойт популярного ПО. Ежегодные мероприятия подобного масштаба всегда широко освещаются в СМИ и вызывают интерес у наиболее крупных игроков рынка.
Это и есть основная идея. Если вы хотите найти ошибки в своем коде, на веб-сайте, в приложении, сделайте это старым добрым способом — заплатите за проверку. Другими словами, купите себе глаза.
Хотя я приветствую любые усилия, направленные на повышение безопасности, и абсолютно согласен с тем, что это битва, которую нужно вести сразу на нескольких фронтах, как коммерческих, так и некоммерческих, мне не дают покоя некоторые моменты, связанные с тем, что платить деньги за поиск ошибок сегодня становится нормой. Какие могут быть последствия?
Деньги заставляют ошибки в защите прятаться глубжеТеперь у эксплойтов есть цена, и чем эксплойт глубже и малоизвестнее, тем больше соблазна никому о нем не говорить до тех пор, пока не сорвешь куш побольше. Поэтому есть смысл ждать чуть ли не год, прежде чем сообщить о проблеме с безопасностью, а тем временем эта проблема никуда не денется — как знать, кто еще ее обнаружит? Если основной вопрос в деньгах, кто платит больше? Хорошие парни или плохие парни? Что лучше — выждать, чтобы потом заработать побольше, или усовершенствовать эксплойт так, чтобы он стал еще опаснее? Надеюсь, ради нашего общего блага, что у хороших парней карманы глубже, иначе всем нам несдобровать.
Мне нравится, что Google уже начал решать эту проблему, поменяв условия Pwnium, своего собственного варианта Pwn2Own для Chrome, таким образом, что a) деньги можно получить в любой момент и б) сумма стала неограниченной. Не знаю, достаточно ли этого, но они, несомненно, движутся в правильном направлении.
Деньги превращают безопасность в корыстную цель Впервые я заметил такую тенденцию, когда пара человек сообщили о незначительных проблемах с безопасностью в Discourse — и, по моим ощущениям, замерли в ожидании награды (насколько это можно было выразить в электронном письме). Это было странно, и я чувствовал себя неловко.Получается, я теперь обязан не просто дать миру абсолютно бесплатное ПО с открытым кодом, но и заплатить тем, кто делится информацией о проблемах с безопасностью, улучшая тем самым его качество? Поверьте, я очень ценю сообщения о проблемах с безопасностью, поэтому я отправил этим людям все, что мог: наклейки, футболки, пространные письма с выражением благодарности, упомянул их в коде и пояснениях к правкам. Но открытый исходник делается не ради денег… так?
Возможно, с закрытыми исходниками картина другая: это коммерческая продукция, здесь не действует принцип «услуга за услугу», и за сервис так или иначе платят, прямо или косвенно.
Нет денег — нет защиты Если все лучшие исследователи в области защиты ПО будут заниматься отловом багов за все большее вознаграждение и все крупные компании перейдут на такую схему работы, как это отразится на индустрии программного обеспечения? Это будет означать, что, если у вас нет большого бюджета, вы не сможете обеспечить нормальную защиту, потому что никто не захочет сообщать вам об ошибках. С какой стати? Ведь им не заплатят. Они будут искать проблемы в других программах.
Вымогательский принцип «заплатите мне, а то я не расскажу вам о вашем ужасном баге» больше не кажется дикостью. Мы уже получаем подобные письма.
Легкие деньги привлекают всех Неприятный побочный эффект идеи платить за баги заключается в том, что она привлекает не только добросовестных программистов, но и вообще всех, кого интересуют легкие деньги.Мы получили слишком много «важнейших» отчетов о проблемах с безопасностью, ценность которых оказалась практически нулевой. Но нам все равно приходится их проверять, потому что это «важнейшие» отчеты, так? К сожалению, многие из них — пустая трата времени, потому что…
• автору отчета гораздо интереснее напугать вас грандиозными последствиями критического нарушения безопасности из-за обнаруженного бага, чем дать ему внятное объяснение, поэтому в конце концов всю работу придется сделать вам самим;
• автор отчета не понимает, что такое эксплойт, но знает, что все похожее на эксплойт имеет определенную ценность, поэтому отправляет отчеты обо всем, что найдет;
• автор отчета не может поделиться информацией с другими исследователями и убедиться, что ему действительно удался эксплойт, потому что находку могут «украсть» и получить за это деньги;
• автору отчета нужно убедить вас в том, что это эксплойт, чтобы заработать, поэтому он будет доказывать вам, что он прав. Долго и упорно.
Эти мотивы кажутся мне совершенно неправильными. Естественно, я знаю, что безопасность крайне важна, но при этом смотрю на такое решение проблемы со все возрастающим ужасом, потому что оно прибавляет мне работы, а отдачи от него практически никакой.
Что можно сделать? К счастью, у нас есть общая цель — сделать программное обеспечение более безопасным.Поэтому мы должны относиться к отлову багов за деньги как к дополнительному оружию или еще одному рубежу «глубокой обороны» — возможно, чуть более подходящему для коммерческих проектов с достаточным бюджетом. Тогда это нормально.Но я хотел бы дать совет тем, кто внедряет коммерческие программы отлова багов:
• Нужно, чтобы сначала кто-то тщательно проверял эти отчеты об ошибках: можно ли им доверять, есть ли в них четко описанные шаги по воспроизведению, реализуемы ли они.
• Нужно создать в своем сообществе дополнительные стимулы для быстрого и эффективного поиска уязвимостей. Исследователи должны работать вместе, ничего не скрывая друг от друга.
• Нужно разработать систему создания репутации, чтобы только лучшие, проверенные участники могли пройти все этапы и подать отчет.
• Нужно убеждать крупных игроков рынка финансировать программы отлова багов для общих проектов с открытым исходным кодом, а не только для их собственных приложений и сайтов с закрытым исходным кодом. Мы в Stack Exchange каждый год оказывали финансовую помощь тем проектам с открытым исходным кодом, которыми пользовались. Безвозмездное финансирование программ отлова багов может в разы увеличить число глаз, проверяющих код.
Я боюсь, что скоро мы будем жить в мире, где при достаточном количестве денег все ошибки выплывают на поверхность. Деньги действительно создают некоторые ложные стимулы в плане безопасности программного обеспечения, и эти стимулы нужно контролировать.
Но я по-прежнему верю, что люди будут сами сообщать о проблемах с безопасностью программного обеспечения с открытым исходным кодом, потому что
• это правильно™
и
• они хотят помочь проектам, которые когда-то помогли им, и тогда
… мы еще немного поживем в нормальном мире — хотелось бы надеяться.
Перевод выполнен ABBYY Language Services
