Hacker News Digest

В Omarchy до версии 4.0.1 по умолчанию пользователь входил в группу docker, что позволяло любому процессу в его сессии получать root-привилегии через доступ к сокету Docker. Docker-демон работает от root и слушает /var/run/docker.sock; члены группы docker могут взаимодействовать с этим сокетом, запуская контейнеры с монтированием хост-файловой системы и выполняя код от имени root. Это означало, что даже обычные приложения — браузеры, редакторы, IDE, npm-скрипты или AI-агенты — могли быть использованы для полного захвата системы без пароля или sudo. Проблема была усугублена тем, что настройка была opt-out, а документация вводила в заблуждение, подразумевая rootless-режим, хотя на самом деле предоставляла полный доступ к root. Эксплойт демонстрировался чтением /etc/shadow через docker run -v /:/hostroot. Исправление выпущено в версии 4.0.1; пользователям рекомендуется обновиться немедленно. Для тех, кто хочет избежать root-доступа при работе с контейнерами, предлагается использовать Podman — daemonless-альтернативу, работающую в пользовательских неймспейсах без привилегий.

Тред расширяет статью в нескольких направлениях: ставит под сомнение практическую значимость LPE через docker-группу на десктопе, указывает на давно документированный риск docker-сокета и существование rootless-альтернатив (Podman, rootless Docker), сообщает о других конкретных проблемах Omarchy (vibecoded-установщики, USB-дескрипторы в shell, win11-скрипт с plain-text паролями, неаудированные плагины), и фиксирует защиту как минимум одним пользователем с годовым опытом — частично подтверждая позицию лагеря, что вопрос не столько в Omarchy, сколько в культуре дефолтов десктопных дистрибутивов.

• Совет: @lrvick: любое приложение от имени пользователя способно перехватить пароль sudo через подмену функции в ~/.bashrc и exfiltration, поэтому sudo на десктопе — театр безопасности независимо от docker-эскалации.

• Спор: @mike_hearn утверждает, что root на Linux-десктопе мало что значит, так как пользовательский код уже контролирует ~/.bin, PATH и терминал: «If you run code as yourself on Linux it owns you». Оппоненты (@pibaker, @hashstring, @pkulak) считают, что дефолтное членство в docker-группе — это явное игнорирование документации Docker и Podman по работе rootless.

• Совет: @WhyNotHugo: rootless Docker стабилен уже более 4 лет, и он сам упаковывал его в AUR — использование rootful-демона на пользовательском десктопе необоснованно.

• Несколько участников (@kodoman, @exitb, @po1nt, @arjie) указывают, что docker-группа с rootful-сокетом — широко распространённая практика по всей экосистеме, и проблема не уникальна для Omarchy; статья лишь подсветила общий антипаттерн десктопов.

• @darkwi11ow, @SamInTheShell, @arjie и @WhyNotHugo: Podman / rootless Docker — стандарт в 2026 и поставляются rootless из коробки; @SamInTheShell по опыту отмечает: «sudo pacman -S podman не принёс этих проблем из коробки и предполагал rootless по умолчанию».

• Совет: @concinds обращает внимание на предыдущий похожий баг (commit 9285b19d6a72) — USB-дескрипторы передавались прямо в shell — и на этом основании рекомендует избегать vibecoded-дистрибутивов в принципе.

• Совет: @ruby_curmudgeon: плагины на plugins.omarchy.org запускаются полностью несакседжированными и без аудита, что усиливает риск-профиль Omarchy за пределами дефолтного пользователя.

• Совет: @felixfurtak по опыту установки: скрипт win11-docker в Omarchy сохраняет логин и пароль Windows-VM в открытом виде в конфиге — второй конкретный security-инцидент помимо статьи.

• Совет: @teravor: на текущий момент нет ни одного Linux-дистрибутива, где безопасно запускать приложения «как есть», так как у них есть доступ к /home; практика — профили bubblewrap для каждого приложения.

• Часть критики (включая @hashstring, @concinds, @archole) фокусируется не на конкретном CVE, а на «vibecoded»-происхождении дистрибутива: по их мнению, это системная проблема зрелости, а не единичный баг.

