Microsoft молча отказалась от блокировки макросов в Office по умолчанию

Microsoft молча отказалась от блокировки макросов в Office по умолчанию

Microsoft молча отказалась от блокировки макросов в Office по умолчанию

Microsoft без объяснения причин отказалась от идеи блокировать сторонние макросы в Office по умолчанию. Использование макросов — популярный метод среди киберпреступников, поэтому вдвойне интересно узнать, почему корпорация изменила своё мнение.

В посте Microsoft, который датируется февралём 2022 года, специалисты компании объясняли, насколько мощными могут быть вредоносные макросы, написанные на Visual Basic for Applications. С их помощью злоумышленники загружают пейлоады на компьютеры пользователей.

Причём это довольно старый метод; достаточно вспомнить хотя бы зловред Melissa, который в 1999 году распространялся с помощью макросов в документе Word. За эти годы проблема только усугубилась, поэтому Microsoft в 2016 году выпустила инструмент, позволяющий системным администраторам чётко определять, когда и где макросы могут запускаться.

Microsoft также пересмотрела сам принцип работы макросов: теперь система спрашивает пользователя, действительно ли он хочет запустить такой элемент. Тем не менее это не остановило киберпреступников, поэтому в феврале 2022 года техногигант рассказал о дополнительных мерах: макросы должны быть заблокированы по умолчанию в Access, Excel, PowerPoint, Visio и Word.

Теперь Microsoft, судя по всему, изменила свои планы. Один из комментариев от некоего Винса Хардвика говорит о том, что функцию блокировки макросов по умолчанию убрали из текущей версии Office.

Позже Анджела Робертсон, работающая в штате корпорации из Редмонда, отметила следующее:

«Исходя из обратной связи, которую мы получили, функция была отозвана. Приношу извинения за любые вызванные неудобства».

При этом Робертсон не уточнила, что это была за обратная связь, однако по другим комментариям и жалобам можно сделать вывод, что дефолтная блокировка макросов приводит к определённым проблемам с другой полезной функциональностью.

В ядре 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