Версия OpenSSL 3.0.5 должна устранить дыру с потенциалом Heartbleed

Версия OpenSSL 3.0.5 должна устранить дыру с потенциалом Heartbleed

Версия OpenSSL 3.0.5 должна устранить дыру с потенциалом Heartbleed

Разработчикам OpenSSL v3 не хватило двух патчей, чтобы устранить уязвимость, которая с технической точки зрения может быть опаснее Heartbleed. Известно, что брешь приводит к повреждению памяти и угрожает x64-системам.

21 июня девелоперы выпустили версию OpenSSL 3.0.4, в которой устранялась уязвимость CVE-2022-2068. Интересно, что предыдущий патч для дыры CVE-2022-1292 не смог полностью избавить пользователей от проблемы.

Сейчас ситуация похожая: OpenSSL 3.0.4 требует дополнительного патча, поскольку этот релиз содержит баг, которым может легко воспользоваться условный киберпреступник. В случае успешной эксплуатации атакующий сможет выполнить вредоносный код на одном из двух устройств, между которыми установлено соединение через OpenSSL.

Специалист Гвидо Вранкен считает, что эта уязвимость может быть опаснее Heartbleed, если она допускает удалённую эксплуатацию. Исследователь также упомянул ряд смягчающих факторов: можно использовать ветку OpenSSL 1.1.1 вместо v3ыы, брешь затрагивает только 64-битные системы с AVX512 и т. п.

К сожалению, разработчики пока не выпустили OpenSSL 3.0.5. Более того, в топике на GitHub один из членов команды OpenSSL Foundation Томас Мраз выразил мнение, что описанную проблему вообще нельзя называть уязвимостью.

«Не думаю, что это именно уязвимость. Больше похоже просто на серьёзный баг, из-за которого версия 3.0.4 работает нестабильно на AVX512-устройствах», — объясняет Мраз.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Crosstech представила решение для защиты контейнерных сред

Компания Crosstech Solutions Group выпустила новый продукт в сфере кибербезопасности — Crosstech Container Security (CTCS). Система предназначена для защиты контейнерной инфраструктуры — как в Kubernetes-кластерах, так и на отдельных хостах.

Решение охватывает весь жизненный цикл работы с контейнерами: от анализа образов до мониторинга поведения в runtime-среде. Например, CTCS позволяет:

  • проверять образы контейнеров на наличие уязвимостей, ошибочных настроек и «зашитых» секретов;
  • контролировать попытки запуска контейнеров и применять собственные политики — можно блокировать действия или просто получать уведомления;
  • отслеживать поведение контейнеров в реальном времени и реагировать на подозрительную активность;
  • сканировать файловые системы нод в кластере и выявлять потенциально опасные конфигурации;
  • проверять настройки Kubernetes на соответствие отраслевым стандартам (например, CIS Benchmarks).

Система поддерживает интеграцию с Keycloak, LDAP/LDAPS, Syslog и Docker Registry (API v2). Работает по принципу одностороннего соединения: инициатива всегда идёт со стороны основного ядра — к агентам, установленным на защищаемых кластерах. Есть открытое API, а установка происходит с помощью Helm-чартов.

CTCS можно использовать не только в Kubernetes, но и на хостах без оркестрации — за счёт standalone-агента. Решение подходит как для классических ИТ-сред, так и для сложных инфраструктур с высоким уровнем требований к безопасности.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

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