• Совет: @andrewvc: после того как на машине хотя бы раз запускали vibe-coding, он перестаёт доверять системе в целом и использует полностью отдельный физический хост для LLM-агентов.

• Совет: @trentnix противопоставляет критике скорость фикса: docker-проблема была зарепорчена и быстро закрыта — по его мнению, «система сработала хорошо», а Omarchy — удобный путь попробовать hyprland и дать детям машину с агентным сопровождением.

• Несколько участников (@vinniepukh, @yoyohello13) указывают на исторический прецедент LARBS от Luke Smith 8–10 лет назад — цикл «controversial personality + WM install script» повторяется; @yoyohello13 в итоге вернулся на KDE после оптимизаций тайлинга.

• Совет: @PaulHoule: для десктопа «root» давно не самое ценное — важнее credentials к git-репозиторию, postgres, облачным API и keyring, поэтому LPE-через-docker сам по себе менее критичен, чем кажется из CVE-заголовка.

Исследователи безопасности обнаружили критическую уязвимость в системе Международной автомобильной федерации (FIA), позволившую получить несанкционированный доступ к персональным данным гонщиков Формулы-1. Через портал drivercategorisation.fia.com, используемый для присвоения гонщикам категорий, они смогли повысить свои привилегии до уровня администратора с помощью простого модифицированного HTTP PUT запроса, добавив параметр "roles" со значением "ADMIN".

Получив полный административный доступ, исследователи обнаружили возможность просмотра конфиденциальной информации, включая паспортные данные чемпиона Макса Ферстаппена и других гонщиков. Уязвимость существовала из-за отсутствия proper проверки прав при изменении параметров пользователя, что позволяло осуществить атаку повышения привилегий. Этот инцидент демонстрирует серьезные пробелы в кибербезопасности даже в таких престижных организациях, как FIA, отвечающей за один из самых технологичных видов спорта в мире.

• Сайт F1, который не смог защитить личные данные, был взломан, и это стало поводом для обсуждения, что компания, которая не может защитить данные, не должна быть доверена.
• Пользователи отметили, что сайт не только не защищает данные, но и не имеет bug bounty программы, что делает невозможным получить вознаграждение за найденные уязвимости.
• Некоторые участники обсуждения подчеркнули, что вместо того, чтобы устранять уязвимости, компания может начать угрожать исследователям, которые сообщают о проблеме.
• Было также отмечено, что вместо того, чтобы устранять уязвимости, компания может начать угрожать исследователям, которые сообщают о проблеме.

Уязвимость Copilot: доступ к файлам без записи в журнал аудита
Автор: Zack Korman, 19.08.2025

Суть проблемы

M365 Copilot может читать файлы и не фиксировать это в журнале аудита, если попросить «не давать ссылку на файл». Это позволяет скрытно скачивать данные, нарушая безопасность и требования к соответствию.

Как обнаружил

Исследуя логику аудита для новой функции Pistachio, автор заметил пропуски в журнале. Проверка показала: достаточно добавить фразу «без ссылки» — запись исчезает. Это может произойти случайно, поэтому у многих организаций журналы уже искажены.

Реакция Microsoft

• Уязвимость признали «важной» и исправили.
• Клиентов не уведомили; официального бюллетеня нет.
• Процесс MSRC занял 45 дней, ответы были формальными, без деталей.

Вывод

Журналы аудита M365 Copilot ненадёжны, а Microsoft не планирует информировать пользователей. Организациям стоит перепроверить свои логи и усилить контроль доступа к чувствительным данным.

• Copilot читает индексированные данные от имени привилегированного сервиса, поэтому не фиксирует в журнале доступ к самому файлу.
• Это приводит к утечкам: пользователь видит содержимое, но в аудите нет записи о нарушении прав.
• Исправление Microsoft ограничилось «автоматическим обновлением» без CVE и без изменения архитектуры.
• Участники считают проблему классической «confused deputy» и указывают, что фильтрация по правам в векторной БД вполне масштабируется.
• Советуют подключить Legal/Compliance и готовиться к регуляторным разбирательствам, особенно в HIPAA-окружении.