В OpenSSL пропатчена уязвимость, грозящая удаленным выполнением кода

В OpenSSL пропатчена уязвимость, грозящая удаленным выполнением кода

В OpenSSL пропатчена уязвимость, грозящая удаленным выполнением кода

Кураторы популярного проекта OpenSSL выпустили патч для уязвимости, потенциально позволяющей удаленно выполнить вредоносный код на сервере. Пользователям настоятельно рекомендуется обновить криптобиблиотеку до сборки 3.0.5.

Опасная ошибка, которой был присвоен идентификатор CVE-2022-2274, классифицируется как переполнение буфера в куче. Уязвимость была привнесена с выпуском OpenSSL 3.0.4 в июне; причиной является некорректная реализация генератора 2048-битных ключей RSA для CPU c архитектурой x86_64 и поддержкой набора инструкций AVX-512.

Согласно бюллетеню (TXT), проблема затрагивает серверы SSL/TLS и иные, использующие закрытые ключи RSA-2048. Эксплойт возможен лишь в том случае, когда сервер запущен на машине, отвечающей вышеназванным условиям, и открывает возможность для удаленного выполнения стороннего кода.

О несовершенстве релиза OpenSSL 3.0.4 разработчики узнали на следующий день после выпуска — от аспиранта Сианьского университета электронных наук и технологий (Китай). Автор отчета также придумал, как исправить ситуацию, и его вариант патча был включен в состав обновления 3.0.5.

В той же (июньской) сборке была обнаружена другая, менее опасная уязвимость — CVE-2022-2097. Как выяснилось, при прогоне AES в режиме OCB на платформах 32-бит x86 с использованием расширения системы команд AES-NI данные при определенных условиях шифруются не полностью, что грозит утечкой. Проблема актуальна для ветки 3.0 и релиза OpenSSL 1.1.1; патч содержат выпуски 3.0.5 и 1.1.1q.

87% специалистов готовы доверить ИИ рекомендации по реагированию в SIEM

Российские компании готовы слушать советы ИИ в SIEM, но отдавать ему красную кнопку пока не собираются. Это показал опрос участников эфира AM Live «Российские SIEM 2026: что изменилось и как теперь выбирать?». Больше всего респонденты готовы доверить искусственному интеллекту рекомендации по реагированию на инциденты — этот вариант выбрали 87% участников.

Создание и доработку правил детектирования готовы делегировать 71%, а сбор контекста и подготовку резюме расследований — 58%.

Несколько осторожнее аудитория относится к триажу и приоритизации инцидентов — эту задачу ИИ согласны поручить 44% опрошенных. Ещё 39% готовы использовать его для поиска и формирования запросов.

А вот полностью автономное реагирование без подтверждения аналитика набрало всего 13%. В общем, ИИ уже можно посадить рядом с SOC-командой, поручить ему рутину и попросить подготовить план действий.

Но самостоятельно блокировать пользователей, отключать узлы и принимать другие потенциально болезненные решения ему пока не разрешают.


Участники также рассказали, что, по их мнению, сильнее всего изменит SIEM к 2030 году. Лидируют ИИ и автономные агенты с 34%. На втором месте — объединение SIEM с другими платформами информационной безопасности, за которое проголосовали 28% респондентов.

Изменений в экономике и моделях лицензирования ожидают 14%, появления новой архитектуры работы с данными — 13%, а развития облачных и гибридных моделей — 9%. Только 2% считают, что за ближайшие годы ничего существенно не поменяется. Железная выдержка, учитывая скорость, с которой сегодня переписывается рынок.

На эфире эксперты также обсудили ложные срабатывания, правила детектирования, MITRE ATT&CK, UEBA, производительность, масштабирование, хранение данных и TCO. Главный вывод: выбирать SIEM по красивой презентации больше нельзя. На пилоте придётся проверять не только скорость обработки событий, но и качество контента, удобство расследований и реальную стоимость дальнейшей эксплуатации.

RSS: Новости на портале Anti-Malware.ru