Дефект чипов AMD используют для выживающего после переустановки ОС вируса

AMD уверяет, что хакерам непросто воспользоваться уязвимостью. Исследователи с этим не согласны.

Исследователи безопасности обнаружили тревожную ошибку в процессорах AMD, которой можно воспользоваться для установки вредоносного ПО. Его трудно обнаружить, и оно способно выживать после переустановки операционной системы.

Уязвимость касается режима работы в чипах AMD, называемого «Режим управления системой». Он предназначен для выполнения общесистемных функций, таких как управление питанием и аппаратного обеспечения. Этот же режим содержит высокие привилегии, которые исследовали в компании IOActive, занимающейся кибербезопасностью.

Согласно результатам проверки, так называемая уязвимость «Sinkclose» позволяет злоумышленнику получить системные привилегии глубоко в системе AMD, будь то ПК или сервер. Это может позволить хакеру устанавливать вредоносное ПО за пределы ОС и во встроенное ПО, что значительно затрудняет удаление вредоносного кода.

«Эта проблема на уровне кремния, похоже, оставалась незамеченной почти два десятилетия», - сообщили исследователи.

В понедельник, 12 августа, компания AMD начала выпускать исправления против Sinkclose для процессоров AMD Ryzen и Epyc, предупреждая при этом, что уязвимость имеет «высокий уровень серьезности». Поставщикам материнских плат и, возможно, Microsoft потребуется время, чтобы помочь распространить исправление среди пользователей.

Тем не менее, AMD уверяет, что этот недостаток нелегко использовать. Ошибка связана с манипулированием малоизвестной функцией в чипах AMD, известной как TClose. Sinkclose может быть внедрен только в том случае, если хакер уже имеет доступ к компьютеру с правами на вмешательство в ядро операционной системы.

«Хотя для использования Sinkclose требуется доступ к компьютеру на уровне ядра, такие уязвимости обнаруживаются в Windows и Linux практически каждый месяц. Этим могут управлять элитные хакеры-шпионы, спонсируемые государствами», – предупредили исследователи.

вопрос 1 из 10

Как ты проводишь тестирование?

А) Пробегаюсь по основным функциям — если работает, значит, всё норм!

Б) Следую чек-листам и проверяю каждый пункт. Ну, почти каждый.

В) Делаю полный анализ всего и ещё немного — даже у теста будут тесты.

Далее

вопрос 1 из 10

Как ты реагируешь, когда находишь баг?

А) «Эээ, это точно не моя проблема, так что дальше тестирую!»

Б) Сразу пишу в баг-трекер с комментарием, что разработчики опять налажали.

В) Праздную маленькую победу: нашёл ещё одну ошибку и спас человечество!

Далее

вопрос 1 из 10

Продукт вот-вот выходит в релиз, и времени на тесты почти нет. Что ты делаешь?

А) «Авось пронесёт!» — быстро пробегусь по основному сценарию и всё.

Б) Перепроверяю самые важные части, а мелочи — на потом.

В) Работаю, как супергерой: успеваю всё и даже больше, ведь я — последняя линия защиты!

Далее

вопрос 1 из 10

Что ты делаешь, если прод упал из-за бага?

А) Молча притворяюсь, что вообще не при делах, и тихо ухожу из чата.

Б) Возмущаюсь и кидаю ссылку на тикет: «Я же говорил, что это важно!»

В) Сразу беру вину на себя, чтобы показать, что баг-охотники всегда бдительны.

Далее

вопрос 1 из 10

Тебе нужно протестировать новую фичу, но документации по ней нет. Что будешь делать?

А) «На глазок сойдёт» — протестирую, как сам понял.

Б) Начну задавать кучу вопросов разработчикам, пока не выбью из них правду.

В) Пройду весь продукт вдоль и поперёк, даже если придётся писать документацию самому.

Далее

вопрос 1 из 10

Как ты относишься к автоматизированным тестам?

А) Зачем? Я и вручную справлюсь, если вдруг найду время.

Б) Вроде полезная штука, но пусть это лучше автоматизаторы делают.

В) Обожаю их! Настрою так, чтобы баги даже близко не подбирались.

Далее

вопрос 1 из 10

Когда коллеги просят протестировать их код, ты...

А) Пропускаешь это мимо ушей, пока кто-то другой не займётся.

Б) Соглашаешься, но проверяешь поверхностно, чтобы не увязнуть надолго.

В) Провожу настоящий краш-тест, чтобы коллеги потом сказали: «Ну ты и зануда!»

Далее