Сообщение Безопасность открытого кода (опять, да) от 07.03.2017 17:25
Изменено 07.03.2017 17:30 kochetkov.vladimir
Безопасность открытого кода (опять, да)
Отвечая на вопрос
Пользователь всегда будет находиться в неравном положении с атакующими, поскольку не обладает навыками, необходимыми для сколь-нибудь адекватной оценки защищённости исходного кода. Даже, если этот пользователь является разработчиком -- навыки, необходимые для разработки кода ортогональны навыкам, требующимся при ревью кода на предмет возможных уязвимостей. Сам факт открытости кода к просмотру и даже модификациям никак не способствует его защищённости. Если речь просто о том, что подобное стремление разработчиков ОС и приложений греет души рядовымм пользователям, то ок, это вполне понятно и объяснимо. Но к безопасности оно никакого отношения не имеет.
Я просто приведу здесь несколько фактов, а как они отвечают на заданный вопрос -- решайте сами.
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 (в девичестве TruCrypt) на порядок более популярный проект. Если не больше. Вопрос уязвимостей в нём интересовал многих, но так случилось, что это множество хотящих никак не могло пересечься со множеством умеющих. Пока наконец не догадались прибегнуть к краудфандингу и собрали требуемые 70 килобаксов на проведение анализа. Аудит состоял из двух частей, включавших поиск недостатков уровня кода и уровня реализации криптографии. Для проведения аудита была привлечена стороння организация. Первая часть была выполнена за 5 недель двумя экспертами в области AppSec, вторая -- за 4 недели, также двумя экспертами в области криптографии. Аудит позволил выявить ряд уязвимостей, существовавших в проекте достаточно долгое время.
В случае 5 и 6 полноту проведённых исследований и корректность отчётов никто толком не проверял. Отчёты не содержат информации о том, почему исследователи сочли защищённой ту или иную часть этих проектов, которая бы покрывала весь код целиком (информация, без которой невозможно ни подтвердить, ни опровергнуть полноту проведённых исследований).
---
А теперь, ответьте на два вопроса:
1. Вы получили код всех используемых вами приложений, прошивок устройств (включая бейсбенды -- ну допустим), операционных систем и т.п. Ваши дальнейшие действия?
2. Что выделяет вас среди всей прочей массы пользователей всего этого хозяйства?
Автор: Michael7
Дата: 06.03.17
Michael7:Дата: 06.03.17
Владимир, а возможность (хотя бы потенциальная) для пользователя полностью контролировать ОС и программы, в том числе узнавать как она устроена с подробностями — это входит в понятие безопасности или нет? В том числе делать это легально. У меня такое впечатление, что здесь у нас расхождение по этому пункту. Для меня и видимо для 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 (в девичестве TruCrypt) на порядок более популярный проект. Если не больше. Вопрос уязвимостей в нём интересовал многих, но так случилось, что это множество хотящих никак не могло пересечься со множеством умеющих. Пока наконец не догадались прибегнуть к краудфандингу и собрали требуемые 70 килобаксов на проведение анализа. Аудит состоял из двух частей, включавших поиск недостатков уровня кода и уровня реализации криптографии. Для проведения аудита была привлечена стороння организация. Первая часть была выполнена за 5 недель двумя экспертами в области AppSec, вторая -- за 4 недели, также двумя экспертами в области криптографии. Аудит позволил выявить ряд уязвимостей, существовавших в проекте достаточно долгое время.
В случае 5 и 6 полноту проведённых исследований и корректность отчётов никто толком не проверял. Отчёты не содержат информации о том, почему исследователи сочли защищённой ту или иную часть этих проектов, которая бы покрывала весь код целиком (информация, без которой невозможно ни подтвердить, ни опровергнуть полноту проведённых исследований).
---
А теперь, ответьте на два вопроса:
1. Вы получили код всех используемых вами приложений, прошивок устройств (включая бейсбенды -- ну допустим), операционных систем и т.п. Ваши дальнейшие действия?
2. Что выделяет вас среди всей прочей массы пользователей всего этого хозяйства?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Безопасность открытого кода (опять, да)
Отвечая на вопрос
Пользователь всегда будет находиться в неравном положении с атакующими, поскольку не обладает навыками, необходимыми для сколь-нибудь адекватной оценки защищённости исходного кода. Даже, если этот пользователь является разработчиком -- навыки, необходимые для разработки кода ортогональны навыкам, требующимся при ревью кода на предмет возможных уязвимостей. Сам факт открытости кода к просмотру и даже модификациям никак не способствует его защищённости. Если речь просто о том, что подобное стремление разработчиков ОС и приложений греет души рядовымм пользователям, то ок, это вполне понятно и объяснимо. Но к безопасности оно никакого отношения не имеет.
Я просто приведу здесь несколько фактов, а как они отвечают на заданный вопрос -- решайте сами.
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. Что выделяет вас среди всей прочей массы пользователей всего этого хозяйства?
Автор: Michael7
Дата: 06.03.17
Michael7:Дата: 06.03.17
Владимир, а возможность (хотя бы потенциальная) для пользователя полностью контролировать ОС и программы, в том числе узнавать как она устроена с подробностями — это входит в понятие безопасности или нет? В том числе делать это легально. У меня такое впечатление, что здесь у нас расхождение по этому пункту. Для меня и видимо для 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. Что выделяет вас среди всей прочей массы пользователей всего этого хозяйства?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>