Специалист по безопасности Гвидо Вранкен (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).
Автор: alizar
