В системе для изолированного выполнения приложений Firejail (https://firejail.wordpress.com/) выявлено девять уязвимостей, большинство из которых позволяют повысить свои привилегии в основной системе до пользователя root. Firejail использует (https://www.opennet.ru/opennews/art.shtml?num=45120) для изоляции механизм пространств имён (namespaces), AppArmor и фильтрацию системных вызовов (seccomp-bpf) в Linux, но для настройки изолированного запуска требует повышенных привилегий, которые получает через привязку к утилите флага suid root или запуск при помощи sudo. Как оказалось безопасность Firejail находится в весьма печальном состоянии и многие опции и пользовательские данные обрабатываются под euid 0.
Первой была опубликована (http://openwall.com/lists/oss-security/2017/01/04/1) информация об уязвимости CVE-2017-5180, найденной участниками SuSE Security Team и использующей манипуляцию с файлом /etc/ld.so.preload для запуска своего кода с правами root. Следом было выявлено (http://openwall.com/lists/oss-security/2017/01/05/4) ещё шесть уязвимостей, позволяющих совершить атаку через манипуляцию с tmpfs (CVE-2016-10117, CVE-2016-10119), переписать /etc/resolv.conf (CVE-2016-10118), получить полный доступ к системным файлам из-за монтирования /dev, /dev/shm, /var/tmp и /var/lock в режиме 0777 (CVE-2016-10120, CVE-2016-10121) и выполнить код с правами root из-за неочистки переменных окружения (CVE-2016-10122) и из-за возможности использования режима "--chroot" без seccomp (CVE-2016-10123).
Например, firejail позволяет непривилегированному пользователю примонтировать tmpfs-раздел для любой директории, в том числе прикрепить свой tmpfs-раздел вместо /etc - "firejail --noprofile --tmpfs=/etc". Или можно загрузить с правами root стороннюю библиотеку из-за неочистки переменной окружения LD_PRELOAD при запуске программ в режиме x11 (X-сервер запускается с правами root) - "firejail --x11=xorg --env=LD_PRELOAD=$PWD/rootshell.so". В дополнение было выявлено ещё две уязвимости: выход из изолированного окружения через ptrace при запуске в режиме "--allow-debuggers" (CVE-2017-5207 (http://openwall.com/lists/oss-security/2017/01/07/3)) и выполнение кода с правами root через манипуляции (https://github.com/netblue30/firejail/issues/1023) с опциями --bandwidth и --shell (CVE-2017-5206 (http://openwall.com/lists/oss-security/2017/01/07/5)).URL: http://openwall.com/lists/oss-security/2017/01/04/1
Новость: https://www.opennet.ru/opennews/art.shtml?num=45824
Красота. Недавно читал про сабж - думал может пригодится, а вот оно как...
С самим sandbox там всё в порядке, судя по всему. Суть уязвимостей в том, что запустив firejail с определёнными параметрами можно получить root. Если sandbox был запущен с правильными параметрами, то процессы изнутри sandbox ничего плохого сделать не смогут.
Беда в том, что firejail - suid. Если похакают твоего пользователя, то используя firejail можно будет похакать рута. Вообще-то считается не очень. suid приложения надо писать очень тщательно.Но не нашлось ни одного безопасника, готового писать песочницу под линукс. В результате за это дело взялся прохожий, не слишком хорошо разбирающийся в вопросах безопасности. Скажем так, не сильно лучше анонимных экспертов с этого сайта. Имеем что имеем, полудырявую тюрьму, которая всё ещё лучше полного отсутствия тюрьмы.
>Беда в том, что firejail - suidна лоре советуют bubblewrap
Ирония в том, что самые нелепые уязвимости вылезают в программах для повышения безопасности.
Поэтому sudo предпочитаю su. Говорят так лучше с точки зрения безопасности, хоть пароли разные для разных операций.
> Говорят так лучше с точки зрения безопасностиЧушь какая. sudo по определению даёт меньше прав, чем su. И потом, нужно ограничивать же, через /etc/sudoers
по-моему, здесь разница в том, кто делал - "системный" программист или "прикладной"
если уязвимость с повышением прав до root была в ядре - фиолетово
> если уязвимость с повышением прав до root была в ядре - фиолетовоОно как бы да, но в силу специфики ядерщики пишут код получше, что ни говори. А потому что если халтурить то все падает, с грохотом. И от этого икается хоть самим програмерам. Конечно от ОС зависит. В реактосе какомнить програмеры девелопают из максималки в вьюжлстудии, понятно что стабильность системы их не парит.
Я использую firejail, уязвимости с удаленным исправлением кода есть?
Исполенение кода в твоем браузере - не удаленное.Лень метаться пока эксперты более достойную кандидатуру на свет б не вытащат.
А в новости про автокликер баннеров (https://www.opennet.ru/opennews/art.shtml?num=45821) народ был свято уверен, что Firejail их защитит в случае, когда автокликер словит рано или поздно эксплоит-пак.Именно поэтому ПО, увеличивающее риск поймать какую-либо гадость (в данном случае, такое ПО - автокликер), не нужно.
Эксплоит-паку в данном случае нужно будет предолеть ещё и firejail. Т.е. должен быть специфичный экслоит, эксплуатирующий уязвимости сразу двух продуктов. Да ещё и под linux. А шанс на появление такого экслоита аналогичен шансу, что firejail займёт хотя бы 20% пользовательских ПК всего мира.
Что мешает делать бомбовую атаку из исплоитов?
> Что мешает делать бомбовую атаку из исплоитов?Нежелание палить все карты.
> Нежелание палить все карты.И повышение вероятности "treason uncloaked!". Ну как, если вы перочинный ножик в кармане носите-это одно. А тридцать хренов устроивших ураганную пальбу в центре города из пулеметов - поднимут на уши всех. Одни только аверы устроят между собой CTF "кто первый этот отнет завалит?!". А потому что хорошее дело фирму украшает. Стало быть пиар.
Ну учитывая, что речь была про линуксы, то экономическая целесообразность.
Сплоит тоже разработать надо - это ресурсы. Тем более в одном дистрибутиве соберут так, в другом сяк. Слишком много возни для слишком малого потенциального улова.
Если firejail работает под рутом то нужно преодолеть только firejail.
> Если firejail работает под рутомОн не работает под рутом. Так что нужно попотеть, чтобы рутовый доступ ещё получить.
> Если firejail работает под рутом то нужно преодолеть только firejail.А ничего что конфигурирование контейнера таки требует повышенных прав?
Не читатели?Уязвимость в утилите firejail, а не в контейнере.
Подсунув ей заточенный чрут или атакуя проц/тмпфс во время выполнения.
Атака снаружи а не изнутри!
Интересно, в убунте скоро исправят?
Доизолировались.
Внимательно посмотрел на номера уязвимостей, в том числе исправленных. Много думал.
А что там странного, номера CVE не назначаются по порядку. Red Hat выдаёт номера CVE из заранее выделенного пула. В 2017 году им выдали пул CVE-2017-5xxx.
Иногда лучше один раз прочитать, чем семь раз подумать =)