Легко взламываемые модели ИИ показывают, что меры защиты не работают

Легко взламываемые модели ИИ показывают, что меры защиты не работают

Легко взламываемые модели ИИ показывают, что меры защиты не работают

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

Четыре общедоступные большие языковые модели (Large Language Models, LLM) чрезвычайно уязвимы для «джейлбрейка» — эксплуатации багов, позволяющей заставить модели ИИ выполнять то, что разработчики им делать запретили.

LLM тщательно настраиваются для безопасного публичного пользования. Их обучают избегать вредных реакци1 и токсичных результатов, используя меры предосторожности.

Однако исследователи обнаружили возможность обойти защиту с помощью простых атак.

В качестве наглядного образца можно привести инструкцию для пользователя, согласно которой система должна начинать свой ответ со слов, которые предполагают выполнение вредоносного запроса, например: «Конечно, я рад помочь».

Специалисты использовали подсказки в соответствии с отраслевым стандартом контрольного тестирования. В ходе исследования специалисты обнаружили, что некоторым моделям ИИ даже не требовался джейлбрейк, чтобы выдать нестандартный ответ. 

А вот когда использовался джейлбрейк, каждая модель отвечала как минимум один раз из пяти попыток. Три модели в 100% случаев давали ответы на вводящие в заблуждение запросы.

Анализ протестированных моделей показал, что они остаются уязвимы для базовых джейлбрейков, а некоторые LLM выдают вредные результаты без каких-либо попыток обойти защиту. Какие именно модели были исследованы, специалисты не сообщили.

В институте также оценили возможности моделей ИИ выполнять определенные задачи для проведения основных методов кибератак. Несколько LLM смогли решить задачи, которые исследователи назвали «хакерскими на уровне средней школы», но немногие смогли выполнить более сложные действия «университетского уровня».

Проводник Windows падал не из-за Microsoft, виноват оказался деинсталлятор

Инженер Microsoft Рэймонд Чен рассказал любопытную историю отладки загадочных падений Проводника. Сначала всё выглядело так, будто в Windows внезапно появился неприятный баг. Но виновником оказалась вовсе не Microsoft, а сторонний деинсталлятор.

Проблема проявилась как резкий всплеск сбоев Проводника. Инженеры начали изучать дампы и заметили странную деталь: падала 32-битная версия программы, запущенная на 64-битных системах Windows.

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

Дальше выяснилось, что деинсталлятор некорректно работал с системными API: использовал неправильное соглашение о вызовах функций и неверно обрабатывал параметры стека. Из-за этого при каждой неудачной операции данные из стека удалялись неправильно.

Поскольку процесс повторялся в цикле, повреждение памяти постепенно накапливалось. В какой-то момент указатель стека уезжал в область активного кода, и Проводник падал.

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

Чен напомнил важную вещь: в экосистеме Windows с миллиардами устройств и огромным количеством приложений далеко не каждый сбой компонента Microsoft означает баг в Windows. Сторонние программы тоже могут ломать системные процессы, особенно если неправильно используют низкоуровневые API.

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