В корректирующих обновлениях платформы для организации совместной разработки GitLab 8.13.3, 8.12.8, 8.11.10 и 8.10.13 устранена (https://about.gitlab.com/2016/11/02/cve-2016-9086-patches/) критическая уязвимость (CVE-2016-9086), позволяющая (https://hackerone.com/reports/178152) аутентифицированному в web-интерфейсе GitLab пользователю получить доступ к произвольным файлам на сервере.Проблема вызвана ошибкой (https://gitlab.com/gitlab-org/gitlab-ce/issues/23822) в реализации функции импорта и экспорта проектов, впервые появившейся в GitLab 8.9 и позволяющей пользователю загрузить файлы своих проектов в форме tar-архива. До версии 8.13 функция была разрешена только администраторам, но после 8.13 стала доступна всем пользователям. Суть уязвимости в некорректной проверке символических ссылок в передаваемом архиве, что позволяет заменить типовые файлы проекта на ссылку на внешний файл и получить доступ к этому файлу.
Например, в архив можно добавить ссылку project.json, указывающую на /etc/passwd и после импорта проекта будет выведена ошибка о некорректности данных JSON, включающая содержимое всего файла. Таким способом можно прочитать файлы с ключами аутентификации и получить доступ к серверу. Всем пользователям рекомендуется срочно обновить GitLab или применить патч (https://gitlab.com/ClemMakesApps/gitlab-ce/commit/dc9b3db8b0...). В качестве обходного пути защиты можно отключить в настройках поддержку импорта/экспорта проектов ("Admin Area/Settings/Import Sources/GitLab export").
URL: https://about.gitlab.com/2016/11/02/cve-2016-9086-patches/
Новость: http://www.opennet.me/opennews/art.shtml?num=45427
Да что же это такое-то?! Как жить дальше!?
> Да что же это такое-то?! Как жить дальше!?Наверное, как обычно - менять язык программирования.
> менять пхп/жскрипт/гвидобейсик на язык программирования.//fixed
>> менять вебмакак на программистов//вот теперь fixed
> Таким способом можно прочитать файлы с ключами аутентификации и получить доступ к серверу.Я наверное что-то не понимаю, но, пардон - каким именно образом? Если тотже апач под которым по всей видимости крутится гитлаб живет из-под www-data. Кто его пустит в /etc/shadow?
PS: Да, читать произвольные файлы на сервере - это не есть хорошо. Но вот чтобы так сразу "получить доступ к серверу" - это видимо перебор.
Имеются в виду SSH-ключи пользователя.
SSH-ключи пользователя www-data? у которого вообще /bin/false должен быть указан как shell.У каким боком SSH ключи к /etc/passwd в новости лично мне непонятно. Мне вообще непонятно, что можно такого принципиально важного найти в этом файле. Понятно, что показывать его напоказ плохо, и понятно, что уязвимость неприятная. Но ничего критического я не вижу
/etc/passwd был использован для примера/доказательства. Это обычная практика при демонстрации уязвимости. Есть много других интересных файликов для атакующего.
А зачем тебе публичная часть ssh ключа? Что ты с ней делать то будешь?
GitLab по умолчанию устанавливается в /home/git, работает и управляется под пользователем git. Соответственно можно вытянуть и приватные ключи из /home/git/.ssh
Если они вообще есть. А для чего их используют? Пользователь git ходит по ssh на другие сервера?
> Имеются в виду SSH-ключи пользователя.А чем грозит доступ к публичному ключу?
> Я наверное что-то не понимаю, но, пардон - каким именно образом? Если тотже апач под которым по всей видимости крутится гитлаб живет из-под www-data. Кто его пустит в /etc/shadow?Инструкция по установке GitLab по-умолчанию предлагает использовать nginx. В любом случае, какой бы веб-сервер не использовался, сам GitLab- это отдельный FastCGI процесс, выполняющийся, как правило, с правами пользователя git. Ничего сверъестественного/чувствительного ему в любом случае доступно быть не должно. Ошибка, конечно, неприятная, но на уязвимость не тянет, как мне кажется.
Если репозиторий публичный с полным доступом для всех, то конечно никаких проблем. В противном случае у атакующего может появится возможность выдать себя за другого пользователя, например через private token для API.Хотя если еще подумать, то даже в случае полной открытости есть вкусные вещи. Например сохраненный в конфиге dn и пароль к LDAP.
>> Я наверное что-то не понимаю, но, пардон - каким именно образом? Если тотже апач под которым по всей видимости крутится гитлаб живет из-под www-data. Кто его пустит в /etc/shadow?
> Инструкция по установке GitLab по-умолчанию предлагает использовать nginx. В любом случае,
> какой бы веб-сервер не использовался, сам GitLab- это отдельный FastCGI процесс,
> выполняющийся, как правило, с правами пользователя git. Ничего сверъестественного/чувствительного
> ему в любом случае доступно быть не должно. Ошибка, конечно, неприятная,
> но на уязвимость не тянет, как мне кажется.В apache DocumentRoot и все Directory описаны. Разве можно выйти за них? Как это в nginx?
>>> Я наверное что-то не понимаю, но, пардон - каким именно образом? Если тотже апач под которым по всей видимости крутится гитлаб живет из-под www-data. Кто его пустит в /etc/shadow?
>> Инструкция по установке GitLab по-умолчанию предлагает использовать nginx. В любом случае,
>> какой бы веб-сервер не использовался, сам GitLab- это отдельный FastCGI процесс,
>> выполняющийся, как правило, с правами пользователя git. Ничего сверъестественного/чувствительного
>> ему в любом случае доступно быть не должно. Ошибка, конечно, неприятная,
>> но на уязвимость не тянет, как мне кажется.
> В apache DocumentRoot и все Directory описаны. Разве можно выйти за них?
> Как это в nginx?А, извиняюсь, понял, символьная ссылка может указывать вне DocumentRoot.
> Кто его пустит в /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/shea3214941be1 образ на базе ubuntu 12.04
grep www /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologincat /etc/issue
Ubuntu 14.04.5 LTS \n \lОбраз для openvz. Может дело не в Canonical, а в том, кто образ для docker делал?
> 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 че,есть кто то,кто за эти имиджи отвечает и не выбрасывает на докеровскую помойку без гранатий?
А разьве не понятно, что НЕТ ?
> Может дело не в Canonical, а в том, кто образ для docker делал?дело в canonical, образ с их офф репы. И зачем вы приводите выводи с 14.04, когда я писал для 12.04? :)
Какой образ был в наличии, в таком и посмотрел. Сейчас загрузил 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.
> A че,есть кто то,кто за эти имиджи отвечает и не выбрасывает на докеровскую помойку без гранатий?в случае с Ubuntu сам Canonical и отвечает. При условии, что вы используете FROM ubuntu:code-name, а не сборку Васи Пупкина
>> A че,есть кто то,кто за эти имиджи отвечает и не выбрасывает
>> на докеровскую помойку без гранатий?
> в случае с Ubuntu сам Canonical и отвечает. При условии, что вы
> используете FROM ubuntu:code-name, а не сборку Васи ПупкинаА в чём, извините, разница-то применительно к рассмотренному случаю?