The OpenNET Project / Index page

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

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

12.05.2017 09:01

В Ubuntu временно заблокирована возможность использования гостевого сеанса в дисплейном менеджере LightDM из-за выявления уязвимости (CVE-2017-8900), которая позволяет получить доступ к файлам вне гостевой директории, в том числе к файлам в домашних каталогах обычных пользователей. Проблема проявляется начиная с Ubuntu 16.10 и вызвана прекращением применения ограничений AppArmor (в Ubuntu 16.04 и более ранних выпусках применялся профиль /usr/lib/lightdm/lightdm-guest-session) после перехода к использованию systemd для управления сеансами. В качестве возможного пути устранения проблемы рассматривается использование модуля pam_apparmor для применения ограничивающего профиля AppArmor.

  1. Главная ссылка к новости (https://www.ubuntu.com/usn/usn...)
  2. OpenNews: Уязвимость в LightDM, позволяющая повысить свои привилегии в системе
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/46537-lightdm
Ключевые слова: lightdm
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (39) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 09:09, 12/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Показателен ответ разработчиков Ubuntu на сообщение о баге, которое было отправлено ещё в феврале:

    "Ow. Unfortunately I don't have any information on how to fix this since most of the work on guest sessions and systemd was done by Martin Pitt."

    В итоге, после трёх месяцев не придумали ничего, чем просто отключить гостевой сеанс.

     
     
  • 2.2, Аноним (-), 09:11, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +23 +/
    Зря ругаешь. Это обычный самоотвод, т.к. вопрос вне компетенций данного инженера. Во всем виноват systemd, это очевидно.
     
     
  • 3.26, Аноним (-), 14:28, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То есть в других дистрибутивах с systemd всё нормально, и только в Ubuntu проблемы, но виноват все равно systemd. Логика железная.
     
     
  • 4.35, Адекват (ok), 15:27, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > То есть в других дистрибутивах с systemd всё нормально, и только в
    > Ubuntu проблемы, но виноват все равно systemd. Логика железная.

    Без СистемД данная проблема была ?

     
     
  • 5.40, Аноним (-), 19:50, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а без убунты, а без линукса?
     
  • 5.43, Аноним (-), 15:37, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    То есть если бы был открыт доступ к ssh с публичным паролем, это была бы проблема ssh? Ведь без него проблемы нет.
     

  • 1.5, Вот и выросло поколение (?), 09:35, 12/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    Нас в садике учили: если не хочешь, чтобы другие другие видели твои файлы, сделай chmod 700 $HOME.
     
     
  • 2.9, hoopoe (ok), 09:47, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +12 +/
    там немного другое: на системе есть зареганые юзеры - они могут видеть файлы друг друга, и есть гостевой сеанс - он не должен видеть файлы остальных узверей. вот это "не должен" и сломали при внедрении systemd

    вообще странно что гостя тупо не засунули под контейнера, это самый очевидный способ загнать в клетку

     
     
  • 3.13, Аноним (-), 10:16, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    засовывать его в контейнер ещё тот аттракцион, причём с учётом того что нужно будет пропихнуть в контейнер, не факт что поможет.
     
  • 3.15, X3asd (ok), 10:17, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > они могут видеть файлы друг друга

    наверно могут те -- которые сделали их друг для друга доступными через вызов setfacl?

    > и есть гостевой сеанс - он не должен видеть файлы остальных узверей

    потому что ни кто не делал вызов setfacl для него?

     
     
  • 4.17, iPony (?), 10:35, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > наверно могут те -- которые сделали их друг для друга доступными через вызов setfacl?

    Неа. По дефолту юзеры без проблем могут шастать по чужой домашней папке
    https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/

     
     
  • 5.18, UUU (?), 11:17, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    1. $ find /home/user -type f -exec chmod 600 {} \;
    2. $ find /home/user -type d -exec chmod 700 {} \;

    Только не перепутайте последовательность.

     
     
  • 6.19, Аноним (-), 11:34, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1. Достаточно {} или нужно "{}" (с кавычками)?
    2. Что будет если перепутать последовательность?
     
     
  • 7.22, UUU (?), 11:45, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    1. На практике достаточно.
    2. Не войдете потом ни в одну папку в домашней директории.
    3. Имя пользователя нужное не забудьте подставить вместо "user".
     
     
  • 8.48, Аноним (-), 23:20, 16/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Подозреваю ты хотел сказать не перепутайте -type d 700 с -type d 600... текст свёрнут, показать
     
  • 6.21, Ilya Indigo (ok), 11:40, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    $ chmod -R a=,u+rwX ~
     
     
  • 7.49, Аноним (-), 23:31, 16/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > $ chmod -R a=,u+rwX ~

    chmod -R go-rwx ~ # у группы и осталных отобрать read, write, execute
    А что ваш набор букв означает?


     
     
  • 8.51, Ilya Indigo (ok), 23:48, 16/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Мой набор букв означает сначала рекурсивно забрать все права у всех 000 , а п... текст свёрнут, показать
     
  • 7.52, Аноним (-), 09:44, 18/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Тут ~/bin/* передают тебе привет.
     
     
  • 8.53, Ilya Indigo (ok), 15:05, 18/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    В том-то и дело, что зонды, спайвари и прочая нечисть не сможет этого сделать А... текст свёрнут, показать
     
  • 5.46, XoRe (ok), 08:32, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Неа. По дефолту юзеры без проблем могут шастать по чужой домашней папке

    В зависимости от дефолтных настроек.

     
  • 3.24, yan123 (?), 14:16, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Тогда все юзеры идут в группу users, а гость в группу guest, права выставляем соответсвенно.
    (с) мопед не мой -- подход придуман где-то в ранних 70-х умными людьми и вроде как обкатан и железобетонно работал всё это время.
    Меня тоже в убунте иногда удивляет желание разработчиков прикрутить свои "велосипеды" вместо использования простого рабочего решения.
     
  • 3.31, vitvegl (?), 14:45, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    он под "appaarmor"
     
  • 3.42, Аноним (-), 21:37, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > там немного другое: на системе есть зареганые юзеры - они могут видеть
    > файлы друг друга

    Все давно уже есть, делаете специальную группу для этих вездешастающих юзеров, добавляете их в ту группу и делаете
    chmod 750 ~
    chown :special_group ~

    voila!

    Кстати, если просто хочется закрыть доступ к домашнему каталогу для других пользователей (включая системных пользователей как nobody и daemon), в chmod не нужно -R, path traversal не будет работать если нет доступа к хотя бы одному каталогу. chmod 700 $HOME хватит. Адептам find ... -exec chmod советую "chmod 700 /".

     
  • 3.44, Аноним (-), 19:15, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Они могут видеть потому что являются членами группы, которой разрешено смотреть в чужие хоумы. И это "не должен" не зависит от системдэ.
     
  • 2.16, Нанобот (ok), 10:27, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    трудное у тебя было детство, сочувствую
     

  • 1.6, Аноним (-), 09:42, 12/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    сколько ещё нам чудных открытий готовит системде
     
     
  • 2.12, Crazy Alex (ok), 10:13, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Это ещё мелочи. Вот когда его ломать начнут...
     
     
  • 3.20, J.L. (?), 11:35, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Это ещё мелочи. Вот когда его ломать начнут...

    поскорее бы, а то скушно читать хейтеров systemd, одна слюна и никакой крошки

     
     
  • 4.23, Аноним (-), 13:14, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +11 +/
    >> Это ещё мелочи. Вот когда его ломать начнут...
    > поскорее бы,

    А что, самостоятельные сломы типа
    https://github.com/systemd/systemd/issues/1143
    > By setting the date to sometime in 2038, we can make systemd getting stuck printing systemd[1]: Time has been changed over and over again.

    или
    https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet (ну да, кто бы мог подумать, что параметр-то пустой будет, а?)
    ну или
    https://github.com/systemd/systemd/issues/5644
    > tmpfiles: R! /dir/.* destroys root

    https://github.com/systemd/systemd/issues/5441
    > Assertion 'path' failed .. Freezing execution

    уже не считаются, да?

    > а то скушно читать хейтеров systemd,

    Так возьмите и почитайте код systemd. Правда, можете сами стать хейтером.
    > одна слюна и никакой крошки

    Одни фантазии поттерофилов и никакой конкретики.

     
     
  • 5.45, Аноним (-), 19:17, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Одни фантазии поттерофилов и никакой конкретики.

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

     

  • 1.11, Аноним (-), 09:55, 12/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ах да, в убунту же сделали гостевой аккаунт. Ещё в релизе 8.10... Так и не затестил. Спасибо что напомнили!
     
     
  • 2.14, Аноним (-), 10:17, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ах да, в убунту же сделали гостевой аккаунт. Ещё в релизе 8.10...
    > Так и не затестил. Спасибо что напомнили!

    Неожиданно вспомнил о нём когда человеку(не случайному) срочно понадобился комп, а дома был ноут с убунтой :)

     
     
  • 3.28, нах (?), 14:32, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Неожиданно вспомнил о нём когда человеку(не случайному) срочно понадобился комп, а дома
    > был ноут с убунтой :)

    боюсь спросить - там adduser поломан уже насовсем, или "не случайному" - в смысле, полицаи пришли, cp искать, и надо было срочно сделать вид, что никаких других юзеров там нет?

     
     
  • 4.33, Аноним (-), 15:23, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >полицаи пришли, cp искать

    И нашли в /bin?

     
     
  • 5.38, Аноним (-), 18:38, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Поттеринг же, теперь cp в /usr/bin. Вот так мы беспалевно храним ЦоПэ в /bin/cp, и никто даже не думает там искать :-)
     
  • 4.50, Аноним (-), 23:44, 16/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да в чем пилять юмор. Я уж и гугол теребил. И в рестриктет шел cp нормально работает.
    Что за фишка с гостевым пользователем и cp?
     

  • 1.47, Аноним (-), 13:50, 15/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Проблема проявляется начиная с Ubuntu 16.10 и вызвана прекращением применения ограничений AppArmor (в Ubuntu 16.04 и более ранних выпусках применялся профиль /usr/lib/lightdm/lightdm-guest-session) после перехода к использованию systemd для управления сеансами.

    А я уже думал на что же переходить с LinuxMint 17 (который на основе 14.04)

    > Linux Mint 18 is based on Ubuntu 16.04.

    Тогда надо брать.

     
  • 1.55, Аноним (55), 22:00, 24/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эта долбанная AppArmor вместо того чтобы защищать систему наоборот позволяет получить доступ над всем сервером на ubuntu и debian злодей 3 раза уже взламывал через нее мой сервер представляясь как кэш полиция Гугла блокируя мои директивы, пристраивая свой кэш и воруя мой трафик, сразу и не заметишь, при этом не позволяя мне отключить ее, приходилось полностью переустанавливать систему и сервер, если бы не отдельный аккаунт на VPS биллинг то полностью бы потерял контроль над сервером. Разработчикам стоит задуматься над этим полуфабрикатом а не запускать ее по умолчанию.
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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