КИБЕРБЕЗОПАСНОСТЬ

Microsoft закрывает баг в Surface, превращавший ноутбук в «кирпич»

Microsoft 90 дней тихо выпускала патчи для Surface после бага, который одним пакетом мог вывести устройство из строя при отключённом Secure Boot.

✍️ Редакция iTech News | 13.06.2026 | ⏱ 5 мин | Источник: The Register
🔐

Microsoft в течение 90 дней тихо выпускала исправления для Surface после истории, которая звучит как плохая шутка про ИИ, но оказалась вполне реальной инженерной проблемой. Уязвимость Surface позволяла вывести устройство из строя фактически одним пакетом команд, если на машине были отключены Secure Core и Secure Boot, а для русскоязычной IT-аудитории это еще один сигнал: эксперименты с низкоуровневым железом, кастомными драйверами и AI-ассистентами теперь могут ломать не только код, но и сам ноутбук.

О проблеме сообщает The Register со ссылкой на австралийского исследователя безопасности Джека Дарси. По его словам, баг вскрылся почти случайно: он попросил Microsoft Copilot помочь с настройкой подсветки экрана на Surface, а сгенерированный ассистентом Python-скрипт в процессе «разведки» отправил сырые SSAM ioctl-команды напрямую в контроллер SAM. Вместо полезного тюнинга Darсy получил нерабочий ноутбук: скрипт перезаписал прошивку embedded controller, а после перезагрузки устройство уже не смогло пройти POST. То есть речь не про синий экран и не про «переустановите Windows», а про сценарий, где не помогают ни USB-восстановление, ни сброс, ни доступ к BIOS/UEFI.

Технически история упирается в реализацию SAM/SSAM — встроенного контроллера Surface. Как описывает Дарси, в интерфейсе команд нет внятной защиты от произвольной записи, а безопасного способа «прощупать» шину тоже не предусмотрено. Copilot последовательно создал и выполнил четыре все более агрессивных Python-скрипта, пытаясь найти значения для управления подсветкой. В одном из сценариев код перебирал пары Target Category и Command ID, отправляя пустые или нулевые payload в команды записи. На практике это приводило к тому, что одни вызовы шли как SET Feature Report с пустой нагрузкой, другие — как Output Report с пустой нагрузкой, а часть команд записывала мусор в чувствительные области. Самая неприятная деталь в том, что повреждение проявлялось не мгновенно: пока SAM уже инициализирован и работает в RAM, ноутбук может выглядеть живым. Но после перезагрузки контроллер пытается перечитать поврежденные данные из постоянной памяти и больше не поднимается.

Microsoft публично не драматизирует ситуацию. В комментарии The Register компания заявила, что не считает баг практичным вектором атаки: для эксплуатации нужны права администратора, взаимодействие со специфическими драйверами и отключенный Secure Boot. Формально аргумент понятный. Если злоумышленник уже получил admin-доступ и пользователь сам ослабил защиту платформы, у него и без того длинный список неприятных действий. Но у истории есть важная поправка: здесь речь не столько о классической удаленной атаке, сколько о дефекте архитектуры, при котором низкоуровневый интерфейс допускает разрушительные операции без дополнительных аппаратных предохранителей. Во многих устройствах для такого уровня доступа нужен физический жест вроде удержания кнопки или перемычки на плате. В Surface, если верить исследователю, этой страховки не было.

Отдельный нюанс — затронуты прежде всего не «управляемые» корпоративные машины, а устройства пользователей, которые любят жить чуть ближе к железу. Microsoft утверждает, что managed devices риску не подвержены, а обновления уже выпущены для большинства затронутых моделей или придут в ближайшие недели через Windows Update. При этом компания не присвоила проблеме CVE и описывает ее как deprecated UEFI interface, способный вызвать boot loop на части устройств. Из текста The Register следует, что в зоне риска могли оказаться разные поколения Surface Laptop и Surface Book, тогда как Surface Go, по наблюдениям Дарси, скорее всего не задеты; ARM-варианты при этом не тестировались. Полного официального списка моделей в публикации нет, и это, пожалуй, главный практический пробел для тех, кто поддерживает парк таких машин вне стандартной корпоративной политики.

Для разработчиков и DevOps-инженеров в этой истории сразу несколько неприятных выводов. Во-первых, генеративный помощник, который умеет писать код и тут же его запускать, легко перескакивает из категории «ускоритель рутины» в категорию «автоматизированный способ испортить дорогое устройство». Copilot здесь не «атаковал» систему намеренно; он просто механически исследовал плохо спроектированный интерфейс без понимания, где чтение, а где запись. Во-вторых, опасность оказалась встроена в саму структуру команд: по словам Дарси, идентификаторы чтения и записи перемешаны так, что безопасного диапазона для перебора нет. Если бы read-команды и write-команды были разделены хотя бы по диапазонам, скрипт можно было бы ограничить простым bounds check. Но когда destructive operations спрятаны в том же пространстве идентификаторов, что и безобидные запросы, любой «сканер возможностей» превращается в русскую рулетку.

Для бизнеса вывод еще прозаичнее: отключение Secure Boot ради совместимости, игр, Linux или нестандартных драйверов перестает быть «личным выбором продвинутого пользователя» и становится полноценным операционным риском. В корпоративной среде такие исключения обычно живут годами: один инженер просил для тестов, другой для dual boot, третий для старого драйвера, а потом это превращается в парк устройств с неочевидным профилем угроз. На этом фоне Microsoft, похоже, делает выводы не только точечным патчем. The Register пишет, что компания переводит стек Surface на Rust и уже работает над более защищенной архитектурой будущих Surface for Business, включая embedded controller firmware и переписывание частей UEFI. На фоне череды разговоров о memory safety это выглядит не модным жестом, а довольно земным признанием: когда ошибка в низком уровне может убить устройство, цена старых интерфейсных решений становится слишком высокой.

Главный вопрос теперь не в том, сумела ли Microsoft закрыть конкретную уязвимость Surface на большинстве устройств, а в том, сколько еще аппаратных интерфейсов в потребительских и корпоративных ПК проектировались из расчета на «осторожного инженера», а не на эпоху, где код генерирует ИИ и тут же идет щупать шину вслепую. Если такие инструменты становятся частью повседневной работы, производителям придется считать безопасным не только злонамеренного атакующего, но и слишком исполнительного помощника с правами администратора.

Поделиться: Telegram X LinkedIn