ИИ-помощник Windows Recall теперь opt-in и включается через Hello

ИИ-помощник Windows Recall теперь opt-in и включается через Hello

ИИ-помощник Windows Recall теперь opt-in и включается через Hello

Разработчики Microsoft полностью перестроили систему безопасности Windows Recall. ИИ-ассистент теперь работает с данными в изолированной среде, по умолчанию неактивен и при включении требует аутентификации через Windows Hello.

Подтверждать физическое присутствие с помощью Windows Hello придется также при изменении настроек Windows Recall или получении доступа к UI. По желанию в ОС можно выставить постоянный запрет на включение ИИ-функций.

Все операции над скриншотами отныне выполняются в безопасной секции памяти — анклавах VBS (Virtualization-Based Security). Для сегментации используется такой же гипервизор, что и в Azure; по завершении сессии или превышении лимита времени все данные из памяти удаляются.

Вносимые в базу Recall снимки экрана и сопутствующая информация всегда шифруются ключами, хранимыми в TPM. Эти данные недоступны другим пользователям ОС; их можно удалять, ставить функцию скриншотов на паузу или временно отключать. Юзер может также ограничить срок хранения контента Recall и выделенное пространство на диске.

Усилена защита от утечек конфиденциальных данных (паролей, номеров удостоверений личности, номеров банковских карт). Умный помощник теперь автоматом отфильтровывает их с помощью фоновых DLP-функций, позаимствованных у Microsoft Purview, и откатывает сохранение.

Защититься от вредоносов и несанкционированного доступа Recall помогают ограничение скорости передачи данных и противодействие атакам перебором.

 

Нововведения призваны развеять опасения в отношении безопасности и приватности, которые породила способность ИИ-ассистента почти ежесекундно фиксировать действия пользователя и хранить результаты локально. Из-за волны недоверия и критики Microsoft пришлось отложить выпуск тестовых версий Windows Recall — по последним данным, до октября.

В ядре Linux нашли первую уязвимость в коде на Rust

В ядре Linux зафиксировали первую уязвимость (CVE), связанную с кодом на Rust. Об этом сообщил один из ключевых разработчиков ядра Грег Кроа-Хартман, а подробности появились в рассылке Linux. Речь идёт о проблеме под идентификатором CVE-2025-68260, которая затрагивает переписанный на Rust драйвер Android Binder.

Проблема, согласно публикации Phoronix, связана с состоянием гонки (race condition), возникающим из-за использования небезопасного Rust-кода. В определённых условиях это может привести к повреждению указателей в памяти и, как следствие, к сбою системы.

Уязвимость затрагивает версии ядра Linux 6.18 и новее, то есть те сборки, где появился Rust-драйвер Binder. Важно отметить, что речь идёт именно о потенциальном сбое в работе системы — удалённого выполнения кода или компрометации здесь нет.

Сам Грег Кроа-Хартман подчёркивает, что это первый подобный случай с момента появления Rust-кода в основном дереве ядра Linux. И хотя для кого-то новость может прозвучать тревожно, разработчики призывают не делать поспешных выводов: уязвимость не критическая, а сам факт её обнаружения — скорее показатель того, что Rust-код в ядре теперь проходит тот же путь зрелости, что и C-код десятилетиями ранее.

В сообществе также отмечают, что проблема возникла не «вопреки» Rust, а как раз из-за использования небезопасных участков, без которых в ядре пока не обойтись. Это лишний раз показывает, что Rust снижает класс рисков, но не отменяет необходимости аккуратного проектирования и ревью.

Подробности по CVE-2025-68260 уже опубликованы в официальной рассылке Linux CVE, а исправления, как ожидается, появятся в ближайших обновлениях ядра.

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