Видео доклада: http://www.youtube.com/watch?v=9ZraBMDqX6Y В 2014 году было обнаружено несколько масштабных критических уязвимостей в открытых проектах, затрагивающие миллионы компьютеров по всему миру. Например знаменитый Heartbleed, FREAK, POODLE и BEAST в библиотеке OpenSSL, обычный SQL Injection в популярной системе управления контентом Drupal. Возможно ли с этим бороться, есть ли плюсы в открытой модели разработки с точки зрения безопасности?

1. Информационная безопасность в
открытых проектах
Алексей Брагин, Pierre Schweitzer

2. О докладчике
• Алексей Брагин, aleksey@reactos.org
• Активный участник СПО с 2000 г.
• 10+ лет разработки и руководства ReactOS
• Разносторонние интересы
• Программирование
• Бизнес
• Финансы
• Управление
• Наука
• Соавтор доклада – Pierre Schweitzer
• Сфера интересов – информационная безопасность, инфраструктура

3. О докладчике
• Координатор проекта ReactOS
• Преподаватель в МГТУ им. Н.Э.Баумана
• Научный руководитель НИРС
• Участник рабочей группы по ОС МинСвязи
• Член комиссии по модернизации Научного
совета РАН по проблемам европейской
интеграции и модернизации

4. ИБ в открытых проектах
1. Безопасность (надёжность) исходного кода
2. Безопасность инфраструктуры
3. Безопасность самого проекта

5. 1. Безопасность кода в открытых проектах
• Критические уязвимости в 2014 году – в открытых проектах
• Heartbleed (OpenSSL, CVE-2014-016)
• Shellshock (Bash, CVE-2014-6271)

6. OpenSSL – открытая библиотека SSL/TLS
• OpenSSL – очень широко используемый проект
• Нет коммерческой поддержки
• Отсутствует аудит кода
• Все только используют, но не помогают
• Только 2 человека работает над ним полное рабочее время

7. Bash – командный процессор, оболочка
• Bash – очень широко используемый проект
• Нет коммерческой поддержки
• Отсутствует аудит кода
• Все только используют, но не помогают
• 1 мейнтейнер

8. Как с этим бороться?
• Аудит исходного кода, в т.ч. независимый
• Рецензирование (review) всех вносимых изменений
• Возможно позволило бы обнаружить heartbleed/shellshock
• Негативное тестирование
• Обычно – тестирование на обнаружение регрессий
• Нужно – тестирование с совершенно некорректными значениями параметров.
Позволило бы обнаружить heartbleed/shellshock
• Статический анализ кода
• Не помогло в случае Heartbleed/shellshock
• Fuzzing – (полу)автоматическое тестирование, подающее на вход
различные неправильные, неожидаемые и случайные значения
• Позволило бы обнаружить heartbleed/shellshock

9. Apple “goto fail” – что могло помочь?
• Правильный стиль
написания кода
• Правильные методы
разработки
• copy/paste вносит ошибки
• Опции компилятора
• Игнорирование
предупреждений
компилятора – верный путь к
ошибкам
hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
goto fail;
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail; /* err здесь равно 0, т.е. «успех» */
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
err = sslRawVerify(...);
fail: /* Epic */

10. 1. Безопасность кода в открытых проектах
• Уязвимость в открытом проекта – не значит, что проект
провальный.
• Люди ошибаются
• Разработчики не могут просчитать все сценарии работы кода
• Common Weakness Enumeration – CWE MITRE
• Общие шаблоны ошибок
• Пример того, как была предотвращена уязвимость в ReactOS
• https://www.reactos.org/node/932

11. 2. Безопасность инфраструктуры
• Проект свободный, исходные коды открыты
• Но не стоит игнорировать уязвимости хостинга, на котором он
работает
• Учётные записи пользователей
• Те же принципы системного администрирования как и для любой
серьёзной инфраструктуры
• Политики безопасности
• Системы Intrusion Detection System / Prevention System
• Обновление ОС/ПО
• Firewall
• Аудит безопасности

12. Инфраструктура СПО
• Утечка данных – всегда имеет огромные последствия
• Не важно – из компании или из открытого проекта
• Всего-лишь один из векторов атаки
• А что, если злоумышленники похитят данные для внесения изменений в
код (коммитов) от имени разработчика этого проекта?
• Не волнуйтесь, вас тоже рано или поздно взломают
• ReactOS – не исключение, ситуация подробно описана
• https://www.reactos.org/node/928

13. 3. Безопасность самого проекта
• Надёжность хранения данных – это тоже безопасность!
• Резервное копирование – залог успеха
• В этом ошибаются очень и очень многие
• Управление правами доступа в команде
• Где размещать код?
• Что делать, если хостинг закрывается
(Например, Google Code)

14. Сила открытого кода
• Открытый код должен больше дублироваться
• во многих местах по всему миру
• децентрализация
• В реальности всё не так…
• Например, TrueCrypt (из-за плохой лицензии)

15. • Вопросы и предложения