Брешь в Phoenix SecureCore угрожает сотням тысяч Intel-компьютеров

Брешь в Phoenix SecureCore угрожает сотням тысяч Intel-компьютеров

Брешь в Phoenix SecureCore угрожает сотням тысяч Intel-компьютеров

В UEFI-прошивке Phoenix SecureCore выявили новую уязвимость — UEFICANHAZBUFFEROVERFLOW, затрагивающую множество компьютеров на процессорах от Intel и позволяющую выполнить вредоносный код на устройстве.

Брешь, получившая идентификатор CVE-2024-0762, представляет собой возможность переполнения буфера в конфигурации чипа Trusted Platform Module (TPM).

Сначала специалисты компании Eclypsium заявили, что UEFICANHAZBUFFEROVERFLOW актуальна для устройств Lenovo ThinkPad X1 Carbon 7th Gen и X1 Yoga 4th Gen.

Чуть позже выяснилось, что баг затрагивает прошивку SecureCore, которая используется в следующих линейках процессоров: Alder Lake, Coffee Lake, Comet Lake, Ice Lake, Jasper Lake, Kaby Lake, Meteor Lake, Raptor Lake, Rocket Lake и Tiger Lake Intel.

Другими словами, уязвимость потенциально опасна для сотен тысяч компьютеров от Lenovo, Dell, Acer и HP.

UEFI-прошивка считается защищённой, поскольку она располагает функциональностью Secure Boot, которую поддерживают все современные операционные системы (Windows, Linux и macOS).

Задача Secure Boot — убедиться в том, что компьютер запускается исключительно с проверенными драйверами и легитимным софтом.

Баги в прошивке — подарок для киберпреступников, так как с их помощью можно установить буткиты, от которых крайне сложно избавиться. Среди таких вредоносов можно вспомнить BlackLotus, CosmicStrand и MosaicAggressor.

Phoenix выпустила официальное уведомление в отношении CVE-2024-0762, а техногигант Lenovo уже выпустил новую версию прошивки.

Подпишитесь на новости

Orion soft добавил аварийное восстановление в StarVault 1.6

Orion soft обновил систему управления секретами StarVault до версии 1.6. Главное нововведение — Disaster Recovery: данные реплицируются в реальном времени на резервный кластер, который можно задействовать при аварии. Резерв работает в режиме warm standby — подготовлен к переключению и получает изменения с основного кластера.

Если основной кластер выходит из строя, администратор переводит резервный в статус основного через соответствующие API-эндпоинты.

Секреты, конфигурации и права доступа сохраняются: собирать настройки заново в разгар аварии не потребуется.

По заявлению компании, механизм позволяет минимизировать время восстановления (RTO) и риск потери актуальных данных (RPO). Конкретные значения этих показателей в анонсе не приведены. Балансировку и автоматизацию переключения заказчики настраивают самостоятельно под свои регламенты.

Для хранилища секретов такой резерв особенно важен. Когда оно недоступно, сервисы могут потерять возможность аутентифицироваться, а восстановление остальной инфраструктуры — упереться в отсутствие необходимых учётных данных. Получается неприятный замкнутый круг: чтобы поднять системы, сначала нужно вернуть доступ к секретам.

Как объясняет лидер экосистемных продуктов zVirt Алишер Камалов, DR помогает снизить риск превращения централизованного хранилища в единую точку отказа. StarVault 1.6 даёт инструменты для этого сценария, а рабочую схему аварийного восстановления компании выстраивают на их основе.

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