Експерти з безпеки описали дві довгоочікувані вразливості, які команда проекту OpenSSL виправила у вівторок, як проблеми, які потрібно вирішити швидко, але не обов’язково заслуговують екстреного реагування типу «відкинути все інше».
Випуск версії 3.0.7 майже повсюдно використовуваної криптографічної бібліотеки усуває дві вразливості переповнення буфера, які існують у версіях OpenSSL від 3.0.0 до 3.0.6.
Напередодні розголошення експерти з безпеки попереджали, що одна з проблем, спочатку характеризувався як «критичний» Проблема віддаленого виконання коду може спричинити проблему на рівні Heartbleed, повну проблему. На щастя, це, здається, не так — і, розкриваючи недолік, команда проекту OpenSSL заявила, що вирішила знизити рівень загрози до «високого» на основі відгуків організацій, які протестували та проаналізували помилку.
Пара переповнень буфера
Перший баг (CVE-2022-3602) справді міг — за певних обставин — увімкнути RCE, що спочатку спонукало деяких експертів із безпеки занепокоїтися, що недолік може мати наслідки для всієї галузі. Але виявляється, що є пом’якшувальні обставини: по-перше, це важко використовувати, як пояснюється нижче. Крім того, це стосується не всіх систем.
Зокрема, за словами Марка Еллзея, старшого дослідника з питань безпеки в Censys, зараз це стосується лише браузерів, які підтримують OpenSSL від 3.0.0 до 3.0.6, таких як Firefox і Internet Explorer; особливо не постраждав Google Chrome, який є провідним Інтернет-браузером.
«Очікується, що вплив буде мінімальним через складність атаки та обмеження способів її проведення», — каже він. «Організації повинні оновити тренінги з фішингу та стежити за джерелами розвідки про загрози, щоб переконатися, що вони готові, якщо вони стануть ціллю такої атаки».
На додаток, Алекс Ілгаєв, провідний дослідник безпеки в Cycode, зазначив, що недолік не можна використовувати в певних дистрибутивах Linux; Крім того, багато сучасних платформ ОС реалізують захист від переповнення стека, щоб у будь-якому випадку пом’якшити такі загрози, каже Ільгаєв.
Друга вразливість (CVE-2022-3786), який було виявлено під час розробки виправлення початкової вади, можна було використати для ініціювання умов відмови в обслуговуванні (DoS). Команда OpenSSL оцінила вразливість як дуже серйозну, але виключила можливість її використання для використання RCE.
Обидві вразливості пов’язані з функціональністю під назвою Пунікод для кодування інтернаціоналізованих доменних імен.
«Користувачі OpenSSL 3.0.0 – 3.0.6 є рекомендується якомога швидше оновити до 3.0.7”, – повідомила команда OpenSSL у блозі, що супроводжує розкриття помилок і випуск нової версії криптографічної бібліотеки. «Якщо ви отримуєте свою копію OpenSSL від постачальника операційної системи або іншої третьої сторони, вам слід якомога швидше отримати від них оновлену версію».
Не ще одне кровоточиве серце
Розкриття помилок обов’язково придушить — принаймні на даний момент — викликало широке занепокоєння через сповіщення команди OpenSSL минулого тижня про непередбачене розкриття помилки. Опис першої вади як «критичної», зокрема, спонукав кілька порівнянь з помилкою «Heartbleed» 2014 року — єдиною іншою помилкою в OpenSSL, яка отримала критичний рейтинг. Ця помилка (CVE-2014-0160) вплинула на широку область Інтернету, і навіть зараз її не повністю усунено в багатьох організаціях.
«Heartbleed був відкритий за замовчуванням у будь-якому програмному забезпеченні, яке використовувало вразливу версію OpenSSL, і зловмисники дуже легко могли використати його, щоб побачити криптографічні ключі та паролі, що зберігаються в пам’яті сервера», — каже Джонатан Кнудсен, керівник відділу глобальних досліджень у Synopsys Research Center Cybersecurity. . «Дві уразливості, щойно повідомлені в OpenSSL, є серйозними, але не однакового масштабу».
Важко використовувати помилки OpenSSL…
За словами Кнудсена, щоб використати будь-яку з нових вад, уразливі сервери повинні запитувати автентифікацію сертифіката клієнта, що не є нормою. А вразливим клієнтам потрібно буде підключитися до шкідливого сервера, що є звичайним і захищеним вектором атак, каже він.
«Ні в кого не повинно горіти волосся через ці дві вразливості, але вони серйозні, і їх потрібно вирішувати з належною швидкістю та старанністю», – зазначає він.
Тим часом у дописі в блозі SANS Internet Storm Center описав оновлення OpenSSL як виправлення переповнення буфера під час процесу перевірки сертифіката. Щоб експлойт працював, сертифікат має містити зловмисне ім’я, закодоване Punycode, і вразливість спрацює лише після перевірки ланцюжка сертифікатів.
«Спочатку зловмисник повинен мати зловмисний сертифікат, підписаний центром сертифікації, якому клієнт довіряє», — зазначив SANS ISC. «Здається, це не можна використовувати проти серверів. Для серверів це може бути використано, якщо сервер запитує сертифікат від клієнта».
Підсумок: ймовірність використання є низькою, оскільки вразливість складна для використання, як і потік і вимоги для її запуску, каже Ілгаєв із Cycode. Крім того, він впливає на відносно невелику кількість систем порівняно з тими, що використовують версії OpenSSL до 3.0.
…Але будьте старанними
У той же час, важливо мати на увазі, що вразливості, які важко використовувати, використовувалися в минулому, говорить Ілгаєв, вказуючи на експлойт без кліків, розроблений NSO Group для уразливості в iOS минулого року.
«[Крім того], як каже команда OpenSSL, «неможливо дізнатися, як кожна комбінація платформи та компілятора впорядкувала буфери в стеку», і тому віддалене виконання коду все ще може бути можливим на деяких платформах», – застерігає він.
І справді, Еллзі описує один сценарій того, як зловмисники можуть використати CVE-2022-3602, недолік, який команда OpenSSL спочатку оцінила як критичний.
«Зловмисник розмістить шкідливий сервер і спробує змусити жертву пройти автентифікацію на ньому за допомогою програми, вразливої до OpenSSL v3.x, потенційно за допомогою традиційної тактики фішингу», — каже він, хоча область обмежена через те, що експлойт переважно клієнтський. бік.
Подібні вразливості підкреслюють важливість наявності a перелік матеріалів програмного забезпечення (SBOM) для кожного використовуваного двійкового файлу, зазначає Ільгаєв. «Подивитися на менеджери пакунків недостатньо, оскільки цю бібліотеку можна зв’язати та скомпілювати в різних конфігураціях, що вплине на можливість використання», — каже він.
