Специалист по безопасности Гвидо Вранкен (Guido Vranken) своим фаззером нашёл четыре серьёзные уязвимости в безопасности OpenVPN. Что интересно, это произошло после недавно проведённых двух полных аудитов безопасности исходного кода этой программы. Это наталкивает на мысль, что аудит исходников не даёт абсолютной гарантии отсутствия багов. Сам Гвидо Вранкен считает, что в некоторых случаях человеческий аудит — вообще не лучший вариант. Он говорит, что спонсорам аудита OpenVPN (деньги собирали через краудфандинг) не следовало оплачивать ручной аудит, а надо было нанять экспертов, которые будут заинтересованы в нахождении уязвимостей любыми средствами (через тот же фаззинг). Такая стратегия принесла бы наибольшие дивиденды. По крайней мере, сейчас мы видим, что фаззинг оказался эффективнее, чем анализ вручную.
OpenVPN — свободная реализация технологии виртуальной частной сети (VPN) с открытым исходным кодом для создания зашифрованных каналов между ПК. Создана Джеймсом Йонаном (James Yonan) и распространяется под лицензией GNU GPL.
Уже выпущены патчи для OpenVPN. Следуется обновиться до версий 2.4.3 и 2.3.17 как можно скорее, чтобы чувствовать себя в безопасности. Всё-таки дыры, найденные Гвидо, действительно очень серьёзные.
Гвидо Вранкен говорит, что в данном случае автоматический анализ оказался эффективнее, чем труд оплаченных аудиторов, так что в будущем стоит подумать, на что тратить бюджет. Согласно его сценарию, идеальный аудит должен начинаться с фаззинга, и только после автоматического анализа кода его должны анализировать эксперты.
Да, эксперты способны найти уязвимости там, где фаззинг неэффективен. Например, люди могут проверить криптографические операции и процедуры, проверить логику уровня приложения, оценить зависимости от определённых версий библлиотек, оценить вероятность утечек персональной информации через разные сторонние каналы и прочими способами проявить свою экспертизу. Но заставлять людей искать те же ошибки памяти — совершенно нерациональное расходование ресурсов, считает Гвидо. Такое гораздо быстрее и эффективнее делается автоматическими средствами.
Уязвимости
CVE-2017-7521
В функции
extract_x509_extension() в файле ssl_verify_openssl.c обнаружено сразу несколько ошибок, в том числе некорректная процедура освобождения памяти и некорректное использование структуры GENERAL_NAMES. GENERAL_NAMES *extensions;
int nid = OBJ_txt2nid(fieldname);
extensions = (GENERAL_NAMES *)X509_get_ext_d2i(cert, nid, NULL, NULL);Гвидо Вранкен пишет, что из-за такой реализации различные NID требуют разных структур хранения. То есть использование структуры
GENERAL_NAMES для каждого NID приведёт к эффектным падениям для некоторых NID.Соответственно, эта уязвимость классифицируется как удалённый сбой сервера / утечки памяти / двойное освобождение памяти (double-free, один и тот же участок памяти освобождается дважды).
CVE-2017-7520
Удалённый сбой клиента (включая MiTM), утечка данных.
Эта уязвимость угрожает только тем, кто использует OpenVPN для подключения к прокси NTLM version 2.
В файле
ntlm_phase_3() in ntlm.c обнаружен следующий код:if (( *((long *)&buf2[0x14]) & 0x00800000) == 0x00800000) /* Check for Target Information block */
{
tib_len = buf2[0x28]; /* Get Target Information block size */
if (tib_len > 96)
{
tib_len = 96;
}
{
char *tib_ptr = buf2 + buf2[0x2c]; /* Get Target Information block pointer */
memcpy(&ntlmv2_blob[0x1c], tib_ptr, tib_len); /* Copy Target Information block into the blob */
}
}Массив
buf2 здесь содержит данные, полученные пиром (прокси). Фаззинг показал несколько багов. Во-первых, если
buf[0x28] содержит значение 0х80 или больше, то tib_len станет отрицательным, что порушит memcpy. Во-вторых, buf[0x2c] используется как индекс для массива buf2. Если оно примет значение 0х80 или больше, то tib_len опять станет отрицательным и в данном случае будет указывать перед buf2, что приведёт к утечке данных. Память с этого адреса затем копируется в ntlmv2_blob, которым потом отправляется пиру. Налицо утечка данных и потенциальная возможность для атаки MiTM. Пароль пользователя, кстати, тоже хранится в стеке, и тоже будет отправлен пиру чистым текстом. Такая атака может быть спровоцирована злоумышленником в дистанционном режиме.Повреждение буфера стека у клиента и MITM (нет CVE)
Такой вариант атаки крайне малореалистичен, для него требуется сочетание ряда условий, в том числе пользователь должен выбрать имя пользователя, которое заканчивается на обратный слэш, и должен использоваться NTLM version 2.
CVE-2017-7508
Уязвимость позволяет осуществить удалённое обрушение сервера, на котором работает OpenVPN, если злоумышленник пошлёт на него специальным образом составленные данные.
Дело в том, что функция
mss_fixup_dowork() в файле mss.c содержит следующий код:ASSERT(BLEN(buf) >= (int) sizeof(struct openvpn_tcphdr));Гвидо Вранкен пишет, что существует возможность сконструировать такой пакет для сервера, чтобы указанное утверждение не выполнялось, и сервер остановится.
CVE-2017-7522
Атака с обрушением сервера mbed TLS/PolarSSL для своего успешного проведения требует, чтобы на сервере была установлена опция конфигурации
–x509-track. Уязвимости подвержена OpenVPN 2.4 (не 2.3), скомпилированная с криптографическим бэкендом mbed TLS/PolarSSL.Был найден ещё один баг (нет CVE) с переполнением буфера стека в случае исключительно длинной опции
–tls-cipher, но это не классифицировали как реальную уязвимость, потому что эксплуатация возможна только при условии ненадёжных настроек, а тогда атака доступна и по другим каналам.Для поиска уязвимостей Вранкен использовал фаззер libFuzzer вместе с AddressSanitizer (ASAN), UndefinedBehaviorSanitizer (UBSAN) и MemorySanitizer (MSAN).
Комментарии (40)
Dmitri-D
23.06.2017 06:17Уязвимости так и будут появляться пока программы разрабатываются как произведения искуства, или творчества, если угодно.
SystemXFiles
23.06.2017 06:33Это как? Связи уловить не могу.
hokum13
23.06.2017 09:20Речь, наверное, про то, что очень большая часть программистов самоучки-быдлокодеры, которые, например, на java пишут в процедурном стиле.
Правда сомнительно, чтобы в столь сложных проектах, как openvpn, мог разобраться и что-то дельное написать откровенный быдлокодер.
PS: Оскорбить ни кого не хочу. Просто факт: пока технология развивается — научного подхода ждать не стоит. Когда-нибудь IT это перерастет. Но пока это нормально.maxpsyhos
23.06.2017 11:40+1Никогда IT это не перерастёт. Научный подход в программировании и так есть, с него, собственно, всё и началось. Он даже не сильно более требователен к качеству персонала. Но его проблема в том, что он требует просто астрономических трудозатрат, которые себя банально не окупают.
hokum13
23.06.2017 15:15Ну перестали же врачи резать на удачу. Изучили/изобрели наркоз, антисептику и асептику, рентген… Чем мы хуже?
Просто постепенно будет написан почти весь код, который нужен миру и пространством для работы программистов останется только рефакторинг и оптимизация под частные задачи. Оптимизация мало сказывается на безопасности (не выгодно ломать код, который ни где не повторяется), а для рефакторинга нужно не только язык понимать, но и понимать что-то в теории программирования.Hellsy22
24.06.2017 07:39Ну перестали же врачи резать на удачу
Через несколько тысяч лет после зарождения медицины…
И количество врачебных ошибок все еще велико. Антисептика работает не всегда, от наркоза просыпаются не все, а трактовка мутных рентгеновских снимков — зачастую искусство.
У нас тоже, в общем-то есть аналогичные инструменты. Вместо антисептики — защитное программирование, вместо наркоза — сэндбоксы, а вместо рентгена вот фаззинг, например.
tikhenko
26.06.2017 11:00+1Мне это напомнило мысли отсюда:
… у большинства программистов не сформировано структурное отношение к программе (здесь слово «структурное» употребляем без прямой связи со структурным программированием, а в общем смысле). Программа для них — это нечто сродни литературному тексту, который пишет программист-«писатель», пытаясь описать требующиеся от машины действия. Более того, в таком отношении присутствует даже некая «художественная трепетность».
Вывод: восприятие программы как инженерной системы, составленной из конструкций, которые соединяются по определённым правилам, не сформировано у массовых программистов, и это представляет реальную проблему для развития ИТ как инженерной деятельности. Обязательное требование к инженерной деятельности — наличие строгих (обычно математизированных) методов, позволяющих анализировать и гарантировать свойства создаваемых конструкций, выводя их из свойств использованных элементов и соединений.Hellsy22
26.06.2017 12:09Жаль только, что этот вывод этот взят автором с потолка. А его «безусловно было продемонстрировано» на той же странице — попытка перейти от частного случая к общему выводу, причем путем радикального ухудшения читаемости кода.
mayorovp
26.06.2017 12:23Ну, я бы не сказал что качество кода радикально ухудшилось. Хотя и сильно лучше тоже не стало.
Scf
23.06.2017 08:13> Следуется обновиться до версий 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
Версия значительно старше, но дата сборки — вчерашняя. Уязвима она или нет?izzholtik
23.06.2017 11:23Обновлялся вчера вечером, сейчас 2.3.11
а какая у вас версия убунты?myemuk
26.06.2017 07:44+1Всегда сижу только на lts. Сейчас на 16.04, а на 18.04 перейду только осенью 18го. Пусть обкатают ее маленько перед переходом. Все-таки стабильность сейчас для меня важней всяких плюшек и новшевств.
nexion
24.06.2017 20:01+1Для 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.
(так и не понял, как тут сделать блок текста моноширинным шрифтом и без подсветки)
a5b
26.06.2017 02:52Если "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)
ars_ivanov
23.06.2017 08:44Вот зачем выкладывать это после того как только-только (позавчера) релиз с заплаткой вышел. В репах пока ничего нет. Придется самому собирать.
ChiefPilot
23.06.2017 10:59+2А как узнать, проверяли ли его при помощи PVS-Studio?
imanushin
23.06.2017 11:42+1Дружелюбно попросить сотрудников компании (например, Andrey2008, foto_shooter, AsyaRak, SvyatoslavMC) ответить, если им не сложно.
ChiefPilot
23.06.2017 12:53Спасибо! Отправил сообщения двум сотрудникам из списка: Andrey2008 и SvyatoslavMC (остальные двое read-only — наверное нет смысла к ним обращаться?).
Andrey2008
23.06.2017 13:59+1Мы не проверяли проект OpenVPN. Проверял ли его кто-то ещё, я не знаю, но думаю, что нет.
Найдем ли мы такие ошибки? Не знаю, надо пробовать, но сомневаюсь. Надо понимать, что ранее мы не ориентировались в направлении поиска уязвимостей и только в последние месяцы начали смотреть в эту сторону. Там есть некоторая специфика, которой мы будем учить анализатор.
Сейчас PVS-Studio круто ищет ошибки. Некоторые из них по совместительству являются уязвимостями. Буквально на днях, мой коллега продемонстрировал, что некоторые из уязвимостей могли бы быть найдены с помощью PVS-Studio, если бы его кто-то запустил :). Он взял некоторые проекты (старые версии исходников) и убедился, что уязвимости находятся. Вот эта заметка: "Как PVS-Studio может помочь в поиске уязвимостей?".
SvyatoslavMC
23.06.2017 13:48+1Ну что Вам ответить?) Я проверю неисправленные исходники, посмотрим с коллегами несколько найденных CWE, кое-что может совпадёт с материалом этой статью. Диагностики PVS-Studio действительно покрывают очень много серьёзных CWE (но не все, многое из оригинального списка не относится к C/C++/C#, также очень много неадекватных правил, на мой взгляд).
Далее идёт работа по эксплуатации уязвимости и приведении её к CVE, для чего нужен соответствующий опыт. Найдя код:
ASSERT(BLEN(buf) >= (int) sizeof(struct openvpn_tcphdr));
вряд ли я написал бы в статьи что-то типа
… существует возможность сконструировать такой пакет для сервера, чтобы указанное утверждение не выполнялось, и сервер остановится.
Мы пробуем сейчас сотрудничать со специалистами по безопасности, которые смогут выявлять уязвимости на основе найденных CWE с помощью PVS-Studio.
saboteur_kiev
23.06.2017 12:25Можно даже самостоятельно взять открытый код и прогнать в PVS-Studio, и даже написать об этом на Хабр.
В этом и суть опен-сорса.
amarao
23.06.2017 16:05+3Не надо путать ручной аудит и фаззеры. Ручной аудит проверяет, что нет закладок. Фаззер пытается программу уронить. Можно иметь хорошо написанную программу с бэкдором, которой фаззер будет полностью доволен. И можно иметь честно написанную программу без бэкдоров, в которой фаззер будет ловить баги.
Фаззер хорошо, FUD в статье — нет.
DrPass
Куда больше нелепым кажется, что кто-то где-то вообще считал, что аудит исходников может дать абсолютную гарантию чего-либо.
pronvit
Ну как же, это один из основных постулатов open-source — открытый код безопаснее, потому что каждый может изучить.
monah_tuk
Всё зависит от пристальности изучения, личных навыков изучающего, количества изучающих и везения. Для тёмных целей это тоже верно. В любом случае, наличие открытых исходников даёт больше шансов большему числу людей их изучить. Для того же фазинга исходники тоже необходимы.
Смогут они найти что-то или нет — другой вопрос. Я, в некоторых проектах (или частях одного крупного), бывает сразу и о основную логику вникнуть не могу, требует времени. Что говорить о нештатной эксплуатации.
Hellsy22
Безопаснее переходить дорогу за зеленый свет по пешеходному переходу солнечным днем, чем перебегать где попало в темной одежде ночью. Но абсолютной гарантии успеха даже первый вариант не дает.
myemuk
Может и каждый, но вот кто это действительно делает? Вспомните историю с Heartbleed.
saboteur_kiev
Вопрос в том, как был найден HeartBleed? Не благодаря ли тому, что код открытый?
Да, найдено поздно, но найдено. А сколько есть уязвимостей в проприетарных системах, можно и после взлома не узнать.
DrPass
Неа. Это как раз хороший пример, который показывает, что и открытый код в большинстве случаев никто, кроме тех, кто непосредственно занимается его разработкой и сопровождением, не анализирует и не выверяет.
Будь код OpenSSL закрытым, ну нашел бы этот баг через те же несколько лет кто-то из внутренних разработчиков, только и всего.
Radmin
Или не нашёл бы…
Или нашёл бы, и не стал ничего с ним делать по договорённости со спецслужбами...
DrPass
Ну так и с открытым абсолютно то же самое. Мы-то судим об одной уязвимости, которую нашли, при этом понятия не имеем, сколько их там ещё может быть. Так, чисто по статистике, какого-то преимущества по надёжности или безопасности у проприетарного или опенсурсного ПО не наблюдается. Т.е. сказать, что какая-то модель надёжнее, нельзя. Просто в проприетарном, если что, всегда можно ткнуть пальцем на конкретную организацию и сказать: «Это они виноваты». А в опенсурсе так не получится.
Hellsy22
Корректнее сказать, что мы не можем знать точно, сколько их там еще может быть. Но конечно же мы можем сделать оценку, исходя из прошлого опыта.
А вот такие утверждения нуждаются в доказательстве. Приведите, пожалуйста, статистику.
navion
NSA точно делает.
alexevil
Ну да, он безопаснее — но это не значит, что он абсолютно безопасен.
saboteur_kiev
Открытый код не безопаснее, а «потенциально безопаснее».
То есть у каждого желающего есть потенциальная возможность анализировать код и искать в нем проблемы — не обязательно даже сидеть самому смотреть, или нанимать экспертов — можно хотя-бы по-быстрому прогнать исходники через анализатор и получить дополнительные данные о качестве кода.