Уязвимость во Flatpak, позволяющая выполнить код вне изолированного окружения

нужно добавить ~/.bashrc или ~/.profile

Куда добавить?

изменить

В ~, очевидно. Странный вопрос.

Но да, новость кривовато написана — не ясна суть уязвимости. Собственно уязвимость позволяет обойти ограничения песочницы и получить доступ к файлам на хосте. Ну и понятно, что в качестве примера автор приводит наиболее очевидный способ запуска произвольного кода на хосте таким путём — создать какой-то файл, который у юзера исполняется автоматически, самое простое — ~/.profile, хотя можно и с кронтабами какими помудрить.

Автору рекомендую добавить в начало новости больше информации о собственно самой уязвимости, без неё пример эксплуатации действительно каким-то оторванным от реальности выглядит.

обойти режим изоляции, получить доступ к файлам в хост-системе

Разве недостаточно?

В ~, очевидно. Странный вопрос.

Ну, я вижу, что на OpenNET с подробностями тоже не справились:

Для организации выполнения своего кода в системе, например, можно добавить автозапускаемый сценарий, такой как «~/.bashrc» или ~/.profile, или изменить файл ~/.ssh/authorized_keys с ключами SSH.

Р Е Ш Е Т О !

обойти режим изоляции, получить доступ к файлам в хост-системе

Разве недостаточно?

В новости «получить доступ к файлам в хост-системе и выполнить произвольный код». Но насколько я понял суть, уязвимость позволяет именно получить доступ к файлам в хост-системе. Выполнить произвольный код можно уже не благодаря этой уязвимости, а просто потому что имея доступ на запись к файлам хоста, ты можешь записать тот файл, который будет рано или поздно выполнен (по независящим ни от Flatpak, ни от этой уязвимости, причинам).

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

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

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

а есть ли тут пользователи, которые активно используют flatpak? я так понимаю, любители nixos?

Есть, конечно (не я лично). Обмажутся своими флатпаками и снапами и сидят довольные.

на OpenNET с подробностями тоже не справились

Там хоть потрудились расписать. А здесь три строчки. Это даже на мини-новость не тянет. Максимум в толксы, мол, жрите шо дают. Эх, ЛОРчик :(

Есть, конечно

Случаем, подмножество пользователей которые использует flatpak, и подмножество пользователей которые правят файлы через mcedit не пересекаются на 80%+ ?

а есть ли тут пользователи, которые активно используют flatpak?

Согласно опросу, очень много кто пользуется (я даже немного удивился тогда). Насколько активно, сложно судить, но не все только когда это единственный доступный вариант, похоже.

я так понимаю, любители nixos?

А зачем в nixos флатпак? Они же наоборот очень гордятся тем, что штатными средствами можно кучу разных версий либ одновременно и всё такое прочее. Кажется, как раз им флатпаки как раз меньше всех нужны.

А так их вроде редхатовцы продвигают? Надо юзеров федоры спросить.

А что лучше: flatpak, snap, deb или rpm?

А зачем в nixos флатпак? Они же наоборот очень гордятся тем, что штатными средствами можно кучу разных версий либ одновременно и всё такое прочее. Кажется, как раз им флатпаки как раз меньше всех нужны.

Флатпак никак не противоречит использованию никс. Флатпак позволяет установить приложение в песочницу максимально простым и удобным путем. Есть пачка хелперов, которые интегрируют управление флатпак-пакетами в никс-конфигурацию

Нативного аналога в никсе нет, разве что можно переизобрести флатпак используя bubblewrap и аналоги

Я хотел оттуда полностью скопипастить (это и сейчас не поздно сделать), но и тогда нашлись бы недовольные. :)

А что лучше: flatpak, snap, deb или rpm?

guix

Так словно им кто-то пользуется

А зачем в nixos флатпак?

Они же наоборот очень гордятся тем …

Они этим гордятся до тех пор, пока какая-нибудь сборка (тулза, etc) не выходит за пределы их парадигмы.

