Сформирован (https://openvpn.net/index.php/open-source/downloads.html) корректирующий выпуск пакета OpenVPN 2.4.2, в состав которого вошли исправления, устраняющие проблемы, выявленные в результате независимого аудита механизмов шифрования. Одновременно опубликован (https://ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quark.../) отчёт с раскрытием деталей (https://ostif.org/wp-content/uploads/2017/05/OpenVPN1.2final...) аудита. Напомним, что аудит был инициирован фондом OSTIF (Open Source Technology Improvement Fund) и выполнен французской компанией QuarksLab, которая уже привлекалась (https://www.opennet.me/opennews/art.shtml?num=45333) для аудита проекта VeraCrypt.
На основании выработанных в ходе проверки рекомендаций в OpenVPN 2.4.2 внесено семь исправлений: устранена одна опасная проблема, одна уязвимость средней степени опасности и пять несущественных недоработок. В частности, исправлены следующие уязвимости:
- CVE-2017-7478 (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-7478) - аутентифицированый пользователь может инициировать отказ в обслуживании VPN-сервера через отправку слишком большой порции данных в пакете P_CONTROL. Из-за простоты проведения атаки проблеме присвоен высокий уровень опасности. Серверы, использующие tls-auth/tls-crypt для шифрования пакетов аутентификации, проблеме не подвержены;
- CVE-2017-7479 (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-7479) - аутентифицированый пользователь может вызвать крах OpenVPN через переполнение счётчика пакетов Packet-ID. Для совершения атаки нужно отправить несколько сотен гигабайт данных.
URL: https://ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quark.../
Новость: http://www.opennet.me/opennews/art.shtml?num=46538
> переполнение счётчика пакетов Packet-ID. Для совершения атаки нужно отправить несколько сотен гигабайт данныхне так уж и много..
жесть что разработчики сами не догадались что кто-то может *действительно* использовать openvpn-соединение -- для дел (передавать через соединение сотни гогобайт полезных данных), а не подключиться на 3 минуты ради пары лулзов (пару сообщений на форумы)..
Вы, уважаемый, не говорите за разрабов, тем более такие фантазии. OpenVPN в проде стоит годами, и опыт накоплен - а "может вызвать" и "всегда вызывает" все же разные вещи.
Возможно, там надо передать очень много сотен гигабайт за сессию. Учитывая, что OpenVPN чудовищно режет скорость:"Предположим, вы подключаетесь к серверу в США из России через OpenVPN со стандартными значениями буферов сокета. У вас широкий канал, скажем, 50 МБит/с, но в силу расстояния, пинг составляет 100 мс. Как вы думаете, какой максимальной скорости вы сможете добиться? 5.12 Мбит/с."
пруф: https://habrahabr.ru/post/246953/)
это может быть сложной задачей (сессия окончена/порвалась - баг не случился).
Для тех, кому лень читать по ссылке: изменение размера буферов по умолчанию позволило поднять скорость по UDP с 30 до 80 мегабит. В 2,5 раза, Карл на ровном месте.
> Для тех, кому лень читать по ссылке: изменение размера буферов по умолчанию
> позволило поднять скорость по UDP с 30 до 80 мегабит. В
> 2,5 раза, Карл на ровном месте.это всем-известная проблема -- и конено же в старых версиях openvpn в конфигах люди меняли размеры этих буфферов
> Учитывая, что OpenVPN чудовищно режет скорость:на tcp соединении с некорректными mss
Несколько сотен гигабайт данных — это, как я понимаю, имеются в виду пакеты без полезной нагрузки. А при отправке полезных данных будут уже, наверное, десятки терабайт.
Аналитик или ТП делает в УЯх select * from ... и получает те самые гиги как из пушки, со всеми вытекающими.
>Серверы, использующие tls-auth/tls-crypt для шифрования пакетов аутентификации, проблеме не подверженыНет, они тоже подвержены проблеме, но злоумышленнику нужно иметь tls-auth или tls-crypt-ключ. Например, если это публичный VPN, то такие ключи у злоумышленника будут.
>> Серверы, использующие tls-auth/tls-crypt для шифрования пакетов аутентификации, проблеме
> не подвержены
>
> Нет, они тоже подвержены проблеме, но злоумышленнику нужно иметь tls-auth или
> tls-crypt-ключ. Например, если это публичный VPN, то такие ключи у злоумышленника будут.в новости сказано что уязвимость доступна для *аутентифицированного* пользователя...
как считаешь если пользователь уже прошёл аутентифицикацию -- может ли быть такого что у него не оказалось каких-то-там tls-auth-ключей?
если tls-auth-ключа нет -- то даже до аутентификации дело дойти не может
OpenConnect пока не проверяли?
кому нужно местечковое подельице в ещё непроверенных пучинах опенсорца?
Ну да, троян - предпочтительнее.
Ну куда ты зарываешься-то? Опенконнект это клиент для никому ненужного эниконнекта и жуноса пульза, и тут ты его прям равняешь с опенвпном, который нынче чуть ли не центр индустрии самодельного впна. Ненадо так.
> OpenConnect пока не проверяли?Было бы неплохо. %)