The OpenNET Project / Index page

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

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

04.11.2016 09:11

В корректирующих обновлениях платформы для организации совместной разработки GitLab 8.13.3, 8.12.8, 8.11.10 и 8.10.13 устранена критическая уязвимость (CVE-2016-9086), позволяющая аутентифицированному в web-интерфейсе GitLab пользователю получить доступ к произвольным файлам на сервере.

Проблема вызвана ошибкой в реализации функции импорта и экспорта проектов, впервые появившейся в GitLab 8.9 и позволяющей пользователю загрузить файлы своих проектов в форме tar-архива. До версии 8.13 функция была разрешена только администраторам, но после 8.13 стала доступна всем пользователям. Суть уязвимости в некорректной проверке символических ссылок в передаваемом архиве, что позволяет заменить типовые файлы проекта на ссылку на внешний файл и получить доступ к этому файлу.

Например, в архив можно добавить ссылку project.json, указывающую на /etc/passwd и после импорта проекта будет выведена ошибка о некорректности данных JSON, включающая содержимое всего файла. Таким способом можно прочитать файлы с ключами аутентификации и получить доступ к серверу. Всем пользователям рекомендуется срочно обновить GitLab или применить патч. В качестве обходного пути защиты можно отключить в настройках поддержку импорта/экспорта проектов ("Admin Area/Settings/Import Sources/GitLab export").



  1. Главная ссылка к новости (https://about.gitlab.com/2016/...)
  2. OpenNews: В GitLab устранена критическая уязвимость
  3. OpenNews: Доступен Gitlab 8.2 с поддержкой хранилища больших файлов Git LFS
  4. OpenNews: Gitorious закрывается и переходит в руки GitLab
  5. OpenNews: Критические уязвимости в GitLab
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/45427-gitlab
Ключевые слова: gitlab
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Какаянахренразница (ok), 09:57, 04/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да что же это такое-то?! Как жить дальше!?
     
     
  • 2.19, Аноним (-), 21:48, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Да что же это такое-то?! Как жить дальше!?

    Наверное, как обычно - менять язык программирования.

     
     
  • 3.20, Led (ok), 21:51, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > менять пхп/жскрипт/гвидобейсик на язык программирования.

    //fixed

     
     
  • 4.24, Аноним (-), 05:49, 05/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> менять вебмакак на программистов

    //вот теперь fixed


     

  • 1.2, klalafuda (?), 09:58, 04/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Таким способом можно прочитать файлы с ключами аутентификации и получить доступ к серверу.

    Я наверное что-то не понимаю, но, пардон - каким именно образом? Если тотже апач под которым по всей видимости крутится гитлаб живет из-под www-data. Кто его пустит в /etc/shadow?

    PS: Да, читать произвольные файлы на сервере - это не есть хорошо. Но вот чтобы так сразу "получить доступ к серверу" - это видимо перебор.

     
     
  • 2.3, Аноним (-), 10:08, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Имеются в виду SSH-ключи пользователя.
     
     
  • 3.4, Аноним (-), 11:06, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    SSH-ключи пользователя www-data? у которого вообще /bin/false должен быть указан как shell.

    У каким боком SSH ключи к /etc/passwd в новости лично мне непонятно. Мне вообще непонятно, что можно такого принципиально важного найти в этом файле. Понятно, что показывать его напоказ плохо, и понятно, что уязвимость неприятная. Но ничего критического я не вижу

     
     
  • 4.8, angra (ok), 12:01, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    /etc/passwd был использован для примера/доказательства. Это обычная практика при демонстрации уязвимости. Есть много других интересных файликов для атакующего.
     
  • 3.7, angra (ok), 12:00, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А зачем тебе публичная часть ssh ключа? Что ты с ней делать то будешь?
     
     
  • 4.21, Аноним (-), 23:59, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    GitLab по умолчанию устанавливается в /home/git, работает и управляется под пользователем git. Соответственно можно вытянуть и приватные ключи из /home/git/.ssh
     
     
  • 5.22, angra (ok), 03:45, 05/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если они вообще есть. А для чего их используют? Пользователь git ходит по ssh на другие сервера?
     
  • 3.27, Michael Shigorin (ok), 16:25, 05/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Имеются в виду SSH-ключи пользователя.

    А чем грозит доступ к публичному ключу?

     
  • 2.5, Andrew (??), 11:17, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Я наверное что-то не понимаю, но, пардон - каким именно образом? Если тотже апач под которым по всей видимости крутится гитлаб живет из-под www-data. Кто его пустит в /etc/shadow?

    Инструкция по установке GitLab по-умолчанию предлагает использовать nginx. В любом случае, какой бы веб-сервер не использовался, сам GitLab- это отдельный FastCGI процесс, выполняющийся, как правило, с правами пользователя git. Ничего сверъестественного/чувствительного ему в любом случае доступно быть не должно. Ошибка, конечно, неприятная, но на уязвимость не тянет, как мне кажется.

     
     
  • 3.6, angra (ok), 11:58, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если репозиторий публичный с полным доступом для всех, то конечно никаких проблем. В противном случае у атакующего может появится возможность выдать себя за другого пользователя, например через private token для API.

    Хотя если еще подумать, то даже в случае полной открытости есть вкусные вещи. Например сохраненный в конфиге dn и пароль к LDAP.

     
  • 3.25, ПавелС (ok), 08:23, 05/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Я наверное что-то не понимаю, но, пардон - каким именно образом? Если тотже апач под которым по всей видимости крутится гитлаб живет из-под www-data. Кто его пустит в /etc/shadow?
    > Инструкция по установке GitLab по-умолчанию предлагает использовать nginx. В любом случае,
    > какой бы веб-сервер не использовался, сам GitLab- это отдельный FastCGI процесс,
    > выполняющийся, как правило, с правами пользователя git. Ничего сверъестественного/чувствительного
    > ему в любом случае доступно быть не должно. Ошибка, конечно, неприятная,
    > но на уязвимость не тянет, как мне кажется.

    В apache DocumentRoot и все Directory описаны. Разве можно выйти за них? Как это в nginx?

     
     
  • 4.26, ПавелС (ok), 08:27, 05/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Я наверное что-то не понимаю, но, пардон - каким именно образом? Если тотже апач под которым по всей видимости крутится гитлаб живет из-под www-data. Кто его пустит в /etc/shadow?
    >> Инструкция по установке GitLab по-умолчанию предлагает использовать nginx. В любом случае,
    >> какой бы веб-сервер не использовался, сам GitLab- это отдельный FastCGI процесс,
    >> выполняющийся, как правило, с правами пользователя git. Ничего сверъестественного/чувствительного
    >> ему в любом случае доступно быть не должно. Ошибка, конечно, неприятная,
    >> но на уязвимость не тянет, как мне кажется.
    > В apache DocumentRoot и все Directory описаны. Разве можно выйти за них?
    > Как это в nginx?

    А, извиняюсь, понял, символьная ссылка может указывать вне DocumentRoot.

     

  • 1.10, ALex_hha (ok), 12:22, 04/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Кто его пустит в /etc/shadow?

    где вы вообще прочитали про shadow? Доступ можно будет получить к файлам, на которые есть права чтение у пользователя git и/или nginx/www-data, имхо

    > SSH-ключи пользователя www-data? у которого вообще /bin/false должен быть указан как shell.

    раскажите это Canonical

    # docker run ea3214941be1 sh -c 'grep www-data /etc/passwd'
    www-data:x:33:33:www-data:/var/www:/bin/sh

    ea3214941be1 образ на базе ubuntu 12.04

     
     
  • 2.11, angra (ok), 13:24, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    grep www /etc/passwd
    www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

    cat /etc/issue
    Ubuntu 14.04.5 LTS \n \l

    Образ для openvz. Может дело не в Canonical, а в том, кто образ для docker делал?

     
     
  • 3.13, продавец_кирпичиков (?), 16:07, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > grep www /etc/passwd
    > www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
    > cat /etc/issue
    > Ubuntu 14.04.5 LTS \n \l
    > Образ для openvz. Может дело не в Canonical, а в том, кто
    > образ для docker делал?

    A че,есть кто то,кто за эти имиджи отвечает и не выбрасывает на докеровскую помойку без гранатий?

     
     
  • 4.15, АнонимХ (ok), 16:21, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А разьве не понятно, что НЕТ ?
     

  • 1.17, ALex_hha (ok), 17:21, 04/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Может дело не в Canonical, а в том, кто образ для docker делал?

    дело в canonical, образ с их офф репы. И зачем вы приводите выводи с 14.04, когда я писал для 12.04? :)

     
     
  • 2.23, angra (ok), 03:56, 05/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Какой образ был в наличии, в таком и посмотрел. Сейчас загрузил 12.04. Таки да:
    grep www /etc/passwd
    www-data:x:33:33:www-data:/var/www:/bin/sh

    Ну значит четыре года назад было /bin/sh, а два года назад стало /usr/sbin/nologin. Заодно и в debian глянул, там аналогично: debian 7 /bin/sh, debian 8 /usr/sbin/nologin.

     

  • 1.18, ALex_hha (ok), 19:51, 04/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > A че,есть кто то,кто за эти имиджи отвечает и не выбрасывает на докеровскую помойку без гранатий?

    в случае с Ubuntu сам Canonical и отвечает. При условии, что вы используете FROM ubuntu:code-name, а не сборку Васи Пупкина

     
     
  • 2.28, Michael Shigorin (ok), 16:28, 05/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> A че,есть кто то,кто за эти имиджи отвечает и не выбрасывает
    >> на докеровскую помойку без гранатий?
    > в случае с Ubuntu сам Canonical и отвечает. При условии, что вы
    > используете FROM ubuntu:code-name, а не сборку Васи Пупкина

    А в чём, извините, разница-то применительно к рассмотренному случаю?

     

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



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

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