Небезпечний код в Cursor: що робити користувачам?

Cursor — це форк Visual Studio Code з глибокою інтеграцією GPT-4, Claude та інших LLM. Його використовують мільйони фахівців, щоб писати, пояснювати та рефакторити код.

Вчора, 10 вересня, дослідники з Oasis Security повідомили про баг: Cursor автоматично виконує код із tasks.json, щойно ти відкриваєш проєкт. Йдеться про потенційно шкідливі скрипти, які можуть потрапити у твоє середовище з чужих .vscode директорій.

Як працює баг і чому він небезпечний?

У VS Code існує функція Workspace Trust, яка блокує автоматичне виконання завдань у нових або сторонніх проєктах, доки користувач не підтвердить дозвіл. Це захист від потенційно шкідливих .vscode/tasks.json, які можуть містити небезпечні shell-команди.

У Cursor функції Workspace Trust (!) немає. Через це будь-який файл tasks.json у відкритому репозиторії виконується автоматично, щойно ти відкриваєш репозиторій. І не важливо, чи планував ти запускати ці таски, чи просто переглядав код.

Це створює три основні ризики:

1. Викрадення конфіденційних даних. Токенів, ключів API та налаштувань середовища.
2. Небажані зміни файлів. Скрипт може модифікувати твої проєкти без твоєї згоди.
3. Вхід у ланцюг атак. Підключення до командного сервера (C2) або створення вектора для supply chain-атаки.

Oasis Security навіть опублікували Proof-of-Concept, де .json файл просто відправляє ім’я користувача через shell-команду. Здавалося б нешкідливо — але це лише приклад. Насправді там може бути будь-яка шкідлива команда.

Вигляд коду tasks.json

Що робити користувачам? 

Після повідомлення про баг команда Cursor вирішила залишити автозапуск tasks.json. Мовляв, увімкнення Workspace Trust обмежує можливості функцій ШІ, які є ключовими фічами. В Cursor прокоментували:

Workspace Trust вимикає штучний інтелект та інші функції, які наші користувачі хочуть використовувати в продукті

Щоб не ставати випадковою жертвою, експерти з Oasis Security радять:

1. Увімкнути Workspace Trust вручну в налаштуваннях Cursor
2. Перевіряти .vscode перед відкриттям чужих репозиторіїв
3. Не зберігати чутливі ключі та токени у глобальних конфігураціях shell
4. Використовувати простий текстовий редактор для підозрілих проєктів, якщо є сумніви щодо безпеки

Післяслово

Рекомендуємо стежити за нашим Телеграм-каналом. Там ми висвітлюємо останні релізи, гайди, огляди та статті на тему DevOps, а також подібні новини для твоєї безпечної роботи.

До зустрічі!