Баг обновления Windows 10 v1903 — чрезмерное использование ресурсов CPU

Баг обновления Windows 10 v1903 — чрезмерное использование ресурсов CPU

Баг обновления Windows 10 v1903 — чрезмерное использование ресурсов CPU

После установки обновления KB4512941, вышедшего для версий Windows 10 v1903 на прошлой неделе, некоторые пользователи отметили нетипично высокое и скачкообразное использование ресурсов CPU процессом SearchUI.exe. Этот процесс принадлежит голосовому помощнику Cortana.

Оказалось, что в этом обновлении Cortana содержит баг — если пользователь отключает отправку поисковых запросов Bing (через реестр или групповые политики), голосовой ассистент начинает потреблять неприемлемо большие объемы мощности процессора. Этот же баг приводит к отображению пустых поисковых результатов Windows Search.

Один из пользователей на площадке Reddit поделился скриншотом, на котором видно, что Cortana «съела» 40% ресурсов центрального процессора.

У пользователей есть три способа решения этой проблемы. Во-первых, можно включить BingSearch, во-вторых — заменить директорию с кешем Cortana на старую версию, и последнее — деинсталлировать обновление.

Несмотря на то, что обновления Windows 10 приносили немало проблем, они все же устраняют приличное количество уязвимостей и багов. Именно поэтому не рекомендуется удалять KB4512941, если только в этом нет крайней необходимости.

Есть более гибкий способ решить эту проблему: включите BingSearch лишь временно, пока актуален баг использования ресурсов CPU. Для этого установите значение BingSearchEnabled на 1 в ключе реестра HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Search.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Search]
"BingSearchEnabled" = 1

Один из исследователей также предложил заменить папку с кешем по адресу C:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy\cache\ на прошлую версию, которая хранится в C:\Windows.old.

Представители Microsoft пока не признали наличие каких-либо проблем с этим обновлением.

«В настоящее время Microsoft не располагает информацией в отношении проблем, связанных с этим обновлением», — заявили в корпорации.

Популярную ИИ-библиотеку LiteLLM заразили бэкдором через PyPI

В экосистеме ИИ-разработки всплыла неприятная история: исследователи из Endor Labs обнаружили, что популярная Python-библиотека LiteLLM, у которой больше 95 млн загрузок в месяц, была скомпрометирована в репозитории PyPI. Через заражённые версии злоумышленники распространяли многоступенчатый бэкдор.

Речь идёт о версиях 1.82.7 и 1.82.8. Причём в официальном GitHub-репозитории проекта такого вредоносного кода не было.

Проблема возникла именно в пакетах, опубликованных в PyPI: туда попал файл с закладкой, который декодировал и запускал скрытую нагрузку сразу после импорта библиотеки.

Во второй заражённой версии, 1.82.8, схема стала ещё жёстче. Пакет устанавливал .pth-файл в директорию site-packages, из-за чего вредоносный код мог запускаться вообще при любом старте Python, даже если сам LiteLLM никто не импортировал.

После запуска зловред начинал искать самое ценное: SSH-ключи, токены AWS, GCP и Azure, секреты Kubernetes, криптокошельки и другие конфиденциальные данные. Если заражение происходило в контейнерной или кластерной среде, вредонос пытался двигаться дальше по инфраструктуре, в том числе через развёртывание привилегированных подов на узлах Kubernetes.

Для закрепления на хосте атакующие, как сообщается, ставили systemd-бэкдор sysmon.service, который регулярно связывался с командным сервером и мог получать новые команды или дополнительные вредоносные модули.

Специалисты считают, что за атакой стоит группировка TeamPCP, которая в последнее время явно разошлась: до этого её уже замечали в инцидентах, затронувших GitHub Actions, Docker Hub, npm и OpenVSX.

Украденные данные, по информации исследователей, шифровались и отправлялись на сервер атакующих. Для маскировки использовались домены, внешне похожие на легитимные, например models.litellm[.]cloud и checkmarx[.]zone.

Сейчас разработчикам и DevOps-командам советуют как можно быстрее проверить окружение. Последней известной чистой версией LiteLLM считается 1.82.6. Если в системе использовались 1.82.7 или 1.82.8, нужно проверить наличие файла litellm_init.pth, артефактов вроде ~/.config/sysmon/sysmon.py и сервиса sysmon.service.

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