LXF100-101:Мнение
|
|
|
- Мнение: Джереми Эллисон
Извела меня кручина…
Для моего кода это был не самый удачный месяц. Проекту Samba, за который я отвечаю, пришлось объявить о нескольких уязвимостях. К несчастью, некоторые из них содержатся в коде, который писал я сам. Когда такое случается, я всегда копаюсь в своей душе. Нет ничего хуже, чем узнать, что тысячи людей тратят время на поиски заплаток, а причина — твой проект. В подобных случаях я задумываюсь: не пора ли завязать с программированием и посвятить остаток дней мирной стезе менеджера, исследуя коды других вместо создания собственного?
Проект Samba не юн: первичный код создавался пятнадцать лет назад. Тогда мы и не слыхивали о таких современных проблемах безопасности, как переполнение целого (сумма двух целых чисел может оказаться меньше, чем любое из слагаемых, из-за выхода за разрядную сетку процессора) или кучи (перезапись невыделенной памяти, позволяющая злоумышленнику перехватить управление программой). Мы знали о переполнении буфера (запись в буфер количества данных, превышающего его емкость) и о DDoS-атаках, но 1992 год был проще и дружелюбнее к разработке сетевых программ. Большинство установок Samba проводилось в сетях, изолированных от Интернета, технически грамотными администраторами.
Ошибки в системе безопасности, обнаруживаемые сегодня, намного сложнее и изощренней. И относимся мы к ним намного серьезнее. В те ранние дни мы работали с людьми, знающими, как компилировать исходный код. Ответная реакция на «дыры» наступала через считанные часы. Первая попытка саботировать Samba через эксплойт нулевого дня была направлена в наш список рассылки без всякого предупреждения. Эндрю Триджелл [Andrew Tridgell] (автор первой Samba) пришел в ярость и сработал на рывок, чтобы уже следующее сообщение в списке было заплаткой для этой проблемы. И это ему удалось. Тогда мы редко получали эксплойты нулевого дня, открыто отправленные в списки рассылки. Плохие парни держат их в секрете для своих собственных противозаконных целей, а хорошие парни практикуют наилучший подход, принятый в наши дни – отправка уведомлений непосредственно разработчикам Samba (security@samba.org) и сотрудничество с нами по координации уведомлений о проблеме и поиска путей ее решения.
Ныне ответная реакция значительно медленнее, даже при том, что на нашей внутренней кухне мы обычно находим решение за несколько часов; тормозит нас свой же успех. Чтобы с полной ответственность выпустить заплатку, мы согласуем наши действия с огромным количеством поставщиков, которые продают и перепродают наш код. У большинства из них есть свои графики выхода заплаток и команды по безопасности, которые оценивают предложенные решения и согласовывают, когда именно объявить об уязвимостях по всему миру.
Кто обнаруживает наши ошибки? Сейчас наблюдается соотношение пятьдесят на пятьдесят между внутренним аудитом и специалистами по безопасности из мира Open Source и внешними специалистами пo безопасности, которые зарабатывают на жизнь, получая контракты благодаря своему умению отыскивать уязвимости в открытых проектах. Заметив «дыру» в безопасности, мы сразу же проверяем всю кодовую базу на предмет похожих проблем или аналогичных практик написания кода, способных в будущем стать причиной проблем, и переписываем или удаляем их. Так получается дольше, но зато намного надежнее в конечном итоге. Взглянув на код Samba, вы найдете, что стандартные функции, известные своей ненадежностью, просто не поддадутся компиляции в случае добавления к нашему коду. Набор автоматических макросов предупреждает о любом использовании известных «вредоносных» функций. Мы не можем полагаться на автоматику по части защиты: все пока что существующие уязвимости нашей системы безопасности подразумевают использование некоего допущения в одной части кода, вызывающего появление уязвимости в другой, якобы отдельной части кода, которая на самом деле является взаимозависимой. И злоумышленники, и исследователи уязвимостей в наши дни очень поумнели.
Проще ли обнаруживать и бороться с ошибками в системе безопасности программ с открытым кодом, чем в проприетарных программах? По моему ощущению – да. Возможность изучить намерения автора, посмотрев его код и комментарии, очень помогает увидеть, где идея не соответствует коду. Там-то и скрываются проблемы безопасности. Надежнее ли открытый исходный код, чем проприетарный код? И на это я бы тоже ответил «да». Одно лишь количество выявленных уязвимостей ни о чем не говорит: примерно половина сбоев в системе безопасности обнаруживается в ходе наших внутренних проверок кода, или просто кто-то просматривает код и думает: «ага, вот оно…» Что бы мы ни обнаружили, мы обязаны сообщать об этом нашим контрагентам и оповещать о сбое в системе безопасности. Это штука болезненная, но поскольку все наши процессы открыты, мы не можем позволить себе роскошь тихонечко, молчком, исправить ошибку в надежде, что никто ничего не заметит. А вот проприетарные производители могут себе эту роскошь позволить, и не пользоваться ею было бы безумием, и я уверен, что они и пользуются. Проприетарные производители цепляются за любую возможность, конкурируя с замечательным свободным ПО.
ПроСИм, проСИм
Samba все еще пишется на C. Мы рассматривали возможность перехода на C++, но это не поможет решить наши проблемы с безопасностью. На самом деле, если скрыть взаимозависимости в классах объектов, то отслеживать эти ошибки, возможно, станет еще труднее. Перевод кода на управляемый язык, например, Java или C#.NET, мог бы сократить наши проблемы с безопасностью, но заодно снизил бы производительность – а именно она для многих является решающим фактором в выборе Samba. Не случайно ни один из конкурирующих серверов CIFS не написан в управляемом коде. У нас ушло бы от шести месяцев до года на то, чтобы переписать все и выйти на тот же самый уровень функциональности, вероятно, снизив производительность. Но у нас для этого нет ни времени, ни людей. Если кто-то из вас занимается созданием хорошего свободного сервера CIFS, я бы предложил вам создать его на управляемом языке – в качестве эксперимента. Если он станет работать так хорошо, как я надеюсь, мы выбросим свой код и присоединимся к вам.
Чтобы Samba шла в ногу с современными требованиями, мы постоянно переписываем и переделываем основные части кода. Наш грядущий релиз, Samba 3.2, имеет очень мало общего с оригиналом 1992 года и использует современные технологии управления памятью, дабы избежать переполнения кучи, буфера и утечки памяти, причем большинство этих проблем были обнаружены командой Samba при внутреннем пользовании. Мы сами используем Samba для обслуживания файлов. Зализывая свои раны, мы врачуем и других.
Я по-прежнему чувствую себя скверно из-за допущенных ошибок, но пробую утешиться, предлагая их как учебный пример при приеме на работу в Google. Если кто-то не видит ошибки, это всегда поднимает мне настроение, но в то же время служит большим минусом для претендента. Так или иначе, новые сотрудники должны уметь писать код лучше меня… (!) Код открыт для изучения, так что учтите мои ошибки, чтоб не пришлось согласовывать время объявления о «дырах». Такого познавательного опыта лучше не иметь. LXF
