|
2.19, Аноним (-), 21:48, 04/11/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Да что же это такое-то?! Как жить дальше!?
Наверное, как обычно - менять язык программирования.
| |
|
3.20, Led (ok), 21:51, 04/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
> менять пхп/жскрипт/гвидобейсик на язык программирования.
//fixed
| |
|
|
1.2, klalafuda (?), 09:58, 04/11/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
> Таким способом можно прочитать файлы с ключами аутентификации и получить доступ к серверу.
Я наверное что-то не понимаю, но, пардон - каким именно образом? Если тотже апач под которым по всей видимости крутится гитлаб живет из-под www-data. Кто его пустит в /etc/shadow?
PS: Да, читать произвольные файлы на сервере - это не есть хорошо. Но вот чтобы так сразу "получить доступ к серверу" - это видимо перебор.
| |
|
|
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 на другие сервера?
| |
|
|
|
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 че,есть кто то,кто за эти имиджи отвечает и не выбрасывает на докеровскую помойку без гранатий?
| |
|
|
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, а не сборку Васи Пупкина
А в чём, извините, разница-то применительно к рассмотренному случаю?
| |
|
|