The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

27.11.2016 11:38

В инструментарии управления изолированными контейнерами 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.

  1. Главная ссылка к новости (http://openwall.com/lists/oss-...)
  2. OpenNews: Выпуск системы управления контейнерами LXC 2.0
  3. OpenNews: Выпуск системы управления контейнерами LXC 1.1, со встроенной поддержкой CRIU
  4. OpenNews: Треть образов контейнеров в Docker Hub содержит опасные уязвимости
  5. OpenNews: Уязвимость в CoreOS Alpha, позволяющая войти по SSH без пароля
  6. OpenNews: Уязвимость в ядре Linux, позволяющая выйти из изолированного контейнера
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/45573-lxc
Ключевые слова: lxc
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (43) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, KonstantinB (ok), 12:35, 27/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Давать кому попало рута в контейнере - это уже заведомо хождение по минному полю. Такие уязвимости, боюсь, будут всегда.
     
     
  • 2.4, Аноним (-), 12:57, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Давать кому попало рута в контейнере - это уже заведомо хождение по
    > минному полю. Такие уязвимости, боюсь, будут всегда.

    LXC просто изначально не хотели делать рута внутри контейнеров, ну а потом по-быстрому накрутили, вот и результат

     
     
  • 3.6, KonstantinB (ok), 13:14, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да фиг с ним, с lxc, тут основная проблема в ptrace().
     
  • 3.7, KonstantinB (ok), 13:18, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, то есть как. Не хотели, потому что ядро не обеспечивало достаточной изоляции само по себе. Проверки в юзерспейсе - это заведомо ненадежный способ.
     
     
  • 4.17, Аноним (-), 16:11, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну, то есть как. Не хотели, потому что ядро не обеспечивало достаточной
    > изоляции само по себе. Проверки в юзерспейсе - это заведомо ненадежный
    > способ.

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

    Мне LXC больше напоминает Linux-Vserver, но второй из этого списка уже слабо активен

     
  • 2.11, Anonymous_1 (?), 14:46, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Смысл тогда в контейнере, если рута не давать?)
     
     
  • 3.12, username (??), 15:23, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Хм, ну поясни зачем тебе там рут, просто интересно.
     
     
  • 4.13, хомяк (?), 15:33, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как запустить nginx без root?
     
     
  • 5.18, username (??), 16:53, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Так же как и с рутом.
    Единственная привилегия, которая может понадобиться вебсерверу, это возможность слушать на портах < 1024. Что вполне решается навешиванием атрибутов (привилегий) на бинарник nginx
     
     
  • 6.45, Аноним (-), 08:20, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Что вполне решается навешиванием атрибутов (привилегий) на бинарник nginx

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

     
     
  • 7.59, Аноним (-), 00:45, 29/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Непривилегированные контейнеры с разрешенным CAP_NET_BIND_SERVICE
     
  • 6.48, PnDx (ok), 15:06, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Порт за-DNAT-ить. Обычно приемлемо, если в conntrack не упирается. (Но где это проблема, там lxc с iptables'ами по фигу наверное, т.к. netmap и прочее интересное.)
     
  • 5.21, Аноним (-), 18:42, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +11 +/
    > Как запустить nginx без root?

    Уже дюжину лет как
    [CODE]
    sysctl security.mac.portacl.rules=uid:80:tcp:80
    [/CODE]

     
     
  • 6.49, PnDx (ok), 15:08, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Уже дюжину лет как
    > [CODE]
    > sysctl security.mac.portacl.rules=uid:80:tcp:80
    > [/CODE]

    # sysctl -a | grep  security | wc -l
    0
    У Вас таки фрюха?

     
     
  • 7.52, Аноним (-), 17:31, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > # sysctl -a | grep  security | wc -l
    > 0
    > У Вас таки фрюха?

    Ну да. Я думал, раньше кто догадается.
    А что, в пингвины такие вещи еще не завезли? oO
    Тогда пожалуйста:
    https://github.com/freebsd/freebsd/blob/master/sys/security/mac_portacl/mac_po
    Хотя у вас вроде как setcap + CAP_NET_BIND_SERVICE есть ;)

    Да и в целом просто прикольный эксперимент - вон, пока не знали, накрутили 6 плюсов, теперь можно посмотреть, насколько классовая неприязнь преобладает над здравым смыслом )

    Кстати, man grep
    > -c Выдает только количество строк, содержащих образец.
    >

     
     
  • 8.53, Michael Shigorin (ok), 18:19, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Кто как Держите седьмой для ровного счёта ... текст свёрнут, показать
     
  • 6.58, pavlinux (ok), 00:00, 29/11/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    $ sysctl security.mac.portacl.rules=uid:80:tcp:80
    sysctl: Permission denied

    Оттака ..ня, ребяты

     
  • 4.14, angra (ok), 15:33, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Начни с рассказа, зачем тебе вообще рут где-либо. Может в процессе и сам поймешь. Контейнер ничем особо не отличается от железной машины для большинства задач.
     
     
  • 5.37, Аноним (-), 22:42, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Начни с рассказа, зачем тебе вообще рут где-либо. Может в процессе и
    > сам поймешь. Контейнер ничем особо не отличается от железной машины для
    > большинства задач.

    что бы запускать свои сервисы - а не те которые хостер за меня решил запустить.
    к пример потунелировать openvpn через 443 порт.

     
     
  • 6.39, angra (ok), 22:52, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе надо помочь сделать следующий шаг? Если рут тебе обычно нужен для запуска своих сервисов, то рут в контейнере тебе нужен ... для запуска в нем своих сервисов. Неожиданно, правда?
     
  • 2.15, angra (ok), 15:34, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Расскажи это хостерам с openvz, они посмеются. А тем, кто заикнется про XEN и прочая, можно напомнить, сколько уязвимостей было там.
     
     
  • 3.22, KonstantinB (ok), 19:11, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В openvz похожие уязвимости были.
     
     
  • 4.29, angra (ok), 20:28, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Уязвимости находили практически везде. Объявишь весь софт минным полем и откажешься от него?
     
     
  • 5.33, KonstantinB (ok), 21:55, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это был ответ на "расскажи хостерам".

    В целом же, openvz изначально сделан грамотно. Openvz - это прежде всего патчи на ядро, достичь безопасности на дырявом ядре за счет проверок в userspace там никому в голову не приходило.

    lxc же это просто юзерспейсный набор инструментов, упрощающих использование linux containers/namespaces/cgroups. Говорить о его безопасности вообще не имеет смысла, его безопасность равна безопасности ядра. И патчи, подобные вот этой ерунде, на которую ссылка - это лечение симптомов, костыль, затыкающий один из бесконечного числа возможных векторов атаки.

    Реально уязвимость в ядре, в реализации ptrace(). В ядре уязвимости всегда были и еще много найдут, их там исправят, это нормально. Ненормально пихать userspace-затычки на один частный случай и называть это security fix.

     
     
  • 6.36, Аноним (-), 22:40, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > В целом же, openvz изначально сделан грамотно

    еще бы. долгое время тестировали на бесплатных юзерах, прежде чем закрыть его.
    Все же помним - как SWSoft - (тогда так назывался) взял и закрыл и никому не давал свои патчи на ядро.

     
  • 6.38, angra (ok), 22:45, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > достичь безопасности на дырявом ядре за счет проверок в userspace там никому в голову не приходило
    > его безопасность равна безопасности ядра.

    Ты уже отказался от дырявого линуксового ядра или еще ходишь по этому минному полю? Или ты вообще считаешь, что ходить по минному полю это нормально так как "В ядре уязвимости всегда были и еще много найдут, их там исправят, это нормально"? Тогда к чему вообще был пассаж про рута в контейнере?

     
     
  • 7.40, KonstantinB (ok), 22:55, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я имел ввиду linux containers в их текущем состоянии, а не какие-нибудь там абстрактные контейнеры.
     
     
  • 8.42, angra (ok), 00:02, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Теперь стало понятней и я даже частично согласен По-крайней мере давать чистого... текст свёрнут, показать
     
  • 6.43, Валик228 (?), 04:57, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > В целом же, openvz изначально сделан грамотно. Openvz - это прежде всего патчи на ядро, достичь безопасности на дырявом ядре за счет проверок в userspace там никому в голову не приходило.

    в целом же, ты чушь морозишь несусветную ибо некомпетентен совершенно.
    openvz 10 лет тому возможно таким и было. сейчас опенвз целиком работает на неймспейсе, цпусетах и прочих ядерных технологиях (как и lxc), авторами большей части которых и являются openvz-шники.

     
     
  • 7.44, angra (ok), 07:32, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Целиком? Сам то пробовал, компетентный ты наш? Кое-какую функциональность с vzctl 4.x и ванильным ядром получить конечно можно, но это будет лишь жалкая тень openvz, уступающая lxc. Полноценная работа openvz возможна лишь с их ядром.
     
     
  • 8.50, Аноним (-), 16:10, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    не тупи - openvz потихоньку сливается - все наработки переливая в ванилу скор... текст свёрнут, показать
     
     
  • 9.54, angra (ok), 22:12, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ничего себе степень альтернативной одаренности Да если весь патч openvz перейде... текст свёрнут, показать
     
     
  • 10.55, Аноним (-), 22:53, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    нет сил свое тянуть, cgroups linux-vserver наступают на пятки, клиенты уже нос... текст свёрнут, показать
     
     
  • 11.57, angra (ok), 23:10, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты еще и из альтернативной вселенной пишешь ... текст свёрнут, показать
     
     
  • 12.60, Аноним (-), 13:01, 29/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а тебе Parallels сколько отстегнул ... текст свёрнут, показать
     
  • 5.47, Аноним (-), 14:48, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Уязвимости находили практически везде. Объявишь весь софт минным полем и откажешься от
    > него?

    Компьютеры - минное поле. Срочно отказываемся от них и возвращаемся в пещеры! Мамонт стынет! /s

     
  • 2.28, Аноним (-), 20:09, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Давать кому попало рута в контейнере - это уже заведомо хождение по
    > минному полю. Такие уязвимости, боюсь, будут всегда.

    Выделяя пользователю контейнер по сути на откуп отдают отдельную виртуальную систему, чтобы пользователь сам в ней всё настраивал. Root в контейнере при user namespace никаким образом не должен пересекаться с root-ом в основной системe.

     
  • 2.30, Michael Shigorin (ok), 21:21, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Давать кому попало рута в контейнере - это уже заведомо хождение по минному полю.

    Смотря в каком.  Но особо воодушевлённые давно уж не верили, что LXC не для безопасности, а для удобства.

    Жаль, с ovz containers что-то непонятное творится.

     
     
  • 3.32, Аноним (-), 21:48, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    там просто уже некому делать вменяемый код.
     
  • 3.35, KonstantinB (ok), 22:00, 27/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Смотря в каком

    В linux containers, разумеется - в контексте новости. Solaris zones я не имел ввиду точно.

    > Жаль, с ovz containers что-то непонятное творится.

    Да вроде понятное - "дом свободный, живите кто хотите".

     
     
  • 4.51, Ванга (?), 16:54, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Так опенвз вроде слился с виртуоззо?
     
     
  • 5.56, Аноним (-), 22:53, 28/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Так опенвз вроде слился с виртуоззо?

    openvz это подачка в виде Open Core от виртуозы.

     

  • 1.61, seyko (??), 03:53, 30/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какой host-провайдере предоставляет возможность использовать свой OS-template для контейнеров openxz ? Почему-то большинство предлагают только ими приготовленные заготовкии. Своя ОС -- только при использовании KVM (в виде ISO)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру