Владимир, а возможность (хотя бы потенциальная) для пользователя полностью контролировать ОС и программы, в том числе узнавать как она устроена с подробностями — это входит в понятие безопасности или нет? В том числе делать это легально. У меня такое впечатление, что здесь у нас расхождение по этому пункту. Для меня и видимо для AlexRK — это может быть даже самый главный пункт с которого начинается реальная безопасность. Неважно, что на практике воспользоваться им может не хватить знаний или времени, важно способствует ОС этому или сопротивляется юридически и программно.
Просто потому что пользователь оказывается в неравном положении с атакующим. Атакующий, де-факто, не обращает внимание на лицензии и может дизассемблировать и реверсить Windows как ему угодно (или вообще связан с разработчиками), использовать результаты реверса как угодно.
Пользователь всегда будет находиться в неравном положении с атакующими, поскольку не обладает навыками, необходимыми для сколь-нибудь адекватной оценки защищённости исходного кода. Даже, если этот пользователь является разработчиком -- навыки, необходимые для разработки кода ортогональны навыкам, требующимся при ревью кода на предмет возможных уязвимостей. Сам факт открытости кода к просмотру и даже модификациям никак не способствует его защищённости. Если речь просто о том, что подобное стремление разработчиков ОС и приложений греет души рядовымм пользователям, то ок, это вполне понятно и объяснимо. Но к безопасности оно никакого отношения не имеет.
Я просто приведу здесь несколько фактов, а как они отвечают на заданный вопрос -- решайте сами.
1.
Несколько лет назад, мы с коллегами принимали участие в анализе защищённости коммерческого парольного менеджера. Я и ещё один исследователь работали над кодом серверной части, а другая команда из трёх реверсеров занималась десктоповым и мобильными клиентами, а также плагинами для браузеров. Я был самый неопытный в команде -- на тот момент занимался анализом защищённости приложений около 4 лет. Самым опытным был Дмитрий Скляров (тот самый), он возглавлял команду реверсеров. Мы с коллегой закончили работать со своей частью примерно через три недели. Чуть больше ушло у второй команды на всё остальное. Уязвимостей всего было примерно с десяток, пара критичных. Очень достойный показатель среди проектов с аналогичной сложностью и объёмами кода.
2.
Как-то, готовясь к очередному докладу, я игрался с Nginx прямо на этот сервере (тогда он ещё использовался в качестве фронтенда на RSDN). Внезапно оказалось, что Nginx не учитывает в location-директивах возможность альтернативного указания имени каталога в пути. Используя всевозможные формы ссылок на каталог, допустимые в NTFS, можно было спокойно обходить deny-директивы и забирать файлы из каталогов, доступ к которым был запрещён. Достаточно серьёзная хрень, не прошумевшая только потому, что доля Nginx на NTFS исчезающе мала. Чтобы устранить эту уязвимость правильно, нужно было реализовывать канонизацию путей, править работу с неканонизированными путями (а для этого надо было сначала найти все такие места) и т.п. Это было скучно и долго, поэтому я решил ограничиться воркараундом и просто проверять, что в имени каталога нет всякой левой хрени (и запрещать доступ, если есть). Пропатчил, собрал. Не работает. Начал разбираться. Не там вставил проверку. Поменял, собрал. Вообще всё не работает. Откатил, начал разбираться. Через какое-то время я понял, что только на то, чтобы только найти правильное место для реализации проверки, у меня уже ушло просто дофига времени. А надо ещё и впилить её правильно, чтобы ничего не порушить. В конечном итоге, я просто отправил инфу об уязвимости авторам и обошёлся воркараундом уровня конфига. http://mailman.nginx.org/pipermail/nginx-announce/2012/000086.html С тех пор, править уязвимости в чужих проектах я даже не пытаюсь.
3.
Не так давно, один исследователь обнаружил в x.Org уязвимость 20-летней давности. Примечателен здесь не только её возраст, но и способ, с помощью которого она была обнаружена в числе других ~120 уязвимостей. Он просто прогнал код этого проекта CppCheck'ом и разобрал результаты. Понимаете? За 20 лет никто из тех тысяч пар глаз не удосужился взять бесплатный анализатор и прогнать на нём код одного из ключевых проектов opensource-собщества.
4.
Грязную корову уже затронули в той теме, поэтому тезисно: 11 лет назад Торвальдс не смог исправить уязвимость, связанную с race condition и забил на её исправление, сочтя трудноэксплуатируемой. Через пару лет, благодаря изменениям "вокруг неё" , она превратилась в легко-эксплуатируемую и в таком виде просуществовала ещё 9 лет, после чего-таки была обнаружена при расследовании реальной атаки на реальный ресурс и получила название Dirty COW. Уязвимость позволяла поднять себе привилегии в системе, т.е., фактически, обходить все возможные на данный момент механизмы защиты Linux. И (если вы не прошли по первой ссылке) под Торвальдсом здесь подразумевается именно Линус, а не какой-то разработчик со стороны, внезапно получивший доступ к исходному коду ядра, чтобы найти и исправить в нём баги.
5.
Есть такая криптолиба -- Inferno. На мой скромный взгляд, самая крутая либа высокоуровневой криптографии в .NET (реально, рекомендую). У неё 265 звёзд и 17 форков на Github, около 4.5K закачек на Nuget и без малого тысяча s/пар глаз/пользователей/. Довольно неплохо для столь молодого проекта, не продвигаемого гигантами. Так вот Стэн (автор этого проекта), не дождавшись помощи со стороны, был вынужден обратиться в коммерческую компанию для проведения анализа защищённости кода библиотеки. Два тамошних тестера, за пару дней, метнулись кабанчиками по коду и нашли несколько незначительных недостатков, которые вскоре были устранены, а отчёт выложен в публичный доступ.
6.
VeraCrypt (в девичестве TrueCrypt) на порядок более популярный проект. Если не больше. Вопрос уязвимостей в нём интересовал многих, но так случилось, что это множество хотящих никак не могло пересечься со множеством умеющих. Пока наконец не догадались прибегнуть к краудфандингу и собрали требуемые 70 килобаксов на проведение анализа. Аудит состоял из двух частей, включавших поиск недостатков уровня кода и уровня реализации криптографии. Для проведения аудита была привлечена стороння организация. Первая часть была выполнена за 5 недель двумя экспертами в области AppSec, вторая -- за 4 недели, также двумя экспертами в области криптографии. Аудит позволил выявить ряд уязвимостей, существовавших в проекте достаточно долгое время.
В случае 5 и 6 полноту проведённых исследований и корректность отчётов никто толком не проверял. Отчёты не содержат информации о том, почему исследователи сочли защищённой ту или иную часть этих проектов, которая бы покрывала весь код целиком (информация, без которой невозможно ни подтвердить, ни опровергнуть полноту проведённых исследований).
---
А теперь, ответьте на два вопроса:
1. Вы получили код всех используемых вами приложений, прошивок устройств (включая бейсбенды -- ну допустим), операционных систем и т.п. Ваши дальнейшие действия?
2. Что выделяет вас среди всей прочей массы пользователей всего этого хозяйства?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>VeraCrypt (в девичестве TrueCrypt) на порядок более популярный проект. Если не больше. Вопрос уязвимостей в нём интересовал многих, но так случилось, что это множество хотящих никак не могло пересечься со множеством умеющих. Пока наконец не догадались прибегнуть к краудфандингу и собрали требуемые 70 килобаксов на проведение анализа. Аудит состоял из двух частей, включавших поиск недостатков уровня кода и уровня реализации криптографии. Для проведения аудита была привлечена стороння организация. Первая часть была выполнена за 5 недель двумя экспертами в области AppSec, вторая -- за 4 недели, также двумя экспертами в области криптографии. Аудит позволил выявить ряд уязвимостей, существовавших в проекте достаточно долгое время.
После чего разработчики обиделись, что деньги дали не им, и послали всех на юх. Но это уже другая история.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я просто приведу здесь несколько фактов, а как они отвечают на заданный вопрос -- решайте сами.
Обстоятельно ответить надо собраться с мыслями, тема не простая, но пока вот что скажу.
KV> 1.
Нормальная работа. Проверили — нашли какие-то баги.
KV>2.
KV> Через какое-то время я понял, что только на то, чтобы только найти правильное место для реализации проверки, у меня уже ушло просто дофига времени. А надо ещё и впилить её правильно, чтобы ничего не порушить. В конечном итоге, я просто отправил инфу об уязвимости авторам и обошёлся воркараундом уровня конфига. http://mailman.nginx.org/pipermail/nginx-announce/2012/000086.html С тех пор, править уязвимости в чужих проектах я даже не пытаюсь.
Да, сейчас софт вынужден быть очень большим и сложным. И здесь нет разницы открытый он или нет.
KV>3.
KV>Не так давно, один исследователь обнаружил в x.Org уязвимость 20-летней давности. Примечателен здесь не только её возраст, но и способ, с помощью которого она была обнаружена в числе других ~120 уязвимостей. Он просто прогнал код этого проекта CppCheck'ом и разобрал результаты. Понимаете? За 20 лет никто из тех тысяч пар глаз не удосужился взять бесплатный анализатор и прогнать на нём код одного из ключевых проектов opensource-собщества.
CppCheck появился менее 10 лет назад. Вообще, хорошие и доступные статические анализаторы появились не так и давно. Разбираться с результатами прогона тоже не просто дело, особенно для старого кода, в котором типично наличие разных хаков, то есть, это не прямо вот так нажали кнопку и получили список.
Хотя, проверяться на таких анализаторах, это наверное сейчас должно быть необходимым требованием для любых проектов, особенно сложных, в которых ошибки потенциально могут привести к проблемам в безопасности.
KV>4.
KV>Грязную корову уже затронули в той теме,
Да, Линус лоханулся в этой истории. Но что тут такого особенного?
KV>5.
KV>Есть такая криптолиба -- Inferno. На мой скромный взгляд, самая крутая либа высокоуровневой криптографии в .NET (реально, рекомендую). У неё 265 звёзд и 17 форков на Github, около 4.5K закачек на Nuget и без малого тысяча s/пар глаз/пользователей/. Довольно неплохо для столь молодого проекта, не продвигаемого гигантами. Так вот Стэн (автор этого проекта), не дождавшись помощи со стороны, был вынужден обратиться в коммерческую компанию для проведения анализа защищённости кода библиотеки. Два тамошних тестера, за пару дней, метнулись кабанчиками по коду и нашли несколько незначительных недостатков, которые вскоре были устранены, а отчёт выложен в публичный доступ.
Видимо не нужна была, поэтому даже ничего не слышал о ней. За рекомендацию спасибо.
В чем мораль истории? Что никто не проверил, ну так се ля ви. Видимо будущее в краудфантинге проверки важных проектов.
KV>6.
KV>VeraCrypt (в девичестве TrueCrypt) на порядок более популярный проект. Если не больше. Вопрос уязвимостей в нём интересовал многих, но так случилось, что это множество хотящих никак не могло пересечься со множеством умеющих. Пока наконец не догадались прибегнуть к краудфандингу и собрали требуемые 70 килобаксов на проведение анализа. Аудит состоял из двух частей, включавших поиск недостатков уровня кода и уровня реализации криптографии. Для проведения аудита была привлечена стороння организация. Первая часть была выполнена за 5 недель двумя экспертами в области AppSec, вторая -- за 4 недели, также двумя экспертами в области криптографии. Аудит позволил выявить ряд уязвимостей, существовавших в проекте достаточно долгое время.
А вот с TrueCrypt получилось по принципу "стакан наполовину пуст или наполовину полон". Я думаю, что "наполовину полон". Критичных уязвимостей не нашли. Критичные — это такие, которые позволили бы дешифровать скопированный контейнер или извлечь ключ, анализируя диск с системой. Таких нет, а например, баги в драйверах, которые позволяют через него сделать эскалацию привилегий во время работы машины — это неприятно, конечно, но может быть критичным в основном только для использования на сервере удаленным пользователем. Что, насколько я понимаю, довольно нетипичный случай использования TC.
KV>В случае 5 и 6 полноту проведённых исследований и корректность отчётов никто толком не проверял. Отчёты не содержат информации о том, почему исследователи сочли защищённой ту или иную часть этих проектов, которая бы покрывала весь код целиком (информация, без которой невозможно ни подтвердить, ни опровергнуть полноту проведённых исследований).
Хм, по-моему, сочли потому что не нашли ошибок. Что тут писать?
KV>---
KV>А теперь, ответьте на два вопроса:
KV>1. Вы получили код всех используемых вами приложений, прошивок устройств (включая бейсбенды -- ну допустим), операционных систем и т.п. Ваши дальнейшие действия?
Даже простая перекомпиляция другим компилятором или даже тем же другой версии или с немного другими ключами оптимизации уже потенциально отсекает значительную часть атак из-за изменения бинарника, например срыв стека. Конечно, это не защита от них, но снижение вероятности.
KV>2. Что выделяет вас среди всей прочей массы пользователей всего этого хозяйства?
У меня впечатление немного разных подходов, возможно, что и к понятию безопасности. Для меня возможность анализировать и модифицировать код системы, обеспечивающей безопасность — это необходимое условие безопасности. Естественно, оно не является достаточным, что вы и проиллюстрировали примерами с X.org и грязной коровой (а можно еще и такой эпикфейл как HeartBleed вспомнить и кучу других), но это условие с которого начинается (отнюдь не заканчивается!!!) доверие. Шутка Sinclair про того кто кому готов отдаться — это не совсем шутка на самом деле. Не случайно же есть места, куда в принципе не поставят Win10 (Win 2016 Server), но поставят AstraLinux и подобные.
Здравствуйте, Kesular, Вы писали:
K>После чего разработчики обиделись, что деньги дали не им, и послали всех на юх. Но это уже другая история.
Это одна из версий происшедшего. Классическое "после — не значит вследствие". Доподлинно неизвестна причина, почему они (хотя похоже, что один он) прекратили разработку, не менее вероятно и предположение о давлении.
Здравствуйте, Michael7, Вы писали:
M>Доподлинно неизвестна причина, почему они (хотя похоже, что один он) прекратили разработку, не менее вероятно и предположение о давлении.
Нет никаких данных о таком давлении, а "используйте Bitlocker" — очевидный злой сарказм.
Так что не надо наводить тень на ясный день.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Не так давно, один исследователь обнаружил в x.Org уязвимость 20-летней давности. Примечателен здесь не только её возраст, но и способ, с помощью которого она была обнаружена в числе других ~120 уязвимостей. Он просто прогнал код этого проекта CppCheck'ом и разобрал результаты. Понимаете? За 20 лет никто из тех тысяч пар глаз не удосужился взять бесплатный анализатор и прогнать на нём код одного из ключевых проектов opensource-собщества.
Не совсем по теме, но. Ты можешь исходя из своего опыта какой-либо статический C++ анализатор посоветовать (я несколько раз смотрел на то, что есть. CppCheck совсем никакенный, скорее вредный чем полезный из за огромного количества false positive)? Их хотелок – кроссплатформенный. Платный вполне нормально, не мне же платить, но чтобы была какая-то внятная политика начисления стоимости, а не "мы посмотрим на вашу компанию и скажем сколько оно вам будет стоить". У нас тут есть лицензия на Klocwork, пока сложно сказать насколько штука хороша, если есть какой-то опыт с ней было бы интересно услышать мнение.
Здравствуйте, Kesular, Вы писали:
K>Здравствуйте, Michael7, Вы писали:
M>>Доподлинно неизвестна причина, почему они (хотя похоже, что один он) прекратили разработку, не менее вероятно и предположение о давлении.
K>Нет никаких данных о таком давлении,
Ну-ну, историю с lavabit напомнить? Кроме того, почему-то разработчики TC старались остаться анонимными. Насколько это им удалось и разумно ли это было — другой вопрос, но факт, что мотивы для этого имелись.
K> а "используйте Bitlocker" — очевидный злой сарказм.
Что злой сарказм — это очевидно, но по поводу чего? В "свидетельство канарейки" он еще лучше вписывается.
K>Так что не надо наводить тень на ясный день.
Вот как можно думать, что тут "ясный день", хотя он не ясный. Если мотивы обиды на деньги для проверки, то зачем надо было выпускать версию TC, которая только дешифровывала, зачем надо было молчать о причинах и устраивать клоунаду, зачем специально удалять старые версии с arсhive.org? В конце-концов, кто мешал прямо поставить вопрос сбора денег, что следующая версия выйдет только после сбора достаточного количества вечнозеленых ценностей. С коммерческой точки зрения после аудита их проект становился более привлекательным.
Здравствуйте, Michael7, Вы писали:
M>Кроме того, почему-то разработчики TC старались остаться анонимными.
Что свидетельствует против теории о давлении, на самом деле.
M>то зачем надо было выпускать версию TC, которая только дешифровывала, зачем надо было молчать о причинах и устраивать клоунаду, зачем специально удалять старые версии с arсhive.org?
Чтобы показать фак на прощание.
А зачем надо было бы выпускать такую версию, если бы на них надавили?
M>В конце-концов, кто мешал прямо поставить вопрос сбора денег
Донат у них был всегда, только проку от него было мало.
M>что следующая версия выйдет только после сбора достаточного количества вечнозеленых ценностей.
Здравствуйте, kaa.python, Вы писали:
KP>Не совсем по теме, но. Ты можешь исходя из своего опыта какой-либо статический C++ анализатор посоветовать (я несколько раз смотрел на то, что есть. CppCheck совсем никакенный, скорее вредный чем полезный из за огромного количества false positive)? Их хотелок – кроссплатформенный. Платный вполне нормально, не мне же платить, но чтобы была какая-то внятная политика начисления стоимости, а не "мы посмотрим на вашу компанию и скажем сколько оно вам будет стоить". У нас тут есть лицензия на Klocwork, пока сложно сказать насколько штука хороша, если есть какой-то опыт с ней было бы интересно услышать мнение.
Я сам от плюсов несколько далёк, но знающие люди тут подсказывают, что ничего лучше Klocwork и Coverity сейчас на рынке нет. Причём именно в связке, т.к. они во многих кейсах дополняют друг-друга.
Ок, раз больше версий ни у кого нет, поясню мораль сих басен. Анализ защищённости -- это достаточно сложный и кропотливый процесс, требующий навыков, которые отсутствуют у большинства разработчиков. Исправление уязвимостей -- не менее сложный и кропотливый процесс, требующий навыков, которые отсутствуют у большинства экспертов по анализу защищённости. Вероятность же того, что среднестатистическим открытым проектом добровольно и бесплатно займётся какая-либо security-контора, практически нулевая. Если же не добровольно или не бесплатно, то здесь опенсорс уже ничем не отличается от закрытых проектов. Да и отчёты, получаемые из подобных security-контор вызывают массу вопросов и определённо не являются достаточным поводом, чтобы расслабиться после устранения всех перечисленных в них уязвимостей. Что же касается исправления уязвимостей, то оно зачастую влечёт за собой существенные изменения в коде, с которыми не всегда справляются даже квалифицированные разработчики.
Кроме того, безопасность -- это процесс. И все вот эти разово-точечные потуги в рамках активно разрабатываемого проекта выглядят просто смешно. Факт открытости или закрытости кода никак не влияет на становление в проекте процессов SSDL, контроли которых выполняются на постоянной основе. Да и никаких краудфандингов не напасёшься, чтобы вывести это на постоянную основу. Безопасность -- это ещё и дорогой процесс
M>Для меня возможность анализировать и модифицировать код системы, обеспечивающей безопасность — это необходимое условие безопасности.
Возможность анализировать и модифицировать -- кем? Пользователями системы? Так у них её нет прежде всего в силу отсутствия умения, а не возможности. Её разработчиками? То же самое (ещё и с авторитетными косяками, как в случае с Линусом). Приглашёнными security-экспертами? Так закрытые проекты точно также проходят аудиты, в т.ч. в сторонних организациях За счёт чего неверифицируемый отчёт от аудиторов VeraCrypt "мы-не-шмогли-найти-серьёзные-уязвимости", оплаченный сообществом, заслуживает больше доверия, чем точно такой же отчёт по какому-нибудь ProprietaryCrypt, оплаченный разрабатывающей его компанией?
M>Не случайно же есть места, куда в принципе не поставят Win10 (Win 2016 Server), но поставят AstraLinux и подобные.
AstraLinux -- плохой пример вашему же тезису. Хотя бы потому, что код всего, что было дополнительно разработано в рамках этого проекта, лицензия запрещает даже декомпилировать (за исключением случаев, предусмотренных ГК РФ), не говоря уже об открытости кода по этим доработкам. Доступ к полному исходному коду получали только ФСТЭК и ФСБ в рамках сертификации системы. Вы готовы положиться на мнение этих служб?
Здравствуйте, Michael7, Вы писали:
M>Хм, по-моему, сочли потому что не нашли ошибок. Что тут писать?
Нормальный отчёт предоставляет возможность верифицировать сделанные в нём выводы. Применительно к нашей ситуации это значит, что аудит должен подразумевать обоснование защищённости всех его участков, в которых не были найдены уязвимости, но в которых они могли бы быть. Ну то есть "этот фрагмент кода не уязвим к атакам инъекций, потому что в связи с <перечень контрмер в коде> не существует такого допустимого значения аргументов вызовов a, b и c (приводящих к интерпретации текста на формальном языке) при котором возможно изменение структуры синтаксического дерева этого текста" или "этот фрагмент кода не может являться условиями гонки за ресурсы, поскольку в позициях описывающей его сети Петри не может находиться более одной метки в каждый момент времени за счет <перечень контрмер в коде>".
Подчеркну ещё раз -- анализ защищённости кода это не "я не нашёл тут уязвимостей, хотя искал как умел", а выделение в коде значимых с точки зрения защищённости фрагментов и доказательство (в математическом смысле) их свойств. Чем тут может помочь открытость кода тем, кто не умеет этого делать -- для меня загадка
