Після аудиту OpenVPN в ньому знайшли чотири небезпечні уразливості

Фахівець з безпеки Гвідо Вранкен (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.

Відповідно, ця вразливість класифікується як віддалений збій сервера / mem / подвійне звільнення пам’яті (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 pointer block */
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).