За примером далеко ходить не надо, например, сборка java приложение с библиотекой grpc, в убунте я делал:

$ gradle build

в nixos мне пришлось потратить 4 часа на это

#!/usr/bin/env bash

#nix-shell -p glibc
gradle build || : # first time it's always fails
theLd=$(patchelf --print-interpreter $(which mkdir))
patchelf  --set-interpreter $theLd $1 .gradle/caches/modules-2/files-2.1/com.google.protobuf/protoc/3.21.12/62e794ebd383cad86347240f1c9b419c8d8fce10/protoc-3.21.12-linux-x86_64.exe
patchelf  --set-interpreter $theLd $1 .gradle/caches/modules-2/files-2.1/io.grpc/protoc-gen-grpc-java/1.52.0/e185ee31296001fd7132668138e36d4896d03400/protoc-gen-grpc-java-1.52.0-linux-x86_64.exe

LD_LIBRARY_PATH="/nix/store/8mhaj6yvvb7rq0kl5xmg6wl9myxvs804-gcc-11.3.0-lib/lib/:${LD_LIBRARY_PATH}" gradle build

А что лучше: flatpak, snap, deb или rpm?

deb/rpm используется для системного софта, flatpak/snap для прикладного – они позволяют запускать софт в песочнице и дают тонкую настройку пермишенов

минус flatpak’a – в него не пакуют консольный софт

минус snap’a – раздут и разработан canonical(обычно их идеи мертворожденные)

которые использует flatpak, и подмножество пользователей которые правят файлы через mcedit

Шта? Как это связано?

Лучше бы скопипастил, ей-богу :)

Для непонимающих смысл Flatpak надо сделать пояснение:

Ваш софт, установленный через deb/rpm/pacman, имеет доступ к файлам в хост-системе без каких-либо CVE.

Лучше нативные пакеты (.DEB / .RPM / PACMAN / AUR итд.) или Flatpak.

Snap имеет проприетарный back-end, а также требует демона snapd, который всегда работает в фоне и проверяет обновления, даже когда ты играешь или работаешь, а раньше оно ещё и обновлялось автоматически без твоего ведома (потом добавили паузу).

Ну и чисто с точки зрения здравого смысла и против Snap - Canonical подменяли команды юзера, чтобы пропихнуть Snap-версию браузера Firefox. Не уверен, поменялось ли что-то в свежих версиях Ubuntu.

В постах на Reddit’е и в Гугле говорится, что Snap сейчас уже не такой тупой и медленный, каким был раньше. Но неотключаемый (для сохранения работы Snap-пакетов) демон и проприетарный back-end никуда не делись.

Приоритет - натив. Потом - Flatpak. И только в последнюю очередь стоит смотреть на Snap. Это реально тот случай, когда «голосовать ногами» проще простого…

На серверах своя специфика.

Что ж, готово.

Если не используется SELinux или AppArmor. Которые по умолчанию таки включены много где.

Если не используется SELinux или AppArmor. Которые по умолчанию таки включены много где.

Покажи мейнстримные дистрибутивы плз

без каких-либо CVE

кроме CVE-2026-34078

💥💥💥

Я ещё до nixos пользовался:

• чтоб не зависеть от хотелок мейнтейнеров дистрибутивов
• чтоб запускать там бразуер, мессенджеры и прочий жирный сетевой софт в изоляции

Мне казалось такие инфраструктурные вещи типа flatpack делают с включенной головой… Монтировать и не думать про ссылки? Это же базовый путь выезда из песочницы. Впрочем, а содержимое flatpack выполняется от текущего пользователя?

Ты просто анскильная лалка. Ну и причем тут сборка кастомного приложения, если речь про флатпак? Кастомные приложения не распространяются во флатпак. А для опенсорса nixpkgs - это один из самых больших репозиториев софта в линуксах. Так что особой потребности во флатпаке и нет. По крайней мере точно ниже, чем в более других дистрибах.

