Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в OpenVPN, допускающая подстановку данных в плагины и сторонние обработчики"	+/–
Сообщение от opennews (?), 09-Янв-25, 11:25
Раскрыты сведения об уязвимости (CVE-2024-5594) в пакете для создания виртуальных частных сетей OpenVPN, которая  может привести к подстановке  произвольных данных в сторонние исполняемые файлы или плагины в системе на другой стороне соединения. Уязвимость вызвана отсутствием проверки наличия нулевых байтов и некорректных символов при обработке управляющих сообщений, таких как PUSH_REPLY... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62530
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

2. Скрыто модератором	–1 +/–
Сообщение от Аноним (-), 09-Янв-25, 11:36
>  может привести к подстановке произвольных данных в сторонние исполняемые файлы или плагины в системе на другой стороне соединения > проблема переведена в разряд критических (уровень опасности 9.1 из 10). О, в очередной раз дыряшечные недостроки отстрелили ногу по самую оппу! Никогда такого не было и вот опять))) Правильно про них написали, что это "the most expensive one-byte mistake"
Ответить | Правка | Наверх | Cообщить модератору

3. Скрыто модератором	–5 +/–
Сообщение от Аноним (-), 09-Янв-25, 11:47
Не зря Торвальдс сказал что по сравнению с ЭТИМ - wireguard это "work of art" (C).
Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	–5 +/–
Сообщение от Фнон (-), 09-Янв-25, 11:54
Т.е они в июне рассказывали про незначительный баг (ну подумаешь логи забиваются мусором), а сами, скорее всего знали про серьезность, и поменяли задним числом? Это очень некрасиво - много людей не будет обновляться, если в changelog'е какие-то минорные изменения.
Ответить | Правка | Наверх | Cообщить модератору

	7. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	–2 +/–
	Сообщение от Аноним (-), 09-Янв-25, 12:03
	> а сами, скорее всего знали про серьезность, и поменяли задним числом? Неа, все намного хуже - до них просто не поняли к чему может привести эта проблема. И только потом до жирафа дошло. Прям показатель уровня современных кодеров.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	–2 +/–
	Сообщение от Аноним (12), 09-Янв-25, 12:43
	Неправда им сказали подержать уязвимость и не устраивать шумиху пока мы тут за несогласными не последним, а потом это отверстие закрывайте, а новое открывайте.
	Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
