Docker устранил в Docker Sandboxes несколько уязвимостей, связанных с обращением с учётными данными. Все сборки до 0.43.0 позволяли стороннему набору инструментов объявить себя тем же сервисом авторизации, что и встроенный агент. Токен доступа при этом выдавался без явного согласия пользователя. Риск затрагивает разработчиков и команды, которые запускают изолированные среды для работы с ИИ-агентами, репозиториями и внешними сервисами.
Детали уязвимости
Sandboxes - среда, в которой код и агенты выполняются отдельно от основной системы. Такая изоляция нужна, чтобы подозрительный репозиторий или сторонний модуль не добрался до файлов и секретов машины. Логика понятная, но она перестаёт работать, когда сама песочница неверно решает, кому доверять.
Главная уязвимость связана с OAuth - протоколом, по которому приложение получает доступ к чужому сервису от имени пользователя, не запрашивая пароль каждый раз. В Sandboxes встроенные агенты заранее зарегистрированы как доверенные клиенты OAuth. Сторонний набор мог повторно объявить тот же сервис и унаследовать это доверие. В итоге набору достался рабочий токен, хотя пользователь не подтверждал привязку учётных данных. Ограничение сняли: наследование доверия теперь невозможно, а согласие на привязку по умолчанию отклонено. Песочницы, созданные раньше, чинятся сами при перезапуске службы или добавлении набора. Вручную пересоздавать их не нужно.
Похожая проблема обнаружилась в прокси-сервере (посредник, через который песочница выходит во внешнюю сеть). Клиент мог подсунуть учётные данные, которые прокси не выдавал. Раньше такие значения уходили на хосты управляемых провайдеров, то есть чужие секреты могли попасть туда, где им не место. Обработку ужесточили, и теперь прокси не пропускает то, что не выпускал сам. Заодно удаление секрета немедленно отзывает его на прокси. Синхронизация учётных данных больше не переносит в песочницу то, что ей не настраивали.
Нескольких исправлений потребовала и работа с наборами из Git. Подписанные наборы теперь проверяются на каждом хосте, а содержимое берётся только из объектов коммита. Из-за этого фильтры, преобразование переводов строк, система хранения больших файлов и хуки Git не могут изменить выкачанные данные. Кэш тоже проверяют. Каждая выдача сверяется с построчным манифестом, и подделанная запись уходит в карантин вместо того, чтобы попасть в работу. Клонирование защитили от внедрения команд, которые злоумышленник мог протащить через переменные окружения Git.
Ещё одна уязвимость касалась выбора репозитория. Если на хосте были заданы переменные окружения Git, командная строка Sandboxes могла взять не тот репозиторий. Ошибка проявлялась при загрузке наборов или настройке рабочих пространств. Исправили и это. Соединения по SSH (защищённый доступ к командной строке) теперь остаются привязанными к исходной песочнице, а миграция идентификаторов не ломает уже созданные среды. В Windows одинаковые папки в сетевых путях распознаются корректно.
Проверка пользователя закрывает другой сценарий. Локальная служба теперь сверяет учётную запись операционной системы при подключении через Unix-сокеты и именованные каналы Windows. Без такой проверки любой локальный процесс мог обратиться к службе от чужого имени. Мера простая, но она отсекает целый класс атак, где злоумышленник уже получил доступ к машине и ищет способ расширить права.
Хватает в релизе и вещей, не связанных с безопасностью напрямую. Например, тайм-аут при входе в Docker Hub мог навсегда заблокировать службе доступ к учётной записи, и восстанавливать вход приходилось вручную. Теперь это исправлено. Разрешающие правила для конкретных IP-адресов снова работают после перехода на новую схему согласования: прокси перестал блокировать такие цели по умолчанию. Появился принудительный останов неактивных песочниц, минимальный объём памяти снижен до 512 МиБ, а имена сред проверяют на длину и недопустимые символы в конце.
Кого это касается на практике. Sandboxes - инструмент для тех, кто запускает агентов и чужой код на своей машине или в конвейере сборки. Именно там скапливаются токены к репозиториям, облачным сервисам и моделям. Ошибка в разграничении доверия между компонентами даёт доступ к этим токенам. Сведений об эксплуатации уязвимостей в реальных атаках Docker не приводит. Правда, и повода ждать её появления нет.
Исправления вошли в версию 0.43.0. Обновление обязательно для тех, кто работает со сторонними наборами и внешними сервисами авторизации. Отдельно нужно учесть несовместимость: секреты OAuth для серверов MCP (протокол, через который модели получают доступ к внешним инструментам и данным) переименованы. Значения, сохранённые под старыми именами, больше не читаются, их придётся задать заново. Согласие на привязку учётных данных теперь по умолчанию отклонено, поэтому при первом обращении к новому домену пользователь увидит запрос и должен подтвердить его вручную.
Сама по себе история показательна для класса изолированных сред. Чем больше в них встроенных посредников - прокси, агентов, наборов, - тем важнее, чтобы доверие между ними подтверждалось явно, а не наследовалось. Docker в этом релизе закрыл именно такие места, и это заметнее, чем длинный список мелких улучшений.
Ссылки