А что лучше: flatpak, snap, deb или rpm?

AppImage и tarball.

а РКН заранее позаботился и заблокировал flathub.org :-)

Я предпочту собрать из исходников, так оно надëжнее.

это один из самых больших репозиториев софта в линуксах

ты видимо игнорируешь списки рассылок nixos, которые пронизаны болью пользователей которые не могут запустить у себя x.y.z и ответ им один: flatpak, appimage, docker

сразу видно, что забыли через клода прогнать. Он бы все баги сразу спалил

RHEL и клоны, Fedora – SELinux.

Ubuntu, Debian, многие производные, вроде Linux Mint – хотя AppArmor обычно менее строгий, чем SELinux.

Ubuntu, Debian, многие производные, вроде Linux Mint – хотя AppArmor обычно менее строгий, чем SELinux.

А как файл-пикеры работают в таком случае? Уведомления? Во Flatpak это реализовано через dbus(xdg portals, fuse mounts), сомневаюсь что такой механизм есть для apparmor/selinux

Подозреваю что нету там никаких политик для десктопного софта по-умолчанию, и используется оно только для secure hardening механизмов повышения привелегий и тд

Хомяк для пакетов из флетпака запрещён? Потому что если нет, то я знаю как запустить произвольный код в обход песочницы. ХЗ с чем борются короче. Песочница должна быть отдельно от пакетных менеджеров, а те в свою очередь должны с ней работать. Тогда лучше ситуация с ИБ станет, можно будет тем кто занимается песочницей сконцентрировать усилия на ней, а не тянуть отдельно флетпак, снап, пип и прочую ересь, что стала использоваться в обход основного пакетного менеджера дистрибутива.

Хомяк для пакетов из флетпака запрещён?

Да, для эталонной реализации пакета да. Большинство пакетов сделаны как попало, но это другой вопрос.

Тут можно сколько угодно ругать flatpak, и есть за что, но других альтернатив нет

Ну а толку то. Обычно софт из флетпака обязан работать с хомяком. Так что надо либо хомяк делить на /home/user/files и /home/user/.configs и в последнем делать по каталогу на каждую софтину, куда она и только она может лазить без прав рута, либо будет решето.

Ну а толку то. Обычно софт из флетпака обязан работать с хомяком.

Нет, по замыслу софт должен работать с хомяком через fuse-прослойку, где каждое действие подтверждается юзером через файл-пикер

Угу, а потом оно иконки подгрузить не может или звук уведомления, потому что оно в хомяке где-то валяется.

Угу, а потом оно иконки подгрузить не может или звук уведомления, потому что оно в хомяке где-то валяется.

Если софт следует xdg, то такого быть не должно, иначе это баг flatpak’a

В новости «получить доступ к файлам в хост-системе и выполнить произвольный код». Но насколько я понял суть, уязвимость позволяет именно получить доступ к файлам в хост-системе.

Тем не менее подобные уязвимости называют исполнением кода. Если шанс реализации запуска внешнего кода всё ещё значителен (а тут он почти 100%), то от того, что злонамеренный процесс не делает непосредственно exec процесса вне своего контейнера, классификация уязвимости не меняется.

А кому какое дело до xdg? И вообще я противник всяких ограничений ради ограничений, когда толку в ограничениях реального нет совсем. А в итоге имеем и дырявую систему с пакетами от Васяна, которые лезут куда-попало и кучу толком не работающего софта, который не может залезть туда, куда ему нужно.

Ты как-то неверно позиционируешь флатпак. Это утилита для нубов. Ни о какой включённой голове там речи не шло.

Если софт из песочницы вылезет в хомяк, то внесёт в файл ~/.bashrc вредоносный код и всё, приплыли. И таких мест в хомяке штук 6 которые всегда работают в любом окружении, кроме самой экзотики и ещё штук 50 которые работают при наличии некоторого софта на машине.

Вот же обмажутся горами костылей, а потом удивляются почему всё такое убогое.