Сообщение от Аноним (-), 09-Янв-25, 12:00
Функция check_incoming_control_channel, куда был добавлен фикс, была написана 5 лет назад. Отличная закладка! Минимум пять лет тыщщи глаз не видели дыру и спокойно пользовались открытым, надежным и заслуживающим доверия опенсорным продуктом. А сейчас "oh, it just a bug!"
Ответить | Правка | Наверх | Cообщить модератору

	10. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от Аноним (-), 09-Янв-25, 12:21
	> Отличная закладка! Минимум пять лет тыщщи глаз не видели дыру и спокойно пользовались В OpenVPN сто лет к ряду была известная всем кто минимально интересовался - дыра в дефолтной конфиге - кода он ТИП СЕРТИФИКАТА НЕ ПРОВЕРЯЛ, ОЛОЛО. И каждый первый клиент - мог взять и нагло митмануть ближнего своего, откосплеив сервак своим сертом. Он же той же ауторити выписан! :D Так что спокойно ЭТИМ пользовались только те кто не интересовался что сие за летающий макаронный монстр и как его делают. p.s. надеюсь это объясняет почему вайргад всем этим не занимается :)
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от Витюшка (?), 09-Янв-25, 15:26
	А чем пользовались те, кто интересовался?
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+1 +/–
	Сообщение от User (??), 09-Янв-25, 15:32
	Предполагаю, что IPSec'ом - там способов выстрелить себе в ногу еще больше - но по какой-то причине было принято документацию читать, а не хаутуи копипастить.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	–1 +/–
	Сообщение от Аноним (-), 10-Янв-25, 12:42
	> Предполагаю, что IPSec'ом - там способов выстрелить себе в ногу еще > больше - но по какой-то причине было принято документацию читать, > а не хаутуи копипастить. Не, заменять одну энтерпрайз-блевотень с кучей вулнов, на другую - еще страшнее - и с в 2 раза больше вулнов - это прерогатива покусаных энтерпрайзом господ. А всякие относительно мелкие VPN не покусаные баззвордами типа TLS/SSL и "стандарты" - были много лет. Сейчас им жить стало намного сложнее из-за вайргада, который примерно это самое - но еще в ядре, так что маленький, простой в настройке - и очень шустрый. Так что конкурировать с ним стало конечно гораздо душнее.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+2 +/–
	Сообщение от User (??), 10-Янв-25, 13:21
	>> Предполагаю, что IPSec'ом - там способов выстрелить себе в ногу еще >> больше - но по какой-то причине было принято документацию читать, >> а не хаутуи копипастить. > Не, заменять одну энтерпрайз-блевотень с кучей вулнов, на другую - еще страшнее > - и с в 2 раза больше вулнов - это прерогатива > покусаных энтерпрайзом господ. А всякие относительно мелкие VPN не покусаные баззвордами > типа TLS/SSL и "стандарты" - были много лет. Сейчас им жить > стало намного сложнее из-за вайргада, который примерно это самое - но > еще в ядре, так что маленький, простой в настройке - и > очень шустрый. Так что конкурировать с ним стало конечно гораздо душнее. Звиняйте, хлопцi - но разве что в нише "для себя и кота" - в остальных wg не делает примерно "ничего" полезного, сорян. И да, даже со скотом судя по бенчмаркам того же cillium'а - как-то ниочень вышло, ipsec засчет offload'а криптографии работает - сюрприииз! быстрее. _СЕЙЧАС_ у норот все больше checkpoint, cisco anyconnect, citrix secure access - да даже ms sstp, блин. Нужны complience policy оконечных устройств, нормальные (Нормальные, Карл!) клиенты для примерно всех ОС, централизованное управление зоопарком, развитая маршрутизация, отсутствие проблем за NAT'ами\FW, динамическое управление, контроль аномалий трафика + расширенные возможности FW, в нишевых кейсах - недетектируемость и т.д. - а не "Мааам! Мааам! Смотри как я зашифровал трафик между двумя хостами!" Чтобы из WG вот это всё сделать нуээээ... пока вроде не вышло еще ни у кого, но пытаются, да.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	–1 +/–
	Сообщение от Аноним (-), 10-Янв-25, 12:39
	> А чем пользовались те, кто интересовался? Сейчас они пользуются в основном чем-то типа вайргада. А тогда всякими мелкими наколенными самопалами, менее известными и не такими навороченными опять же. Дабы избегать таких залетов.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	42. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+1 +/–
	Сообщение от нах. (?), 10-Янв-25, 14:32
	ты опять подменил понятия - те кто интересовался, как пользовались _нормальными_ решениями (и одно из них таки openvpn) так и продолжают. А вайргад - удел васянов с подкроватным локалхостом. Как и все твои самопалы. Причем от кого вы прячетесь - никто не знает, потому что никому вы нахрен просто не нужны. (и да, я совершенно уверен что васянские попытки как-то менеджить вайргады - хотя бы вот автоматически обновлять ключи регулярно - сплошное, законченное, эталоннейшее шерето. Опять же никем не поломанное только потому что нахрен никому не сдалось) Ну а у тебя, наверняка, один ключ от всего, и не меняется уже пять лет. Безопастно!
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	–1 +/–
	Сообщение от Аноним (44), 11-Янв-25, 05:49
	Твои страдания по поводу Wireguard вызывают недоумение. Система простая как полено. Циска мусолит добавить wg в роутеры, сразу в хардварном исполнении. Все пользуются, всё работает, ключи ротейтятся, один пох спать не может.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от пох. (?), 11-Янв-25, 14:11
	Никому кроме тебя и таких же как ты васянов - не нужна еще одна система "простая как полено". Мы не печки топим, у нас задачи чуток посложнее. Что ж до вас это никак не дойдет-то до сих пор?
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+3 +/–
	Сообщение от User (??), 09-Янв-25, 15:30
	Уф. Если под "типом сертификата" вы понимаете nsCertType - то тут все вопросы к openssl, его в чистом виде где-то в районе 1.1 депрекейтнули, а стандартом оно и не было никогда. Если вы про extendedkeyusage который serverAuth\clientAuth - то формально они даже совершенно правы и все вопросы к IETF: RFC 5280 т.к. формально он на всю бошку optional и - по замыслу отсосдателей - должен использоваться исключительно для "TLS WWW server authentication" а не для всякого там опенвэпээна. Проверять KU\EKU и считать, что этого достаточно - это надо даже не "разработчиком OpenVPN" быть а прям даже "экспертом opennet". (Вот то, что эта борода _все еще_ не умеет в проверку соответствия SAN (Не, ну формально - дергай скрЫпт в --tls-verify и хоть запроверяйся) таки бида-огорчение. Т.е. и тут конечно можно дiдам в бороды наплевать и на RFC2818 пожаловаться - одни не подумали про несколько DNS-имен, другие deprecate'нули использование CN в этом качестве и напихали возможностёв в альтернативу (Сложьна!) - но то уже совсем в пользу бедных будет. ) Вместо этого все давно уже используют verify-x509-name - а кто икспердт, слышал звон и читал не тот хаутуй - тот может однажды удивиться, что CA оказывается может более одного сертификата с EKU 1.3.6.1.5.5.7.3.1 выписать - и громко жаловаться в спортлото на "небезопасность openvpn" потом.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	26. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от нах. (?), 09-Янв-25, 19:08
	> CA оказывается может более одного сертификата с EKU 1.3.6.1.5.5.7.3.1 выписать ну если тебе ломанули CA - то он выпишет (себе) и с правильным x509-name, столько, сколько понадобится васяну. А тут прикол был в том, что и выписывать ничего не надо - уже ж выписан, на твое честное имя, берешь и пользуешь в качестве серверного, зуб даю - сервер я! Увизгвимость, разумеется, исключительно теоретическая, потому что зачем ты в той стремной лабе полез подключаться к корпоративной сетке - совершенно непонятно. А если "коллеги" тебе такое прямо в сети предприятия устроили - то тут не впн чинить надо, а съ36ывать за границу, прихватив на память чей-нибудь чужой ноутбук, а то завтра они этим не ограничатся и на мясо тебя продадут.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от User (??), 09-Янв-25, 19:46
	> ну если тебе ломанули CA - то он выпишет (себе) и с правильным x509-name, столько, сколько понадобится васяну. Почему "ломанули"? Зачем "ломанули"? Просто берешь _любой_ выписанный этим же CA серверный сертификат и пионЭр с "типом сертификата" и чувством глубокой защищенности из хаутуя идёт... ну вот туда и идет. А про то, что под ovpn оказываецца! (не) нужно отдельный (intermediate) CA заводить - в прионЭрских хаутуях не писано.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от нах. (?), 09-Янв-25, 20:02
	ну такоэ тож... у чувака с выписанным корп-CA сертификатом хоть чего-нибудь тоже дофига интересных возможностей без всякого openvpn. (от intermediate толку мало, нужно просто отдельный CA, которому незачем вовсе быть в корпоративной PKI, этот серт выписывается один раз и навсегда, можешь все запчасти от того CA сразу после этого удалить нахрен вместе с закрытым ключом, мы им никогда и ничего больше подписывать не будем) То что в openvpn нельзя просто сделать key pining без всякого "ca" - в общем-то вопрос к его разработчикам, видимо, черезмерно увлекавшимися корпоративными игрищами в ущерб надежности и простоте.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от User (??), 09-Янв-25, 20:13
	> ну такоэ тож... у чувака с выписанным корп-CA сертификатом хоть чего-нибудь тоже > дофига интересных возможностей без всякого openvpn. MITM на оборудовании мы организовать уже можем - а "найти" сертификат еще нет? Ну... бывает. > (от intermediate толку мало, нужно просто отдельный CA, которому незачем вовсе быть > в корпоративной PKI, этот серт выписывается один раз и навсегда, можешь > все запчасти от того CA сразу после этого удалить нахрен вместе > с закрытым ключом, мы им никогда и ничего больше подписывать не > будем) Ну, depends on. Я бы скорее сказал, что перспективу управлять мульеном разных CA ИБ в гробу видела - но тут возможны варианты вплоть до того, что CA в веденьи инфры, а не безов оказывается... > То что в openvpn нельзя просто сделать key pining без всякого "ca" > - в общем-то вопрос к его разработчикам, видимо, черезмерно увлекавшимися корпоративными > игрищами в ущерб надежности и простоте. Аминь.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от нах. (?), 09-Янв-25, 21:01
	> MITM на оборудовании мы организовать уже можем - а "найти" сертификат еще нет? ну как бы да, обычно это сильно разные направления. Хотя, конечно, надо просто попросить. (но тогда и взламывать впн не понадобится) > Ну, depends on. Я бы скорее сказал, что перспективу управлять мульеном разных CA ИБ в > гробу видела ну вот авторы видимо как раз такой подход и имели в виду - что сертификат подтверждает не столько валидность сервера, сколько то что кому-то _разрешили_ содержать этот сервер. В реальной жизни разумеется - разрешение где-то отдельно, а какой там сертификат - иб никогда и не проверит.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от User (??), 10-Янв-25, 14:04
	> То что в openvpn нельзя просто сделать key pining без всякого "ca" > - в общем-то вопрос к его разработчикам, видимо, черезмерно увлекавшимися корпоративными > игрищами в ущерб надежности и простоте. Кстати, забавно - но похоже уже можно :) "--peer-fingerprint args Specify a SHA256 fingerprint or list of SHA256 fingerprints to verify the peer certificate against. The peer certificate must match one of the fingerprint or certificate verification will fail. The option can also be inlined When the --peer-fingerprint option is used, specifying a CA with --ca or --capath is optional. This allows the he --peer-fingerprint to be used as alternative to a PKI with self-signed certificates for small setups. See the examples section for such a setup. "
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	41. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от нах. (?), 10-Янв-25, 14:25
	хорошая новость. И можно, действительно, навсегда оставить self-signed.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	–1 +/–
	Сообщение от Аноним (-), 10-Янв-25, 12:56
	> Уф. Если под "типом сертификата" вы понимаете nsCertType - то тут все > вопросы к openssl, Это - вранье, или некомпетенция. В OpenVPN даже директива с проверкой типа серта для конфига - была дофига. Но - вот - неактивная по дефолту, пока это не стало совсем уж общеизвестной антифичой, расписаной в каждом FAQ для кулхацкеров. А когда репутация стала совсем сливаться - там они конечно расчехлились. Но вскоре пришел wg и дал этим дурням мастеркласс как это надо было делать правильно.а А кроме сабжевого CVE у сабжа дыр вооьще - хватало. Потому что идея тянуть с сервера конфигурацию сети - да еще в эвон каком объеме - by design достаточно стремная. А TLS/SSL корректно использовать - не умеет из программ почти никто. Ну может кроме браузеров. И то. > депрекейтнули, а стандартом оно и не было никогда. > Если вы про extendedkeyusage который serverAuth\clientAuth Я не помню какое там поле серта за это отвечает, охота мне в этим энтерпрайз какахах копаться, аж два раза. Но помню что у OpenVPN была отдельная директива конфига - проверять тип серта. И вот тогда - атака не катила. Но эта фича была энное время выключена по дефолту - и чтоб не получить граблей надо было ЯВНО активировать это дело. Чего конечно почти никто не делал. Зачем так? А спросите у этих чудаков. > правы и все вопросы к IETF: RFC 5280 т.к. формально он на всю бошку optional Мне все равно, IETF там, RFC, или кто. Если меня может MITM в дефолтной конфиге огреть если я не станцую эвон чего - это плохое решение для VPN, не выполняющее свои функции защиты трафика. > Проверять KU\EKU и считать, что этого достаточно - это надо даже не > "разработчиком OpenVPN" быть а прям даже "экспертом opennet". В вон том случае - это даже работает. Потому что _та_ CA как правило эти серты - автогенерит, каждому клиенту, ну а серт должен быть подписан именно вон той CA. И в этом случае атакующему - если он не админ сервера с этой CA - вот, как максимум, светит получить обычный клиентский серт, как 1 из юзерей VPNа. А вот то что он в дефолтной конфиге потом сможет сервер VPN изобразить с своим клиентским сертом, и проверка пройдет, ибо CA правильная и серт валиден, а то что он клиентский всем пофиг... ...да, вы правы, на самом деле это вообще повод не пользоваться TLS как таковым. > в альтернативу (Сложьна!) - но то уже совсем в пользу бедных будет. ) К счастью вон там уже появилось рещение которое прсото работает - защищает канал - без заучивания 20-этажных заклинаний и уборки капканов с поля. > Вместо этого все давно уже используют verify-x509-name Не. Вместо этого все кому надо было - защиту канала - при минимуме возни и подстав - просто wg поюзали и забыли вон то как страшный сон. И да, появилось полно сервисов умеющих и атвтогенерацию ключей и менеджмент клиентов: свято место пусто не бывает!
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	39. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от User (??), 10-Янв-25, 13:56
	>> Уф. Если под "типом сертификата" вы понимаете nsCertType - то тут все >> вопросы к openssl, > Это - вранье, или некомпетенция. В OpenVPN даже директива с проверкой типа > серта для конфига - была дофига. Ну я и говорю - некомпетентность. Была, была директива --ns-cert-type - но того-этого... вся вышла следом за openssl'ем. Потом да, заменили на --remote-cert-(ku|eku|tls) - но по вышеописанным причинам называть ЭТО "типом сертификата" - ну, такоэ. > Но - вот - неактивная  по дефолту, пока это не стало совсем уж общеизвестной антифичой, расписаной в каждом FAQ для кулхацкеров. Уф. Ну, т.е. я конечно пред-по-ла-га-ю, что OpenVPN вы ТОЖЕ кроме как в журнале "Хакер" нигде не видели - но что вы подразумеваете под "дефолтом" в отношении openvpn? И, главное - что вы хотите видеть в качестве этого самого "дефолта"? > А когда репутация стала совсем сливаться - там они конечно расчехлились. И каким же это образом? Очень интересно узнать! > Но вскоре пришел wg и дал этим дурням мастеркласс как это надо > было делать правильно.а Ииии, как? Как проблему тяжкого legacy x.509 помогает решать WG? >> депрекейтнули, а стандартом оно и не было никогда. >> Если вы про extendedkeyusage который serverAuth\clientAuth > Я не помню какое там поле серта за это отвечает, охота мне > в этим энтерпрайз какахах копаться, аж два раза. Но помню что > у OpenVPN была отдельная директива конфига - проверять тип серта. И > вот тогда - атака не катила. Но эта фича была энное > время выключена по дефолту - и чтоб не получить граблей надо > было ЯВНО активировать это дело. Чего конечно почти никто не делал. > Зачем так? А спросите у этих чудаков. Ну вот если бы вы чего знали - про x509, openssl, openvpn - вопросов бы меньше было, да. >> правы и все вопросы к IETF: RFC 5280 т.к. формально он на всю бошку optional > Мне все равно, IETF там, RFC, или кто. Если меня может MITM > в дефолтной конфиге огреть если я не станцую эвон чего - > это плохое решение для VPN, не выполняющее свои функции защиты трафика. Охтыж. Еще раз, для openvpn'а в глаза не видевших - _не существует_ "дефолтовой конфиги" openvpn, вы её для подключения к серверу сами написать должны - и что вы в неё впишете ответственность в общем-то ваша, а не openvpn'а, компренде? Если вы хотите сказать, что _минимальный_ набор параметров, позволяющих выполнить подключение к удаленному серверу не обеспечивает надлежащий уровень безопасности - то вы даже будете правы, но если прочитаете написанное выше - то поймете, что у господ в распоряжении было вот ровно два стула - или VPN _не будет работать_ с формально валидными сертификатами - или ну... вот... конечному эксплуатанту придется включать голову. Более того, даже если вы таки да, будете требовать наличия соответствующих KU\EKU в сертификате - _нормальный_ уровень безопасности без включения головы достигнут все равно не будет, ибо - см. выше. >> Проверять KU\EKU и считать, что этого достаточно - это надо даже не >> "разработчиком OpenVPN" быть а прям даже "экспертом opennet". > В вон том случае - это даже работает. Потому что _та_ CA > как правило эти серты - автогенерит, каждому клиенту, ну а серт > должен быть подписан именно вон той CA. Уффф... и снова повеяло экспертизой. Даже уточнять, что именно имелось в виду не стану во избежание. > И в этом случае атакующему - если он не админ сервера с > этой CA - вот, как максимум, светит получить обычный клиентский серт, > как 1 из юзерей VPNа. А вот то что он в > дефолтной конфиге потом сможет сервер VPN изобразить с своим клиентским сертом, > и проверка пройдет, ибо CA правильная и серт валиден, а то > что он клиентский всем пофиг... Проверка KU\EKU в данном случае премерзкий кривой костыль, который не то, чтобы добавляет особой безопасности. Нормальное решение - см. выше, но у разрабов - лапки, а до _нормального_ workaround'а ъ-форчун-500-энтерпрайз-админы не дочитали. > ...да, вы правы, на самом деле это вообще повод не пользоваться TLS > как таковым. Не пользуйтесь! >> в альтернативу (Сложьна!) - но то уже совсем в пользу бедных будет. ) > К счастью вон там уже появилось рещение которое прсото работает - защищает > канал - без заучивания 20-этажных заклинаний и уборки капканов с поля. Ну вот конкретно с этим - оно справляется, да. Не то, чтобы хорошо - но как-то. Вот только openvpn сииииильно не только про "защиты канального уровня", да? >> Вместо этого все давно уже используют verify-x509-name > Не. Вместо этого все кому надо было - защиту канала - при > минимуме возни и подстав - просто wg поюзали и забыли вон > то как страшный сон. И да, появилось полно сервисов умеющих и > атвтогенерацию ключей и менеджмент клиентов: свято место пусто не бывает! Ну, да - если вам нужно вот только это - пуркуа бы не па. А вот вопрос наличия\отстутствия аналогичного рода уязвимостей в этих самых "сервисах автогенерации и менеджмента клиентов" требует своего исследователя - предполагаю, их там на полтора ipsec'а в сумме наберется ).
	Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	–1 +/–
Сообщение от Аноним (8), 09-Янв-25, 12:17
>сформированных в июне 2024 года. Проблема не стоит выделенного яйца, никто не ставит софт, который не выдержан года три в дубовых бочках после релиза.
Ответить | Правка | Наверх | Cообщить модератору

	11. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+3 +/–
	Сообщение от Аноним (-), 09-Янв-25, 12:22
	>> сформированных в июне 2024 года. > Проблема не стоит выделенного яйца, никто не ставит софт, который > не выдержан года три в дубовых бочках после релиза. Эм... в сформированных в июне 2024 года как раз фикс. А вот оказалось, что в твоих бочках совсем не мед, а нечто другое. И сейчас у тебя прекрасный выбор - или обновляться на ненастоявшийся софт, или пользоваться заведомо дырявой версией.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от Аноним (8), 09-Янв-25, 12:48
	>сформированных в июне 2024 года как раз фикс. Ты плохо прочитал новость, Аноним. Написано же: >В опубликованном несколько дней назад обновлении, проблема переведена в разряд критических (уровень опасности 9.1 из 10). Уязвимость появилась в июне, несколько дней назад её объявили критической и исправили. Через пару лет посмотрим, до конца ли исправили.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+1 +/–
	Сообщение от Аноним (-), 09-Янв-25, 12:57
	> Ты плохо прочитал новость, Аноним. Разве? А как понимать фразу: "Проблема устранена в выпусках OpenVPN 2.5.11 и 2.6.11, сформированных в июне 2024 года." Устранена. Но внедрили эту уязвимость гораздо раньше, можно посмотреть когда менялся файл. И это было несколько лет назад.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от Аноним (12), 09-Янв-25, 14:17
	Не надо туда смотреть. Не положено.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+3 +/–
	Сообщение от Аноним (19), 09-Янв-25, 14:35
	Что даже нельзя посмотреть имя и фамилию этого "бага"? А вдруг там зарубежный ЖинТян, а не наш родной отечественный! Это же возмутительно!!
	Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
