При достаточном количестве денег все ошибки выплывают на поверхность

Original author: Jeff Atwood
  • Translation
Эрик Рэймонд (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
ABBYY
Решения для интеллектуальной обработки информации

Comments 29

    +11
    Люди будут сообщать о проблемах в Open Source даже без вознаграждения хотя бы потому, что они им пользуются. Уменьшение числа уязвимостей в используемых программах — это уже (пусть и не очень большая) выгода.
      +2
      На самом деле, для программиста и спеца по безопасности фикс критичной проблемы Open Sourc'a это один из лучших способов сделать себе имя и карьеру (правда в РФ это плохо работает, зато замечательно работает на Западе). Думаю тот кто нашел багу в OpenSSL на следующий день после фикса без всяких проблем мог увеличить свои расценки/зарплату раза в два.
        0
        А сколько было за два года людей, кто нашёл багу в OpenSSL и написал эксплойт? Мы не знаем и можем лишь надеяться, что написание эксплойтов было менее выгодно специалистам. Об этом хорошо сказано в статье.
          +2
          Я говорил о другом, не каждый эксперт захочет нарушать закон, продавая эксплойт на черном рынке (и, соответственно, рискуя свободой). Всегда есть светлая сторона силы, бесплатно пофиксить эксплойт в открытом коде, а потом получать не такую большую, но стабильную прибыль как эксперт по безопасности ПО мирового уровня (публикуя книги, давая мастер классы, получая заказы на тестирование безопасности от самых крупных фирм).
      • UFO just landed and posted this here
          +2
          На самом деле, почему так развит OpenSource на Западе и так плохо развит в РФ? Потому что вложиться во всем известный OpenSource это лучший способ увеличить свою стоимость как специалиста. На Западе эксперт, нашедший ошибку в популярном OpenSource, сразу переходит в другую категорию «стоимости», а это зачастую даже большие деньги чем тупо продать эксплойт на черном рынке: что лучше продать эксплойт за 20-50 тыс.$ или получить возможность просить годовую зар.плату на те же 20-50 тыс.$ больше среднерыночной (для США это всего 20-50% надбавки) в течении всей своей жизни?
            +1
            Вы немного о другом говорите: сравниваете Россию и Запад. Не влезая в тонкости разницы между OpenSource «у нас» и «у них» (была тут недавно весьма острая дискуссия), давайте вернёмся к исходному тезису: автор переводной статьи говорит, что в целом в мире (давайте не будем делить по странам) есть такая проблема.
            Поэтому даже если вы и хотите показать, что в России всё ещё хуже, чем в целом по миру — то решать проблему подымая Россию до среднегомирового уровня — совсем не вариант, общая проблема никуда от этого не денется.
              –1
              В России вообще крупных OpenSource проектов крайне мало (из условно-российских на ум приходит разве IntelliJ IDEA Community Edition). Тут проблема не в том что плохо с аудитом безопасности OpenSource, а в том что в РФ вообще с разработкой OpenSource плохо, тут уж нет OpenSourc'а — нет проблемы.

              автор переводной статьи говорит, что в целом в мире (давайте не будем делить по странам) есть такая проблема

              А я говорю, что автор переводной статьи сгущает краски, искать в OpenSource искать уязвимости может быть даже выгоднее чем в коммерческом софте.
              0
              А что мешает эксперту продать эксплойт, а потом, через несколько месяцев пофиксить багу? То есть и денег заработать, и выйти красавчиком и поднять себе зарплату на будущее. Блэк маркет же анонимен, покупатели претензий предъявлять не будут.
              • UFO just landed and posted this here
                  +2
                  Никто не мешает, но
                  1) если эксплойт начнут активно использовать направо и налево с большой вероятностью его найдут и раньше нескольких месяцев => лавры получит кто-то другой,
                  2) если продав багу на черном рынке эксперт немедленно пофиксит багу под своим настоящим именем, его найдут и прирежут. Достаточно наивно верить, что у криминала способного купить эксплойт за десятки тысяч $ не найдется возможности отомстить тому кто их кинул или мозгов догадаться что такое совпадение, что многолетнею багу неожиданно одновременно нашли сразу двое, не просто так,
                  3) ну и в конце концов, полиция думает примерно так же, поэтому если вдруг публикуется эксплойт, которым пару месяцев активно воровали деньги, первый подозреваемый будет именно эксперт публикующий эксплойт, а найти доказательства продажи на черном рынке у конкретного подозреваемого намного легче, чем вообще не зная ничего,
                    0
                    В phpbb была дыра, позволявшая получить доступ к шелу. Она существовала более года и ее тихо использовали заинтересованные люди, пока кто-то ее не опубликовал. После публикации начался бардак и даже появились эксплуатирующие эту уязвимость черви.

                    Разумеется, никого не нашли, даже авторов червей. Подозреваю, что и heartbleed заинтересованные люди использовали годами.
                +2
                Кроме экспертов, которые занимаются исключительно поиском уязвимостей и обычными программистами, которые не видят уязвимостей, есть много разработчиков, которые могут увидеть уязвимости в программе в процессе ее разработки (которая в свою очередь может быть спонсирована коммерческой компанией, которая эту программу использует) и некоторое количество продвинутых пользователей, которым по какой-то причине нужно залазить внутрь и читать код программы (к примеру для отладки багов). Эти люди как репортили уязвимости до появления программ вознаграждения, так и будут репортить. Поэтому Open Source проекты без сообщений о проблемах с безопасностью не останутся.
                +3
                Люди обычно просто пользуются, а не код читают. И багрепорты, если и пишут, то про «открываю мп3 в этом вашем либреофисе, а он вместо текста песни показывает какую-то фигню.» :)
                Так что уязвимости от пользователей будут разве что случайно («падает, если я делаю так»).
                • UFO just landed and posted this here
                  +7
                  Это смотря какая проблема и как решают. Вот я как-то столкнулся с проблемой в tar. Написал. Получил через пару дней хотфикс. Обнаружил, что он не решает проблему. Написал еще раз. Ответа не дождался. Забил. Похожий опыт у меня был с wine (там ветка заглохла через десяток комментариев) и qemu (а эти ребята вообще проигнорировали, но их можно понять — у них с 2009 года висят баги в состоянии «new»).

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

                  А вот если бы была награда, например, в виде сувениров — я бы, вполне вероятно, приложил больше усилий.
                  Идея денежных наград мне кажется сомнительной, потому как профессиональные программисты, обычно, не испытывают финансовых затруднений.
                    +2
                    Ничего не знаю как работают в tar или wine, но как послан bug report имеет огромное значение. Вот только сегодня с коллегами обсуждали bugs.mysql.com/bug.php?id=72322 Дело в том, что underlying issue of this bug — это давно известная проблема и я, честно говоря, ожидала фикса в лучшем случае только в следующей major версии. Однако после того, как был сделан report с таким хорошим test case, позволившим взять и повторить баг, это пофиксили не только в future version, но и во всех поддерживаемых. А до этого годами люди слали что-то типа «Information Schema работает медленно».
                      0
                      > А вот если бы была награда, например, в виде сувениров

                      Автор про это пишет тоже. Люди хотят а) бесплатный софт, б) открытые исходники в) плюшки за поиск багов. Впору их спросить: «У вас совесть есть?»
                      • UFO just landed and posted this here
                          0
                          Взывать к совести бесполезно в рамках поставленной задачи — это не даст ничего, кроме временного ощущения собственного морального превосходства и последующей депрессии от осознания несовершенства мира. Автор хочет больше помощи в нахождении багов? Значит, ему нужно что-то сделать для привлечения людей. Есть бесплатные варианты:

                          • страничка с благодарностями поименно (типа top contributors)
                          • картинка на сайте
                          • именная картинка-для-подписи на сторонних сайтах
                          • место для ссылок на проекты людей, которые помогли
                          • почтовый ящик (пусть и просто редирект) на сайте проекта
                          • хотя бы простое «спасибо» в частном порядке


                          Некоторые из этих пунктов попадаются на багтрекерах время от времени.
                            0
                            Давайте ссылку на ваш профиль в гитхабе и готовьте сувениры на поиск багов :)
                      0
                      Все проблемы актуальны не только для открытого софта, в закрытом всё тоже самое, только чтение исходников сложнее, надо формулировать так чтобы не создавалось впечатление что это проблема именно открытого софта
                        +5
                        Считаю что в закрытом все еще хуже, так как часто авторы закрытого софта считают, что если код закрыт, то он более безопасен и подходят к задаче исправления брешей безопасности этого кода «спустя рукова». Сам с этим сталкивался не раз и не два.
                        +7
                        Я довольно долго имел дело с иходниками openssl, так вот совсем не удивлён что эту ошибку там не нашли, ибо дебри непралазные.
                          –5
                          Бросайте лазанье по OpenSSL — это сильно сказывается на Вашей русской грамматике.
                            +3
                            Согласен. Столько далеко идущих выводов и вся аргументация строится на примере OpenSSL. Но нельзя это поделие рассматривать в качетсве примера, это просто адов ад, а не библиотека.
                              0
                              Так то оно так, но есть много других опенсорсных проектов, где ситуация не лучше.
                                0
                                Собственно причем тут опенсорс. Не видел статистики, где бы утверждалось, что качество кода в закрытых проектах в среднем лучше. В данном случае у нас хотя бы есть возможность заглянуть внутрь и понять, что код говно.
                            0
                            Нужны краудфандинговые фонды, которые будут выплачивать вознаграждения за поиск проблем в безопасности. Плюс определять приоритетные направления и ставки за выплаты. И крупные корпорации вполне могли бы участвовать в этих фондах.

                            Only users with full accounts can post comments. Log in, please.