Microsoft устранила баг отказа LSASS и внезапной перезагрузки Windows 10

Microsoft устранила баг отказа LSASS и внезапной перезагрузки Windows 10

Microsoft устранила баг отказа LSASS и внезапной перезагрузки Windows 10

Microsoft наконец устранила проблему с отказом LSASS, критического компонента операционной системы Windows. Этот баг приводил к вынужденной перезагрузке ОС, поскольку системный файл lsass.exe не мог нормально работать после обновления отдельных версий Windows 10.

LSASS (служба проверки подлинности локальной системы безопасности) отвечает в Windows за верификацию пользователей компьютера или сервера, за обработку изменений пароля, а также создаёт токены доступа. Все действия LSASS записывает в специальный лог.

Если процесс этой службы перестаёт отвечать, пользователь сразу же теряет доступ к зарегистрированным на компьютере учётным записям Windows. При этом ОС выдаст соответствующую ошибку, а устройство должно будет перезагрузиться в течение минуты.

Именно с такой проблемой столкнулись в июне пользователи Windows 10. С выходом обновления под идентификатором KB4565503 Microsoft устранила сбои в работе LSASS. Помимо этого, патч повышает производительность WIndows 10 версии 2004.

 

Известно, что баг LSASS коснулся многих версий (как клиентских, так и серверных):

  • Клиентские: Windows 10 2004; Windows 10 1909; Windows 10 1903; Windows 10 1809; Windows 10 Enterprise LTSC 2019.
  • Серверные: Windows Server 2004; Windows Server 1909; Windows Server 1903; Windows Server 1809; Windows Server 2019.

Claude освободил 700 ГБ, удалив домашнюю папку разработчика

Разработчик Себастьен Гиймо поручил ИИ-агенту Claude написать скрипт для очистки временных файлов. Бот справился слишком эффективно: удалил домашний каталог пользователя вместе с 700 ГБ данных и результатами недельной работы, но предусмотрительно оставил папку /tmp, ради которой всё и затевалось.

Гиймо регулярно запускает ИИ-агентов, которые оставляют после себя множество временных файлов.

Он попросил модель Claude Fable создать отдельную песочницу для каждого агента в /tmp и очищать её после завершения работы, не затрагивая используемые данные.

Первая версия скрипта показалась разработчику слишком сложной. Из-за наличия команд безвозвратного удаления Claude запустил дополнительную проверку безопасности. Система Anthropic сочла задачу рискованной и автоматически понизила модель сначала до Opus 5, а затем до Opus 4.8.


Новая модель написала тест, который сравнивал цели удаления с /tmp и домашним каталогом пользователя. Обе директории были правильно признаны опасными. А затем начался этап очистки тестовых данных, и Claude повторно использовал ту же переменную, в которой находился путь к домашней папке.

Гиймо остановил процесс, но слишком поздно: агент успел удалить 700 ГБ. Большую часть информации разработчик восстановил из Git, конфигурации Nix, журналов сессий и других источников. Однако недельная работа всё же пострадала.

Разработчик предполагает, что автоматический переход на менее сильную модель мог повысить риск ошибки. Более производительная Fable 5, возможно, заметила бы конфликт переменных.

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