Сообщение от Аноним (24), 09-Янв-25, 17:29
Я же говорил - именно в проекты "для анонимусов" бэкдоры и пихают. Корпораты же используют IPSec.
Ответить | Правка | Наверх | Cообщить модератору

	25. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+3 +/–
	Сообщение от Аноним (-), 09-Янв-25, 18:58
	Разумеется. Просто корпораты не боятся "злога хасударства!!11". К ним и так могут придти и попросить ключики. В некоторых странах по решению суда, а где-то и без. Поэтому и закладки делать в протоколах и софтине особого смысла нет. В отличие от софтин для васянов. Что мы собственно и видим.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+1 +/–
	Сообщение от Аноним (44), 09-Янв-25, 20:35
	Пихать в проекты для анонимусов бэкдоры бессмысленно. Любой анонимус и так на виду: соцсетями не пользуется, а если и пользуется, то самыми маргинальными; ОС и браузер нестандартные, в любой более-менее продвинутой системе сбора данных о посетителях видны как на ладони, и смена юзер-агента только хуже делает — сразу же помещает таких в отдельную категорию посетителей с поломанными браузерами; обычными «мирскими» делами такие персонажи интересуются крайне редко, газет и журналов не читают, телевизор не смотрят, и таким образом палятся за две минуты разговора. Вот и сам подумай, зачем тратить силы на бэкдоры, если анонимусы сами себя игрой в шпионов «подсвечивают»?
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	32. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+1 +/–
	Сообщение от Аноним (32), 09-Янв-25, 23:59
	Да я обратил внимание что не только анонимусы сбежали с соц сеточек, по крайней мере вк, да и новости только самые крупные знают
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от Аноним (44), 10-Янв-25, 00:42
	Те анонимусы давно в списках у кого надо. Я про остальной мир говорю.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
	Сообщение от Аноним (34), 10-Янв-25, 08:33
	Корпораты же используют IPSec. iplir же, импортозамещение же
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

43. "Уязвимость в OpenVPN, допускающая подстановку данных в плаги..."	+/–
Сообщение от seven (??), 10-Янв-25, 21:56
Не совсем понятно с Windows версией она есть или будет или там нет уязвимости?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема