В конце октября разработчики OpenSSL предупредили, что грядущее обновление до версии 3.0.7 закроет критическую уязвимость. Примечательно, что это был бы всего второй критический баг в OpenSSL с 2016 года. Теперь, когда OpenSSL 3.0.7 представили официально, выяснилось, что исправления вышли сразу для двух серьезных уязвимостей, а рейтинг критического бага пересмотрели, и он больше не считается таковым.
В версии 3.0.7 исправили сразу две уязвимости (CVE-2022-3602 и CVE-2022-3786), затрагивающие OpenSSL версии 3.0.0 и выше (с 3.0.0 по 3.0.6).
Статус критической должна была получить проблема CVE-2022-3602, которая представляет собой произвольное 4-байтовое переполнение буфера стека, которое способно спровоцировать сбои или привести к удаленному выполнению произвольного кода (RCE).
В конечном итоге этой уязвимости присвоили рейтинг high severity («высокой степени серьезности»), так как по правилам критический баг должен затрагивать широко распространенные конфигурации, а перед проблемой CVE-2022-3602 уязвимы только на экземпляры OpenSSL 3.0 и более поздних версий.
Вторая проблема, CVE-2022-3786, может использоваться потенциальным злоумышленником посредством вредоносных адресов электронной почты, и способна спровоцировать отказ в обслуживании через переполнение буфера.
«Мы по-прежнему считаем эти проблемы серьезными уязвимостями, и затронутым пользователям рекомендуется установить обновления как можно скорее, — пишут разработчики OpenSSL. — Нам неизвестно о каких-либо работающих эксплоитах, которые могли бы привести к удаленному выполнению кода, и на момент публикации этого поста у нас нет доказательств использования этих проблем».
Невзирая на заверения разработчиков, некоторые ИБ-эксперты и поставщики поспешили приравнять обнаружение уязвимости в OpenSSL к нашумевшей проблеме Log4Shell, в 2021 году обнаруженной в библиотеке Log4J.
Издание Bleeping Computer отмечает, что такая паника преждевременна: по данным Censys, в сети можно обнаружить только около 7000 систем, на которых работают уязвимые версии OpenSSL (среди более чем 1 793 000 уникальных хостов), а по данным Shodan, таких экземпляров насчитывается около 16 000.
Компания Wiz.io, занимающаяся облачной безопасностью, провела анализ развертываний в основных облачных средах (например, AWS, GCP, Azure, OCI и Alibaba Cloud) и так же сообщает, что лишь 1,5% всех экземпляров OpenSSL подвержены свежей уязвимости.
Отдельную страницу, посвященную CVE-2022-3602 и всем связанным с ней данным, запустил известный ИБ-эксперт Маркус Хатчинс (Marcus Hutchins). Он объясняет, что проблема возникает при проверке сертификата X.509 и может использоваться для удаленного выполнения кода с помощью вредоносного сертификата TLS. Однако для эксплуатации требуется, чтобы вредоносный сертификат TLS был подписан доверенным удостоверяющим центром.
«Поскольку проверка сертификата обычно выполняется на стороне клиента, эта уязвимость в первую очередь затрагивает клиенты, а не серверы. Существует сценарий, когда сервер может быть взломан через TLS Client Authentication, что поможет обойти требования к подписи удостоверяющего центра, поскольку клиентские сертификаты обычно не требуется подписывать таким образом. Поскольку такая аутентификация, это редкое явление и на большинстве серверов она не включена, риск эксплуатации для серверов должен быть низким, — пишет Хатчинс. — Учитывая тот факт, что уязвимость в основном на стороне клиента, и требуется, чтобы вредоносный сертификат был подписан доверенным удостоверяющим центром (или чтобы пользователь проигнорировал предупреждение), ее сложно использовать, и я оцениваю вероятность эксплуатации как низкую».
Национальный центр кибербезопасности Нидерландов уже начал составлять список продуктов, которые, как подвержены или не подвержены свежему багу.
Стоит сказать, что аналитики компании Akamai отнесли к уязвимым дистрибутивы Redhat Enterprise Linux 9, Ubuntu 22.04+, CentOS Stream9, Kali 2022.3, Debian 12 и Fedora 36. Эксперты этой компании уже опубликовали правила OSQuery и YARA, которые должны помочь ИБ-специалистам обнаружить уязвимые продукты.
