Comments 40
Это наталкивает на мысль, что аудит исходников не даёт абсолютной гарантии отсутствия багов.
Куда больше нелепым кажется, что кто-то где-то вообще считал, что аудит исходников может дать абсолютную гарантию чего-либо.
Ну как же, это один из основных постулатов open-source — открытый код безопаснее, потому что каждый может изучить.
Всё зависит от пристальности изучения, личных навыков изучающего, количества изучающих и везения. Для тёмных целей это тоже верно. В любом случае, наличие открытых исходников даёт больше шансов большему числу людей их изучить. Для того же фазинга исходники тоже необходимы.
Смогут они найти что-то или нет — другой вопрос. Я, в некоторых проектах (или частях одного крупного), бывает сразу и о основную логику вникнуть не могу, требует времени. Что говорить о нештатной эксплуатации.
Смогут они найти что-то или нет — другой вопрос. Я, в некоторых проектах (или частях одного крупного), бывает сразу и о основную логику вникнуть не могу, требует времени. Что говорить о нештатной эксплуатации.
Безопаснее переходить дорогу за зеленый свет по пешеходному переходу солнечным днем, чем перебегать где попало в темной одежде ночью. Но абсолютной гарантии успеха даже первый вариант не дает.
Может и каждый, но вот кто это действительно делает? Вспомните историю с Heartbleed.
Вопрос в том, как был найден HeartBleed? Не благодаря ли тому, что код открытый?
Да, найдено поздно, но найдено. А сколько есть уязвимостей в проприетарных системах, можно и после взлома не узнать.
Да, найдено поздно, но найдено. А сколько есть уязвимостей в проприетарных системах, можно и после взлома не узнать.
Вопрос в том, как был найден HeartBleed? Не благодаря ли тому, что код открытый?
Неа. Это как раз хороший пример, который показывает, что и открытый код в большинстве случаев никто, кроме тех, кто непосредственно занимается его разработкой и сопровождением, не анализирует и не выверяет.
Будь код OpenSSL закрытым, ну нашел бы этот баг через те же несколько лет кто-то из внутренних разработчиков, только и всего.
Будь код OpenSSL закрытым, ну нашел бы этот баг через те же несколько лет кто-то из внутренних разработчиков, только и всего.
Или не нашёл бы…
Или нашёл бы, и не стал ничего с ним делать по договорённости со спецслужбами...
Ну так и с открытым абсолютно то же самое. Мы-то судим об одной уязвимости, которую нашли, при этом понятия не имеем, сколько их там ещё может быть. Так, чисто по статистике, какого-то преимущества по надёжности или безопасности у проприетарного или опенсурсного ПО не наблюдается. Т.е. сказать, что какая-то модель надёжнее, нельзя. Просто в проприетарном, если что, всегда можно ткнуть пальцем на конкретную организацию и сказать: «Это они виноваты». А в опенсурсе так не получится.
при этом понятия не имеем, сколько их там ещё может быть
Корректнее сказать, что мы не можем знать точно, сколько их там еще может быть. Но конечно же мы можем сделать оценку, исходя из прошлого опыта.
Так, чисто по статистике, какого-то преимущества по надёжности или безопасности у проприетарного или опенсурсного ПО не наблюдается
А вот такие утверждения нуждаются в доказательстве. Приведите, пожалуйста, статистику.
NSA точно делает.
Ну да, он безопаснее — но это не значит, что он абсолютно безопасен.
Открытый код не безопаснее, а «потенциально безопаснее».
То есть у каждого желающего есть потенциальная возможность анализировать код и искать в нем проблемы — не обязательно даже сидеть самому смотреть, или нанимать экспертов — можно хотя-бы по-быстрому прогнать исходники через анализатор и получить дополнительные данные о качестве кода.
То есть у каждого желающего есть потенциальная возможность анализировать код и искать в нем проблемы — не обязательно даже сидеть самому смотреть, или нанимать экспертов — можно хотя-бы по-быстрому прогнать исходники через анализатор и получить дополнительные данные о качестве кода.
Уязвимости так и будут появляться пока программы разрабатываются как произведения искуства, или творчества, если угодно.
Это как? Связи уловить не могу.
Речь, наверное, про то, что очень большая часть программистов самоучки-быдлокодеры, которые, например, на java пишут в процедурном стиле.
Правда сомнительно, чтобы в столь сложных проектах, как openvpn, мог разобраться и что-то дельное написать откровенный быдлокодер.
PS: Оскорбить ни кого не хочу. Просто факт: пока технология развивается — научного подхода ждать не стоит. Когда-нибудь IT это перерастет. Но пока это нормально.
Правда сомнительно, чтобы в столь сложных проектах, как openvpn, мог разобраться и что-то дельное написать откровенный быдлокодер.
PS: Оскорбить ни кого не хочу. Просто факт: пока технология развивается — научного подхода ждать не стоит. Когда-нибудь IT это перерастет. Но пока это нормально.
Никогда IT это не перерастёт. Научный подход в программировании и так есть, с него, собственно, всё и началось. Он даже не сильно более требователен к качеству персонала. Но его проблема в том, что он требует просто астрономических трудозатрат, которые себя банально не окупают.
Ну перестали же врачи резать на удачу. Изучили/изобрели наркоз, антисептику и асептику, рентген… Чем мы хуже?
Просто постепенно будет написан почти весь код, который нужен миру и пространством для работы программистов останется только рефакторинг и оптимизация под частные задачи. Оптимизация мало сказывается на безопасности (не выгодно ломать код, который ни где не повторяется), а для рефакторинга нужно не только язык понимать, но и понимать что-то в теории программирования.
Просто постепенно будет написан почти весь код, который нужен миру и пространством для работы программистов останется только рефакторинг и оптимизация под частные задачи. Оптимизация мало сказывается на безопасности (не выгодно ломать код, который ни где не повторяется), а для рефакторинга нужно не только язык понимать, но и понимать что-то в теории программирования.
Ну перестали же врачи резать на удачуЧерез несколько тысяч лет после зарождения медицины…
И количество врачебных ошибок все еще велико. Антисептика работает не всегда, от наркоза просыпаются не все, а трактовка мутных рентгеновских снимков — зачастую искусство.
У нас тоже, в общем-то есть аналогичные инструменты. Вместо антисептики — защитное программирование, вместо наркоза — сэндбоксы, а вместо рентгена вот фаззинг, например.
Мне это напомнило мысли отсюда:
… у большинства программистов не сформировано структурное отношение к программе (здесь слово «структурное» употребляем без прямой связи со структурным программированием, а в общем смысле). Программа для них — это нечто сродни литературному тексту, который пишет программист-«писатель», пытаясь описать требующиеся от машины действия. Более того, в таком отношении присутствует даже некая «художественная трепетность».
Вывод: восприятие программы как инженерной системы, составленной из конструкций, которые соединяются по определённым правилам, не сформировано у массовых программистов, и это представляет реальную проблему для развития ИТ как инженерной деятельности. Обязательное требование к инженерной деятельности — наличие строгих (обычно математизированных) методов, позволяющих анализировать и гарантировать свойства создаваемых конструкций, выводя их из свойств использованных элементов и соединений.
> Следуется обновиться до версий 2.4.3 и 2.3.17
У меня убунта, обновился:
Версия значительно старше, но дата сборки — вчерашняя. Уязвима она или нет?
У меня убунта, обновился:
root@42116f182a1c:/# openvpn --version
OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Jun 22 2017
Версия значительно старше, но дата сборки — вчерашняя. Уязвима она или нет?
UFO just landed and posted this here
Для Debian/Ubuntu проект OpenVPN поддерживает собственный репозиторий: https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos (только i386 и amd64) со свежими сборками.
Вчера на #openvpn-devel как раз шутили по этому поводу насчёт debian и recent в одном предложении:
Kind | another good thing about what happened, I haven't previously noticed you guys run a debian repository with recent builds
@cron2 | he said "debian" and "recent" in the same sentence...
CRCinAU | recent in debian terms is about 4 weeks from something being EOL'ed
@ecrist | and by 4 weeks from you mean 4 weeks after it's been EOL'd.(так и не понял, как тут сделать блок текста моноширинным шрифтом и без подсветки)
Если "dpkg -l openvpn" вернет 2.3.2-7ubuntu3.2 (для 14.04) — то с исправлениями (версия от 22 июня 2017):
https://packages.ubuntu.com/trusty/amd64/openvpn -> Ubuntu Changelog
http://changelogs.ubuntu.com/changelogs/pool/main/o/openvpn/openvpn_2.3.2-7ubuntu3.2/changelog
openvpn (2.3.2-7ubuntu3.2) trusty-security; urgency=medium
- SECURITY UPDATE x 7… — Marc Deslauriers marc.deslauriers@ubuntu.com Thu, 22 Jun 2017 10:51:34 -0400
Xenial 16.04: https://packages.ubuntu.com/xenial/amd64/openvpn — 2.3.10-1ubuntu2.1
yakkety 16.10: https://packages.ubuntu.com/yakkety/amd64/openvpn — openvpn 2.3.11-1ubuntu2.1
zesty 17.04: https://packages.ubuntu.com/zesty/amd64/openvpn — openvpn (2.4.0-4ubuntu1.3)
Вот зачем выкладывать это после того как только-только (позавчера) релиз с заплаткой вышел. В репах пока ничего нет. Придется самому собирать.
Для некоторых дистрибутивов можно установить последнюю версию с оф. сайта.
А как узнать, проверяли ли его при помощи PVS-Studio?
Дружелюбно попросить сотрудников компании (например, Andrey2008, foto_shooter, AsyaRak, SvyatoslavMC) ответить, если им не сложно.
Спасибо! Отправил сообщения двум сотрудникам из списка: Andrey2008 и SvyatoslavMC (остальные двое read-only — наверное нет смысла к ним обращаться?).
Мы не проверяли проект OpenVPN. Проверял ли его кто-то ещё, я не знаю, но думаю, что нет.
Найдем ли мы такие ошибки? Не знаю, надо пробовать, но сомневаюсь. Надо понимать, что ранее мы не ориентировались в направлении поиска уязвимостей и только в последние месяцы начали смотреть в эту сторону. Там есть некоторая специфика, которой мы будем учить анализатор.
Сейчас PVS-Studio круто ищет ошибки. Некоторые из них по совместительству являются уязвимостями. Буквально на днях, мой коллега продемонстрировал, что некоторые из уязвимостей могли бы быть найдены с помощью PVS-Studio, если бы его кто-то запустил :). Он взял некоторые проекты (старые версии исходников) и убедился, что уязвимости находятся. Вот эта заметка: "Как PVS-Studio может помочь в поиске уязвимостей?".
Найдем ли мы такие ошибки? Не знаю, надо пробовать, но сомневаюсь. Надо понимать, что ранее мы не ориентировались в направлении поиска уязвимостей и только в последние месяцы начали смотреть в эту сторону. Там есть некоторая специфика, которой мы будем учить анализатор.
Сейчас PVS-Studio круто ищет ошибки. Некоторые из них по совместительству являются уязвимостями. Буквально на днях, мой коллега продемонстрировал, что некоторые из уязвимостей могли бы быть найдены с помощью PVS-Studio, если бы его кто-то запустил :). Он взял некоторые проекты (старые версии исходников) и убедился, что уязвимости находятся. Вот эта заметка: "Как PVS-Studio может помочь в поиске уязвимостей?".
Ну что Вам ответить?) Я проверю неисправленные исходники, посмотрим с коллегами несколько найденных CWE, кое-что может совпадёт с материалом этой статью. Диагностики PVS-Studio действительно покрывают очень много серьёзных CWE (но не все, многое из оригинального списка не относится к C/C++/C#, также очень много неадекватных правил, на мой взгляд).
Далее идёт работа по эксплуатации уязвимости и приведении её к CVE, для чего нужен соответствующий опыт. Найдя код:
вряд ли я написал бы в статьи что-то типа
Мы пробуем сейчас сотрудничать со специалистами по безопасности, которые смогут выявлять уязвимости на основе найденных CWE с помощью PVS-Studio.
Далее идёт работа по эксплуатации уязвимости и приведении её к CVE, для чего нужен соответствующий опыт. Найдя код:
ASSERT(BLEN(buf) >= (int) sizeof(struct openvpn_tcphdr));
вряд ли я написал бы в статьи что-то типа
… существует возможность сконструировать такой пакет для сервера, чтобы указанное утверждение не выполнялось, и сервер остановится.
Мы пробуем сейчас сотрудничать со специалистами по безопасности, которые смогут выявлять уязвимости на основе найденных CWE с помощью PVS-Studio.
Можно даже самостоятельно взять открытый код и прогнать в PVS-Studio, и даже написать об этом на Хабр.
В этом и суть опен-сорса.
В этом и суть опен-сорса.
Посмотреть список на их сайте.
Не надо путать ручной аудит и фаззеры. Ручной аудит проверяет, что нет закладок. Фаззер пытается программу уронить. Можно иметь хорошо написанную программу с бэкдором, которой фаззер будет полностью доволен. И можно иметь честно написанную программу без бэкдоров, в которой фаззер будет ловить баги.
Фаззер хорошо, FUD в статье — нет.
Фаззер хорошо, FUD в статье — нет.
Государственная дума в первом чтении пропатчила уязвимости.
Sign up to leave a comment.
После аудита OpenVPN в нём нашли четыре опасные уязвимости