Windows Backup получит функцию переноса данных на новый компьютер

Windows Backup получит функцию переноса данных на новый компьютер

Windows Backup получит функцию переноса данных на новый компьютер

Переход на Windows 11 — дело не всегда добровольное: Microsoft активно подталкивает пользователей Windows 10 к апгрейду. Проблема в том, что далеко не все старые компьютеры соответствуют строгим требованиям новой системы.

В тестовом обновлении KB5061087 для Windows 10 появилась новая версия Windows Backup.

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

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

Как это должно работать

Судя по описанию, процесс переноса будет напоминать сопряжение по Bluetooth. Старый компьютер показывает код, вы вводите его на новом — и начинается миграция. Простая и понятная механика, но вот что именно можно будет перенести, пока остаётся загадкой.

Сейчас известно лишь одно: Windows Backup, скорее всего, не сможет перенести всё целиком. По аналогии с предыдущими версиями, речь идёт о системных настройках, личных файлах и, возможно, некоторых приложениях из Microsoft Store.

 

Где Windows пока отстаёт от Apple

В отличие от iPhone, где можно в пару кликов воссоздать старое устройство на новом, в экосистеме Windows полноценного переноса нет. Всё, что выходит за пределы базовой настройки — например, Win32-программы и их данные — по-прежнему требуют ручной установки и копирования.

Надежда на то, что однажды Microsoft научится переносить даже сторонние программы вместе с их окружением, пока выглядит утопично. А жаль — для пользователей это был бы реальный прорыв.

Microsoft явно движется в правильном направлении, но на практике новая функция ещё не готова. Остаётся ждать финального релиза и смотреть, действительно ли Windows Backup станет чем-то большим, чем просто архиватор папки «Документы».

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

Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Исследователь безопасности Дэвид Лидбитер обнаружил уязвимость в OpenSSH — CVE-2025-61984 — которая демонстрирует: даже мелкие особенности парсинга команд и поведения shell могут привести к удалённому выполнению кода.

Суть проблемы проста и неприятна: в OpenSSH (до версии 10.1) контрол-символы в именах пользователей, полученных из ненадёжных источников, могли не отфильтровываться.

Когда такое «имя» подставлялось в ProxyCommand (через переменную %r), OpenSSH формировал строку для exec, которую запускал через shell. Если в этой строке оказывались символы вроде $[ и символы новой строки, некоторые оболочки (например, bash) могли интерпретировать это так, что первая команда аварийно завершается, а затем выполняется то, что идёт после — то есть возможна инъекция команды.

Эксплуатация требует специфической связки: конфигурация, использующая ProxyCommand с %r, уязвимая оболочка и «входной» источник имени пользователя, который злоумышленник контролирует. Практический пример — злоумышленный .gitmodules, где в URL подставляют строку вроде:

[submodule "foo"]
  path = foo
  url = "$[+]\nsource poc.sh\n@foo.example.com:foo"

Если SSH-конфиг содержит строку вроде

ProxyCommand some-command %r@%h:%p

и вы запускаете git clone --recursive, то в подходящих условиях может выполниться source poc.sh — до установления самого соединения.

Важно понимать: условия для успешной атаки нишевые, но реальны — инструментальная цепочка Git → SSH → shell и автоматизация (CI/CD) дают атакующему много точек входа. Проблема усугубляется тем, что OpenSSH фильтровал многие метасимволы, но пропустил $ и [ — и это создало неожиданный вектор.

Исправление уже включено в OpenSSH 10.1: разработчики начали проверять и запрещать управляющие символы в именах пользователей через iscntrl() в ssh.c. То есть долгосрочное решение — обновиться до 10.1 или новее.

Если обновиться сразу нельзя, Лидбитер предлагает два практических временных шага. Во-первых, брать имя пользователя в одинарные кавычки в ProxyCommand, чтобы предотвратить подстановку:

ProxyCommand some-command '%r@%h:%p'

(Обратите внимание: одинарные кавычки нужны именно потому, что двойные не защитят от $[ — оболочка всё ещё будет их обрабатывать.) Во-вторых, по умолчанию отключить SSH-подмодули в Git и не позволять автоматические URL-хендлеры, которые могут передавать непроверенные SSH-команды:

git config --global protocol.ssh.allow user

Главный вывод — не полагаться на то, что «маленький» символ или строка не принесут беды: при передаче входа от ненадёжных источников через несколько инструментов даже неочевидная каверза в парсинге может стать критической. Рекомендуется как можно скорее обновить OpenSSH или применить временные защитные меры в конфигурациях ProxyCommand и политиках Git.

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

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