anonymous@RULINUX.NET~# Last login: 2024-12-26 13:46:39
Регистрация Вход Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск
[#] [Добавить метку] [Редактировать] Фильтры
  • матерные выражения
  • торсионщина
  • порно
Скрыть

Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

В инструментарии управления изолированными контейнерами LXC выявлена уязвимость (CVE-2016-8649), позволяющая при наличии прав root внутри непривилегированного контейнера (работающего в отдельном user namespace) получить доступ к файлам хост-системы и выполнить свой код вне изолированного окружения.

Атака может быть совершена при запуске в контейнере процессов при помощи утилиты lxc-attach. Пользователь root в контейнере имеет возможность влиять на работу утилиты lxc-attach, что, в сочетании с достаточно просто достигаемым состоянием гонки при выполнении lxc-attach, может привести к отключению ограничений и получению доступа к хост-системе. Уязвимость охватывает две проблемы: использование в lxc-attach данных из источников, подконтрольных пользователю контейнера, и возможность применения вызова ptrace для экземпляров lxc-attach, созданных в другом пространстве пользователей (root из контейнера может получить доступ к процессу, созданному во внешнем user namespace).

В частности, lxc-attach оставляет открытым файловый дескриптор к одному из файлов /proc на стороне хост-системы, что позволяет атакующему получить чего него доступ к остальным частям файловой системы, используя системные вызовы семейства openat(). В том числе через файловый дескриптор могут быть записаны данные в файлы /proc/PID/attr/current или /proc/PID/attr/exec на стороне хост-системы для установки меток AppArmor и SELinux к прикреплённому процессу, что даёт возможность отключить сброс привилегий для процесса, запускаемого при помощи lxc-attach.
Уязвимость уже устранена в Ubuntu Linux и ожидает исправления в Debian, RHEL/CentOS, Fedora, Fedora EPEL и SUSE/openSUSE. Патч для блокирования уязвимости принят в дерево исходных текстов LXC, но для полного устранения возможных альтернативных векторов атаки также требуется внесение исправлений в ядро Linux для реализации проверки прав доступа к ptrace с учётом user namespace.
http://openwall.com/lists/oss-security/2016/11/23/6
http://www.opennet.ru/opennews/art.shtml?num=45573


Dr.uid(*) (2016-11-27 15:19:40)

Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/48.0

[Ответить на это сообщение]
avatar
Скрыть

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

В LXC вроде всегда рекомендовалось быть очень осторожными с рутовыми правами внутри контейнера

anonymous(*)(2016-11-27 17:01:10)

Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
avatar
Скрыть

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Это вам не джейлы, да

anonymous(*)(2016-11-27 17:42:26)

Mozilla/5.0 (X11; FreeBSD amd64; rv:50.0) Gecko/20100101 Firefox/50.0
avatar
Скрыть

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

как-то это всё не нра.. есть какое-то субъективное ощущение, что постоянно из *nix хотят сделать M$. chroot, jail, sysjail - Ъ *nix механизмы "изоляции", но.. by system design "рут" в *nix таки обязан иметь права на железо. из-за этого собсно попёрла ставка на полную виртуализацию окружения, несмотря на гораздо бОльшие "накладные расходы".

извините за сумбур, когда читаю подобные "уязвимости" всегда думаю о некоем желании/стремлении урезать по умолчанию рутовые права, вместо того, чтобы тупо не раздавать эти самые права направо и налево.

anonymous(*)(2016-11-28 00:03:35)

w3m: a Proud Member of USSR Communist Party
avatar
Скрыть

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Я ничего не понял. LXC как раз стремится снизить эти самые 'гораздо бОльшие "накладные расходы"', а раздавать рутовые права направо и налево - просто небезопасно. Раздашь налево - а там бэкдор, троян или баг какой-нибудь окажется. Или пользователь непреднамеренно совершит какую-нибудь ошибку.

anonymous(*)(2016-11-28 05:47:07)

Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
avatar
Скрыть

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Не раздавать права оказывается недостаточно. Это было ещё номально когда по размещалось в ФС в виде одного бинарника, и отслеживалось на этом уровне. Вот сейчас и стремяться все засунуть в контейнер, чтобы было можно управлять доступом как единым контейнером, а не отслеживать на уровне файлов, которых овердофига. Но проблема поднятия привелегий через уязвимости остается, только теперь в другом виде.

anonymous(*)(2016-11-28 16:21:43)

Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
avatar
Скрыть

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Не раздавать права оказывается недостаточно. Это было ещё номально когда по размещалось в ФС в виде одного бинарника, и отслеживалось на этом уровне. Вот сейчас и стремяться все засунуть в контейнер, чтобы было можно управлять доступом как единым контейнером, а не отслеживать на уровне файлов, которых овердофига. Но проблема поднятия привелегий через уязвимости остается, только теперь в другом виде.

камрад, попытаюсь ещё раз сказать мысль, что была не понята..

chroot, jail, sysjail и всё прочее в том же ключе - это "классика". оверхед - минимален. работает в пределах возможностей хоста (kernel + fs + memory). требует прямых рук одмина. и именно тут, на пункте "прямые руки", всё и заверте..

lxc, openvz и контейнеры "солярки", оч грубо говоря, - тот же chroot. все они стартуют "рутом". соответственно root в "контейнере" == container_started_pid (по уровню допуска). т.е. та же ситуёвина, что и при получении "рута" в chroot. для контроля прав на уровне приложений у нас собсно есть тот самый "одмин"(ц)(тм) со своим банхаммером, пилой, ножовкой, пивом и какой-то матерью: selinux, apparmor, polkit, udev, acl, attr и т.п. и т.д..

т.е. "out of scope activity", пмсм, можно пресечь не только рихтовкой кода lxc, что оч хор и радует несказанно, но и "сторонними" стандартными средствами, предназначенными именно для подобного рода работы. субъективно ессно.

p.s.:
ещё думаю, что "сложность" отслеживания и контроля любого исполняемого бинаря - фикция. если его не стартовать под тем самым "рутом", ога.. муторно, неинтересно, скучно, но никак не сложно. плюс всегда актуален вопрос доверия к "источнику". худший случай - static stripped binary - гемор, да. мы можем "верить" (пример: драйвер nVidia и весь non open source), стартануть в виртуалке под юзером или упороццо на декомпиляции. но. прежде всего мы сами решаем "а оно нам надо, стартовать вот Это?" и таки если "да, надо..", то "заходи, не бойся.. выходя - не плачь!"(ц)

anonymous(*)(2016-11-28 20:41:32)

w3m: a Proud Member of USSR Communist Party
avatar
Скрыть

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

p.p.s.:
не написал выше очевидное.. оч неплохим вариантом была/стала бы возможность не стартовать "контейнер" рутом. пусть будет привилегированный запуск с .. но не явный "рут".

anonymous(*)(2016-11-28 22:17:07)

w3m: a Proud Member of USSR Communist Party
avatar
Скрыть

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

flatpak через что работает? Сам он не требует рута для старта контейнера.

anonymous(*)(2016-11-29 01:47:21)

Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
avatar
Скрыть

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

flatpak через что работает?

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

anonymous(*)(2016-11-29 17:15:11)

w3m: a Proud Member of USSR Communist Party
Этот тред читают 2 пользователя:
Анонимных: 2
Зарегистрированных: 0




(c) 2010-2020 LOR-NG Developers Group
Powered by TimeMachine

Valid HTML 4.01 Transitional Правильный CSS!