forum.opennet.ru - "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." (57)

"Уязвимость в Git, Subversion и Mercurial, допускающая подста..."

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+1 +/–
Сообщение от opennews (??) on 11-Авг-17, 09:46
Во всех популярных системах управления версиями, поддерживающих обращение к репозиторию через SSH, выявлена (http://blog.recurity-labs.com/2017-08-10/scm-vulns) уязвимость, позволяющая выполнить любую команду в системе при попытке обработки специально оформленной ссылки на репозиторий с URL "ssh://". Проблема уже устранена в Git 2.14.1-2.7.6 (https://lkml.org/lkml/2017/8/10/757) (CVE-2017-1000117 (https://security-tracker.debian.org/tracker/CVE-2017-1000117)), Subversion 1.9.7 (http://openwall.com/lists/oss-security/2017/08/10/3) (CVE-2017-9800 (https://security-tracker.debian.org/tracker/CVE-2017-9800)) и Mercurial 4.3 (https://www.mercurial-scm.org/wiki/WhatsNew#Mercurial_4.3_.2...) (CVE-2017-1000116 (https://security-tracker.debian.org/tracker/CVE-2017-1000116)), а также в коде GitHub и GitLab (https://about.gitlab.com/2017/08/10/gitlab-9-dot-4-dot-4-rel.../). Не исключено, что уязвимость проявляется и в других приложениях, использующих URL "ssh://". Суть уязвимости сводится к тому, что при обработке URL "ssh://" допускается использование символа "-" вначале имени хоста, что позволяет использовать это имя для передачи опций ssh. Например, указав: git clone ssh://-oProxyCommand=gnome-calculator/wat в качестве имени хоста при запуске ssh будет передана строка "-oProxyCommand", которая будет обработана как опция. Так как через ssh-опцию ProxyCommand можно вызвать дополнительный обработчик установки соединения с сервером, появляется возможность выполнить любую команду в системе (в примере запускается gnome-calculator). URL: http://blog.recurity-labs.com/2017-08-10/scm-vulns Новость: http://www.opennet.me/opennews/art.shtml?num=47005
Ответить \| Правка \| Cообщить модератору

Оглавление

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 09:46 , 11-Авг-17, (1)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Andrey Mitrofanov, 11:06 , 11-Авг-17, (9) +9

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 09:50 , 11-Авг-17, (2) +2
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 09:57 , 11-Авг-17, (4) –1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 10:12 , 11-Авг-17, (5) +5

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 10:24 , 11-Авг-17, (6) –1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 17:20 , 11-Авг-17, (32) +2

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 10:25 , 11-Авг-17, (7) –3

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 17:21 , 11-Авг-17, (33) –1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 17:56 , 11-Авг-17, (34)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., пох, 19:40 , 11-Авг-17, (47) –2

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., pripolz, 18:11 , 11-Авг-17, (37) –1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 19:32 , 11-Авг-17, (43) +1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 19:33 , 11-Авг-17, (44)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., nobody, 11:04 , 11-Авг-17, (8) –3

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Andrey Mitrofanov, 11:11 , 11-Авг-17, (10) +2
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., EHLO, 13:13 , 11-Авг-17, (17) +1
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 15:21 , 11-Авг-17, (27) +2

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 15:19 , 11-Авг-17, (26)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., YetAnotherOnanym, 11:33 , 11-Авг-17, (11)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., пох, 14:54 , 11-Авг-17, (24) +2

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., YetAnotherOnanym, 16:57 , 11-Авг-17, (30)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., пох, 19:15 , 11-Авг-17, (39) –2

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 17:09 , 11-Авг-17, (31) –2

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., omnomnin, 17:59 , 11-Авг-17, (35) +1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 11:34 , 11-Авг-17, (12) +1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., пох, 12:20 , 11-Авг-17, (15) +3

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., mmc, 14:15 , 11-Авг-17, (22) +1
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 15:14 , 11-Авг-17, (25)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., пох, 19:48 , 11-Авг-17, (48)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 15:23 , 11-Авг-17, (28) +1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., пох, 19:19 , 11-Авг-17, (40) –3

Бобби Тейблс негодует, Andrey Mitrofanov, 19:23 , 11-Авг-17, (41) +1
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 19:37 , 11-Авг-17, (45)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., little Boby Tables, 19:56 , 11-Авг-17, (49) –1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., pripolz, 13:41 , 11-Авг-17, (20) –3

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Andrey Mitrofanov, 13:49 , 11-Авг-17, (21) +6
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., ваш К.О., 14:49 , 11-Авг-17, (23) +3
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 09:29 , 12-Авг-17, (52)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 16:32 , 11-Авг-17, (29) –5
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., pripolz, 18:00 , 11-Авг-17, (36) –2

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., пох, 19:30 , 11-Авг-17, (42) –1
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 19:39 , 11-Авг-17, (46) –1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., axredneck, 02:53 , 12-Авг-17, (50) +1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 09:27 , 12-Авг-17, (51)
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 02:30 , 13-Авг-17, (53) –1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 03:54 , 13-Авг-17, (54)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., anonymous, 19:08 , 14-Авг-17, (56)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., пох, 22:03 , 14-Авг-17, (58) –1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 23:33 , 10-Сен-17, (64)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., anonymous, 19:12 , 14-Авг-17, (57) –2
Уязвимость в Git, Subversion и Mercurial, допускающая подста..., пох, 22:18 , 14-Авг-17, (60) –1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Ordu, 07:32 , 13-Авг-17, (55)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., пох, 22:06 , 14-Авг-17, (59) –1

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Ordu, 22:45 , 14-Авг-17, (61)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 10:46 , 02-Сен-17, (62)

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., Аноним, 11:04 , 02-Сен-17, (63)

Сообщения по теме [Сортировка по времени | RSS]

1. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 11-Авг-17, 09:46

>Cloning into 'wat'...
>fatal: strange hostname '-oProxyCommand=gnome-calculator' blocked
Не прокатило...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +9 +/–

Сообщение от Andrey Mitrofanov on 11-Авг-17, 11:06

>>Cloning into 'wat'...
>>fatal: strange hostname '-oProxyCommand=gnome-calculator' blocked
> Не прокатило...
Читер.
--- git-2.13.4/connect.c        2017-08-01 21:56:34.000000000 +0300
+++ git-2.13.5/connect.c        2017-08-09 22:53:15.000000000 +0300
@@ -577,6 +577,11 @@
+       if (looks_like_command_line_option(host))
+               die("strange hostname '%s' blocked", host);
--/bin/bash: line 0: exec: gnome-calculator: не найден

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +2 +/–

Сообщение от Аноним (??) on 11-Авг-17, 09:50

Прокатило, запустился калькулятор. CentOS 7

$ git clone ssh://-oProxyCommand=gnome-calculator/wat
Cloning into 'wat'...
Pseudo-terminal will not be allocated because stdin is not a terminal.
** (gnome-calculator:8332): WARNING **: currency.vala:385: Currency LTL is not provided by IMF or ECB
ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от Аноним (??) on 11-Авг-17, 09:57

Так, наверное, это прокол IETF, прежде всего. А то символ подчёркивания в именах хостов они вообще запретили, а имена хостов начинающиеся с "-" значит можно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +5 +/–

Сообщение от Аноним (??) on 11-Авг-17, 10:12

> Так, наверное, это прокол IETF
Можно подумать, что передача других внешних данных в exec() это нормально. За 20 лет так *ничему* и не научились.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от Аноним (??) on 11-Авг-17, 10:24

Т.е., твое мнение: команды ProxyCommand= быть не должно?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

32. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +2 +/–

Сообщение от Аноним (??) on 11-Авг-17, 17:20

> Т.е., твое мнение: команды ProxyCommand= быть не должно?
Я другой анон, но отвечу тут. Мое мнение, "-oProxyCommand=gnome-calculator" не должно приводить к чему-то кроме запроса хоста, а значит, если оно передается через командную строку, то должно стоять после отсекателя опций "--".

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

7. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –3 +/–

Сообщение от Аноним (??) on 11-Авг-17, 10:25

> Так, наверное, это прокол IETF, прежде всего. А то символ подчёркивания в
> именах хостов они вообще запретили, а имена хостов начинающиеся с "-"
> значит можно.
А при чем здесь IETF?
> Суть уязвимости сводится к тому, что при обработке URL "ssh://" допускается использование > символа "-" вначале имени хоста, что позволяет использовать это имя для передачи опций ssh. Например, указав:
>
>
>    git clone ssh://-oProxyCommand=gnome-calculator/wat
>
> в качестве имени хоста при запуске ssh будет передана строка "-oProxyCommand", которая будет обработана как опция.
Экранировать необходимо, при передаче ssh.
> Так как через ssh-опцию ProxyCommand можно вызвать дополнительный обработчик установки соединения с сервером, появляется возможность выполнить любую команду в системе (в примере запускается gnome-calculator).
Запускает то наверняка с EUID=0!

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

33. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от Аноним (??) on 11-Авг-17, 17:21

> Экранировать необходимо
Головой думать надо, а не экранировать.
Если по хорошему поддерживать использование апстримного git в качестве инструмента обработки левых данных, там вообще нужно 99% кода переписать. Костыли на баше с пёрлом хорошо подходят для работы с локальными доверенными репозиториями, но выставлять их в интернет — дикое безумие.
Что касается тонкостей с git-модулями, — не думаю, что это представляет практическую угрозу. В современных проектах столько скриптов, что при компроментации репозитория любая попытка компиляции проекта мгновенно закончится запуском кода злоумышленника. Да что там, — просто запустил автодополнение по Tab в шелле из папки с репозиторием, и получите-распишитесь.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

34. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 11-Авг-17, 17:56

>> Экранировать необходимо
> Головой думать надо, а не экранировать.
Да, думать надо.
> Если по хорошему поддерживать использование апстримного git в качестве инструмента обработки
> левых данных, там вообще нужно 99% кода переписать. Костыли на баше
> с пёрлом хорошо подходят для работы с локальными доверенными репозиториями, но
> выставлять их в интернет — дикое безумие.
99%, ничего скоро зима.
> Что касается тонкостей с git-модулями, — не думаю, что это представляет практическую
> угрозу. В современных проектах столько скриптов, что при компроментации репозитория любая
> попытка компиляции проекта мгновенно закончится запуском кода злоумышленника. Да что там,
> — просто запустил автодополнение по Tab в шелле из папки с
> репозиторием, и получите-распишитесь.
Согласен. По этому безопаснее работать обычным пользователем. Правда остается make install, так как код никто не смотрел :(

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

47. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –2 +/–

Сообщение от пох on 11-Авг-17, 19:40

> Согласен. По этому безопаснее работать обычным пользователем. Правда остается make
в моих системах ровно _ноль_ важных данных, принадлежащих не этому "обычному пользователю".
не говоря уже о вечном "inotify", когда рут на самом деле достается за пару секунд и одно обращение к клону metasploit, так что даже если вы необычный пользователь и имеете привычку даже банальный git pull дергать от nobody/special-git-runner, вас это вряд ли спасет.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

37. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от pripolz on 11-Авг-17, 18:11

> В современных проектах столько скриптов, что при компроментации репозитория любая
> попытка компиляции проекта мгновенно закончится запуском кода злоумышленника.
Попытка компиляции - это уже после. Тут ты ловишь эксплойт ещё на этапе скачивания. Что несколько более смачно.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

43. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +1 +/–

Сообщение от Аноним (??) on 11-Авг-17, 19:32

> Экранировать необходимо, при передаче ssh.
Что экранировать, дефис? Так он правильно воспринимается. Просто такое имя хоста в принципе не должно передаваться ssh, потому что не является валидным. Ну и, как уже написали, после -- должно идти.
> Запускает то наверняка с EUID=0!
Если ты запускаешь ssh-клиент с EUID=0, то да. Только зачем ты это делаешь?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

44. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 11-Авг-17, 19:33

> Если ты запускаешь ssh-клиент с EUID=0, то да.
Точнее, запускаешь с EUID=0 git, который запускает ssh-клиент.

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

8. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –3 +/–

Сообщение от nobody (??) on 11-Авг-17, 11:04

> А то символ подчёркивания в именах хостов они вообще запретили
Причём тут подчёркивание вообще? Дефис - нормальный символ в имени хоста: open-std.org

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

10. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +2 +/–

Сообщение от Andrey Mitrofanov on 11-Авг-17, 11:11

>> А то символ подчёркивания в именах хостов они вообще запретили
> Причём тут подчёркивание вообще? Дефис - нормальный символ в имени хоста: open-std.org
Боль системдешников от s-d-resolved, к которым "прилетело" от их фетиша...>http://www.opennet.me/opennews/art.shtml?num=46905

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

17. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +1 +/–

Сообщение от EHLO on 11-Авг-17, 13:13

>Дефис - нормальный символ в имени хоста: open-std.org
не в начале имени. КО

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

27. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +2 +/–

Сообщение от Аноним (??) on 11-Авг-17, 15:21

> Дефис - нормальный символ в имени хоста: open-std.org
Нормальный, если он не первый и не последний. Читай RFC.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

26. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 11-Авг-17, 15:19

> Так, наверное, это прокол IETF, прежде всего.
Может сначала RFC3986 глянешь, а потом уже будешь на IETF наезжать?
   Such a name consists of a sequence of domain labels separated by ".",
   each domain label starting and ending with an alphanumeric character
   and possibly also containing "-" characters.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

11. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от YetAnotherOnanym (ok) on 11-Авг-17, 11:33

Так всегда бывает, когда для каких-то целей используется команда с избыточной функциональностью. Странно, что до сих пор не изобрели какой-нибудь EunuchSSH специально для таких целей. Тем, кто хочет ткнуть меня носом в rssh, отвечу заранее - это restricted shell for ssh, а не вариант ssh с урезанными возможностями.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

24. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +2 +/–

Сообщение от пох on 11-Авг-17, 14:54

> Так всегда бывает, когда для каких-то целей используется команда с избыточной
> функциональностью.
тебе надо выполнить некую команду на стороне сервера. Программа для этой задачи, используемая повсеместно - ssh (если, конечно, тебе не больше  нравится rsh). Скорее побочной фичей является встроенная в него замена telnet (и она-то отключается).
героически урезать ему возможности - бесполезная гонка за призраками.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

30. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от YetAnotherOnanym (ok) on 11-Авг-17, 16:57

> тебе надо выполнить некую команду на стороне сервера
В данном случае вопрос в том, чтобы не была выполнена нежелательная команда на стороне клиента.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

39. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –2 +/–

Сообщение от пох on 11-Авг-17, 19:15

> В данном случае вопрос в том, чтобы не была выполнена нежелательная команда на стороне
> клиента.
от этого никуда не убежишь - слишком много ситуаций, когда требуется передавать аргументы.
Контролировать это должен был код, вызывающий remote exec, а вот он-то у нас... мда...
ну ладно, теперь они хотя бы минус в начале строки научились проверять. Не прошло и пятнадцати лет (когда там Линус разоcрался с биткиперами?)

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

31. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –2 +/–

Сообщение от Аноним (??) on 11-Авг-17, 17:09

Давно изобрели — используй любую из 9000 сторонних SHH-библиотек и всё ок. Проверил, — в sshj.jar бага не воспроизводится.
Просто разработчики Git и Subversion в страшном сне не могли представить, что их под**ие будет напрямую вызываться из скриптов в потрохах какого-нибудь Gitlab. А гитлабовцы, как истинные PHP разработчики, верили, что все вокруг более продвинутые, и экранировать входные данные не нужно — git же это сделает за них!

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

35. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +1 +/–

Сообщение от omnomnin on 11-Авг-17, 17:59

>А гитлабовцы, как истинные PHP разработчики, верили, что все вокруг более продвинутые, и экранировать входные данные не нужно — git же это сделает за них!
гитлабовцы ващета руби-на-рельсах хипстеры, но сути это не меняет да

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

12. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +1 +/–

Сообщение от Аноним (??) on 11-Авг-17, 11:34

> при обработке URL "ssh://" допускается использование символа "-" вначале имени хоста
Так уязвимость в гите или в стандартах на урлы вида ssh:// ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +3 +/–

Сообщение от пох on 11-Авг-17, 12:20

очевидно, в гите - какого хрена я не могу назвать свой хост -oProxyCommand=gnome-calculator  ?
Метод, которым они эту уязвимость "победили" - должен бы, по идее, заставить задуматься о состоянии их мозга (тех, у кого еще осталась надежда, что там есть мозги)

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

22. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +1 +/–

Сообщение от mmc (??) on 11-Авг-17, 14:15

> какого хрена я не могу назвать свой хост -oProxyCommand=gnome-calculator  ?
скорее всего, имя уже занято
можно использовать "-oProxyCommand=gnome-calculator(2)"

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

25. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 11-Авг-17, 15:14

В mercurial почти так же https://www.mercurial-scm.org/repo/hg/rev/739cc0f9cbb4

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

48. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от пох on 11-Авг-17, 19:48

> В mercurial почти так же https://www.mercurial-scm.org/repo/hg/rev/739cc0f9cbb4
This paranoia probably isn't required, but it can't hurt either.
то есть они совсем не уверены, что кто-то может такое вызвать и что оно вообще-то в их системе сработает. microsoft, кстати, отдает нынче "site maintenance", причем с неправильным mime-type. Совпадение? ДА, совпадение!

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

28. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +1 +/–

Сообщение от Аноним (??) on 11-Авг-17, 15:23

> очевидно, в гите - какого хрена я не могу назвать свой хост
> -oProxyCommand=gnome-calculator  ?
Не можешь, потому что стандарт не разрешает. ни дефис в начале, ни = где бы то ни было.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

40. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –3 +/–

Сообщение от пох on 11-Авг-17, 19:19

>> очевидно, в гите - какого хрена я не могу назвать свой хост
>> -oProxyCommand=gnome-calculator  ?
> Не можешь, потому что стандарт не разрешает. ни дефис в начале, ни
> = где бы то ни было.
провижу массу интересных ремоут-хаков на теме того, что "у нас не принято, а у иностранцев с прилипшей к жопе табуреткой - не проверяется".
очень может быть что даже в gtld каком-нибудь не проверяется, а уж третьего-то уровня домен создать - фигня вопрос.
это ж тоже была наивная (ибо год на дворе такой стоял) прокладка на тему "мы конечно знаем, что программисты рукожопые, давайте попробуем хотя бы административно ограничить", никакими техническими причинами не вызванная.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

41. "Бобби Тейблс негодует" +1 +/–

Сообщение от Andrey Mitrofanov on 11-Авг-17, 19:23

> провижу массу интересных ремоут-хаков на теме того,
"--Маленький Бобби Тейблс, как мы его зовём..."
> очень может быть что даже в gtld каком-нибудь не проверяется, а уж
> третьего-то уровня домен создать - фигня вопрос.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

45. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 11-Авг-17, 19:37

> очень может быть что даже в gtld каком-нибудь не проверяется, а уж
> третьего-то уровня домен создать - фигня вопрос.
Создай и продемонстрируй, тогда поговорим.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

49. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от little Boby Tables on 11-Авг-17, 19:56

> Создай и продемонстрируй, тогда поговорим.
etc/bind# rndc reload local
zone reload queued
etc/bind# tail /var/log/messages
Aug 11 19:48:31  named[2484]: received control channel command 'reload local'
Aug 11 19:48:31  named[2484]: zone local/IN: loaded serial 38
etc/bind# nslookup
> -oProxyCommand=gnome-calculator
Server:         127.0.0.1
Address:        127.0.0.1#53
-oProxyCommand=gnome-calculator.local   canonical name = localhost.local.
Name:   localhost.local
Address: 127.0.0.1
в чем проблема-то?
(только не надо мне про rendezvous, эта зона так называлась за пять лет до изобретения эплом той херни)
Разумеется, я могу завести такую запись и в любом реальном домене, который легально делегирован на мой ns.

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

20. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –3 +/–

Сообщение от pripolz on 11-Авг-17, 13:41

а зачем вообще гиту ssh ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +6 +/–

Сообщение от Andrey Mitrofanov on 11-Авг-17, 13:49

> а зачем вообще гиту ssh ?
Вместо smb://. Очевидно же!!

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

23. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +3 +/–

Сообщение от ваш К.О. on 11-Авг-17, 14:49

не все хотят торчать в инет еще одним кривым сервисом.
не все хотят настраивать веб-прокси с кривой аутентификацией - в еще один кривой сервис.
а возможность удаленной _записи_ в репо - нужна почти всем.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

52. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 12-Авг-17, 09:29

> а зачем вообще гиту ssh ?
Потому, что в голом git ( gitd ) вообще нет авторизации. Она реализуется сторонними средствами. Например, ssh + gitolite

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

29. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –5 +/–

Сообщение от Аноним (??) on 11-Авг-17, 16:32

Это не баг, а фича.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –2 +/–

Сообщение от pripolz on 11-Авг-17, 18:00

Нормальный такой нежданчик всё-таки.
Просто клонировал себе репозиторий.
Получил "rm -rf /" в submodules.
или какой-нить эксплойт на inotify..
Это ещё даже до компиляции.
Что дальше? Окажется, что wget тоже через ssh чудить умеет?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от пох on 11-Авг-17, 19:30

> Нормальный такой нежданчик всё-таки.
да ну, ожидаемый, на самом деле...
> Что дальше? Окажется, что wget тоже через ssh чудить умеет?
а зачем ему, он-то и через http неплохо могет.
https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...
(хм-хм... кстати, о git...)

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

46. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от Аноним (??) on 11-Авг-17, 19:39

> Просто клонировал себе репозиторий.
> Получил "rm -rf /" в submodules.
Ты клонируешь репозитории под рутом? Может и perl-одностроки под ним запускаешь?

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

50. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +1 +/–

Сообщение от axredneck on 12-Авг-17, 02:53

"rm -rf /" и без рута может дров наломать

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

51. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 12-Авг-17, 09:27

> Суть уязвимости сводится к тому, что при обработке URL "ssh://" допускается использование символа "-" вначале имени хоста, что позволяет использовать это имя для передачи опций ssh. Например, указав:
Я правильно понимаю, что параметр передаётся _ВМЕСТО_ имени хоста и это по сути локальная уязвимость?
Или, точнее, это атака на хост клиента, который клонирует репозиторий не глядя на url?
Плюс gnome-calculator это конечно хорошо, но без pseudo-terminal нужно постараться выполнить команду так, чтобы она нанесла вред. я в курсе про почти нормальную работу через ssh -T, но тут немного специфичнее:
$ git clone ssh://-oProxyCommand=bash/wat
Клонирование в «wat»…
Pseudo-terminal will not be allocated because stdin is not a terminal.
bash: строка 1: SSH-2.0-OpenSSH_7.2p2: команда не найдена
ls
uname
^C

> Атака осуществлялась через размещение в репозитории файла .lfsconfig, в котором в качестве пути к LFS-хранилищу применялась конструкция вида "url = ssh://-oProxyCommand=some-command". Метод позволяет организовать выполнение произвольного кода на стороне клиентов, клонировавших репозиторий с подобным файлом, при наличии у них плагина Git LFS
Вот это гораздо интереснее. Тут уже не нужен обезумевший от бессонницы пользователь, достаточно дырявого модуля...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

53. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от Аноним (??) on 13-Авг-17, 02:30

Смотрю я на все эти уязвимости и у меня вопрос доколе будут делать все монолитом. Я лично этим svn+ssh пользовался 1 раз в жизни. Почему нельзя например сделать было просто svns (svn over ssl)? Что с XML уязвимость была смешная что тут ... Такое чувство что назло и специально делают кривые и уязвимые программы... Расстроен... Можно же было сделать ssh через плагины или вообще не делать ...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

54. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 13-Авг-17, 03:54

Потому что Торвальдс не эксперт по безопасности. Он использовал самый простой путь. Нормально в SSL/TLS могут лишь профи, которым это интересно. Те, кто недоросли до TLS используют STARTTLS, хотя он тоже не лишен недостатков.
И нужно еще не забыть, что все текущие свободные реализации TLS имеют херову тучу багов. Поэтому, чтобы сделать что-то реально защищенное и стабильное нужны знания, опыт и куча времени (если нет первых двух).
И да, ща набежит школота, которая скажет, что TLS прикрутить может любой студентик. Прикрутить-то он сможет, а на деле будет дырявое п0делие, которое никому нафиг не сдалось. Старая песня.

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

56. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от anonymous (??) on 14-Авг-17, 19:08

Иксперд, ты же в курсе, что в самом git вообще не предусмотрено ни шифрования, ни авторизации, и эти задачи по определению перекладываются на внешние средства?
Ты говоришь про ssh так, будто в git встроена реализация ssh или хотя бы ssh клиента. Хотя на само деле git работает внутри ssh туннеля
Ты говоришь про ssl, будто не знаешь, что кроме работы внутри ssh туннеля git так же прекрасно работает внутри любого другого защищённого туннеля. В том числе - через любой веб-сервер, настроенный с поддержкой кошерного TLS 1.2
Не путай тёплое с мягким, и над тобой не будут смеяться
Про идеологию unix что-нибудь слышал? git решает одну задачу и решает его хорошо. Авторизацию и шифрование обеспечивает другое ПО, с которым git взаимодействует

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

58. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от пох on 14-Авг-17, 22:03

> Иксперд, ты же в курсе, что в самом git вообще не предусмотрено ни шифрования, ни
он вероятно как раз в курсе, и здраво относит это к банальному неумению линуса и компании сделать хорошо и надежно. Что, конечно, не грех для средней руки менеджера и программиста, но, постойте-постойте...
> авторизации, и эти задачи по определению перекладываются на внешние средства?
одна проблема - даже этими внешними средствами он пользуется через задницу (потому что "авторизация" через ssh сваливает всех внешних юзеров в одну кучу, слепо доверяя тому, что они о себе напишут внутри незащищенного и лишенного минимальной авторизации git-протокола - вот и гадай потом по таймстемпам, хто насрав - даже subversion еще умел при этом отдельно различать юзеров, но не подeлие линуса - потому что он, не умея пользоваться vcs, и категорически не желая учиться, годами принимал патчи в почту, и гит написан для автоматизации именно этой работы, а удаленный доступ к репо приделан на соплях левой задней ногой).
и остаются либо сны разума вроде гитлаба, либо самодельная авторизация через веб+ssl, которую сделать хорошо, надежно и удобно не получится при всем желании, но при совсем ненулевой грамотности и затратах времени можно хотя бы любые два.
справедливости ради - у hg такая же точно херня (ибо копипастили понятен откуда, зато-на-пихоне), и гитлаба для нее нет и не будет никогда. B общем-то поляна и загажена уже...

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

64. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 10-Сен-17, 23:33

> он вероятно как раз в курсе, и здраво относит это к банальному неумению линуса и компании сделать хорошо и надежно
Это не "здраво", а как раз "больная фантазия фанатика". Иди ещё раз кури идеологию UNIX
> дна проблема - даже этими внешними средствами он пользуется через задницу (потому что "авторизация" через ssh сваливает всех внешних юзеров в одну кучу,
Да ёмаё, ты похоже вообще не в курсе, как работает ssh. В такой ситуации рассказывать тебе про gitolite бесполезно
Если ты болезный ни разу в жизни не настраивал авторизацию для доступа к git, не надо нести бред в массы - кури доки

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

57. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –2 +/–

Сообщение от anonymous (??) on 14-Авг-17, 19:12

На вот, почитай  https://git-scm.com/book/en/v2

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

60. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от пох on 14-Авг-17, 22:18

> Потому что Торвальдс не эксперт по безопасности. Он использовал самый простой путь.
он использовал самый кривой путь, какой только можно - и теперь, к сожалению, это стандарт навеки.
> Нормально в SSL/TLS могут лишь профи, которым это интересно. Те, кто
нормально в ssl уметь не надо - stunnel (если уж вштырило ssl) или https о тебе позаботится.
Нормальная не-плэйнтекст авторизация и нормальная аутентификация, с нормальным разделением пользователей - без всякого криптотуннеля (если мне понадобится, туннель я сделаю без вас, на проверенных и надежных технологиях, а коммиты в паблик гитрепо вообще незачем прятать - но очень даже есть зачем точно знать кто коммитил) - это вот то, что никакой ssl за тебя не сделает.
Увы, что-то похожее есть разьве что в mysql, ни одной vcs с таким функционалом мне вообще неизвестно.
Все остальные либо тупейшим образом полагаются на внешние обертки, которые вовсе для этой цели не предназначены, и которые, к тому же, не умеют правильно готовить, как в данном случае, либо, как в svn, в них есть и аутентификация и разделение полномочий, но все эти замки - исключительно от честных людей.

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

55. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Ordu (ok) on 13-Авг-17, 07:32

> Я лично этим svn+ssh пользовался 1 раз в жизни.
_git_ + ssh?
> Можно же было сделать ssh через плагины или вообще не делать ...
Какая тебе разница? Если ты не пользуешься git over ssh, то тебя эта уязвимость вообще никак не затрагивает. А если ты пользуешься, то она тебя затронет вне зависимости от того, будет ли поддержка ssh в плагине или в основной коде.

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

59. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." –1 +/–

Сообщение от пох on 14-Авг-17, 22:06

> Какая тебе разница? Если ты не пользуешься git over ssh, то тебя
> эта уязвимость вообще никак не затрагивает. А если ты пользуешься, то
затрагивает - subrepo на сервере (своем или гитхабе) может "попользоваться" без твоего ведома.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

61. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Ordu (ok) on 14-Авг-17, 22:45

>> Какая тебе разница? Если ты не пользуешься git over ssh, то тебя
>> эта уязвимость вообще никак не затрагивает. А если ты пользуешься, то
> затрагивает - subrepo на сервере (своем или гитхабе) может "попользоваться" без твоего
> ведома.
При чём тут "с ведома"? Если тебе понадобился ssh плагин, а его у тебя нет, то тебе придётся его ставить. Плагин, в данном случае -- это не более чем иллюзия контроля.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

62. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 02-Сен-17, 10:46

только что проверил на ansible, тоже работает
Глобальная проблема то

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

63. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..." +/–

Сообщение от Аноним (??) on 02-Сен-17, 11:04

указал в hosts
"-oProxyCommand=gnome-calculator -m advanced"
Работает, в ковычках можно даже параметры указать

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
Сообщение от Аноним (??) on 11-Авг-17, 09:46
>Cloning into 'wat'... >fatal: strange hostname '-oProxyCommand=gnome-calculator' blocked Не прокатило...
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	9. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+9 +/–
	Сообщение от Andrey Mitrofanov on 11-Авг-17, 11:06
	>>Cloning into 'wat'... >>fatal: strange hostname '-oProxyCommand=gnome-calculator' blocked > Не прокатило... Читер. --- git-2.13.4/connect.c 2017-08-01 21:56:34.000000000 +0300 +++ git-2.13.5/connect.c 2017-08-09 22:53:15.000000000 +0300 @@ -577,6 +577,11 @@ + if (looks_like_command_line_option(host)) + die("strange hostname '%s' blocked", host); --/bin/bash: line 0: exec: gnome-calculator: не найден
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

2. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+2 +/–
Сообщение от Аноним (??) on 11-Авг-17, 09:50
Прокатило, запустился калькулятор. CentOS 7 $ git clone ssh://-oProxyCommand=gnome-calculator/wat Cloning into 'wat'... Pseudo-terminal will not be allocated because stdin is not a terminal. (gnome-calculator:8332): WARNING : currency.vala:385: Currency LTL is not provided by IMF or ECB ssh_exchange_identification: Connection closed by remote host fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

4. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–1 +/–
Сообщение от Аноним (??) on 11-Авг-17, 09:57
Так, наверное, это прокол IETF, прежде всего. А то символ подчёркивания в именах хостов они вообще запретили, а имена хостов начинающиеся с "-" значит можно.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	5. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+5 +/–
	Сообщение от Аноним (??) on 11-Авг-17, 10:12
	> Так, наверное, это прокол IETF Можно подумать, что передача других внешних данных в exec() это нормально. За 20 лет так ничему и не научились.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–1 +/–
	Сообщение от Аноним (??) on 11-Авг-17, 10:24
	Т.е., твое мнение: команды ProxyCommand= быть не должно?
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	32. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+2 +/–
	Сообщение от Аноним (??) on 11-Авг-17, 17:20
	> Т.е., твое мнение: команды ProxyCommand= быть не должно? Я другой анон, но отвечу тут. Мое мнение, "-oProxyCommand=gnome-calculator" не должно приводить к чему-то кроме запроса хоста, а значит, если оно передается через командную строку, то должно стоять после отсекателя опций "--".
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	7. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–3 +/–
	Сообщение от Аноним (??) on 11-Авг-17, 10:25
	> Так, наверное, это прокол IETF, прежде всего. А то символ подчёркивания в > именах хостов они вообще запретили, а имена хостов начинающиеся с "-" > значит можно. А при чем здесь IETF? > Суть уязвимости сводится к тому, что при обработке URL "ssh://" допускается использование > символа "-" вначале имени хоста, что позволяет использовать это имя для передачи опций ssh. Например, указав: > > > git clone ssh://-oProxyCommand=gnome-calculator/wat > > в качестве имени хоста при запуске ssh будет передана строка "-oProxyCommand", которая будет обработана как опция. Экранировать необходимо, при передаче ssh. > Так как через ssh-опцию ProxyCommand можно вызвать дополнительный обработчик установки соединения с сервером, появляется возможность выполнить любую команду в системе (в примере запускается gnome-calculator). Запускает то наверняка с EUID=0!
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	33. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–1 +/–
	Сообщение от Аноним (??) on 11-Авг-17, 17:21
	> Экранировать необходимо Головой думать надо, а не экранировать. Если по хорошему поддерживать использование апстримного git в качестве инструмента обработки левых данных, там вообще нужно 99% кода переписать. Костыли на баше с пёрлом хорошо подходят для работы с локальными доверенными репозиториями, но выставлять их в интернет — дикое безумие. Что касается тонкостей с git-модулями, — не думаю, что это представляет практическую угрозу. В современных проектах столько скриптов, что при компроментации репозитория любая попытка компиляции проекта мгновенно закончится запуском кода злоумышленника. Да что там, — просто запустил автодополнение по Tab в шелле из папки с репозиторием, и получите-распишитесь.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	34. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от Аноним (??) on 11-Авг-17, 17:56
	>> Экранировать необходимо > Головой думать надо, а не экранировать. Да, думать надо. > Если по хорошему поддерживать использование апстримного git в качестве инструмента обработки > левых данных, там вообще нужно 99% кода переписать. Костыли на баше > с пёрлом хорошо подходят для работы с локальными доверенными репозиториями, но > выставлять их в интернет — дикое безумие. 99%, ничего скоро зима. > Что касается тонкостей с git-модулями, — не думаю, что это представляет практическую > угрозу. В современных проектах столько скриптов, что при компроментации репозитория любая > попытка компиляции проекта мгновенно закончится запуском кода злоумышленника. Да что там, > — просто запустил автодополнение по Tab в шелле из папки с > репозиторием, и получите-распишитесь. Согласен. По этому безопаснее работать обычным пользователем. Правда остается make install, так как код никто не смотрел :(
	Ответить \| Правка \| ^ к родителю #33 \| Наверх \| Cообщить модератору


	47. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–2 +/–
	Сообщение от пох on 11-Авг-17, 19:40
	> Согласен. По этому безопаснее работать обычным пользователем. Правда остается make в моих системах ровно _ноль_ важных данных, принадлежащих не этому "обычному пользователю". не говоря уже о вечном "inotify", когда рут на самом деле достается за пару секунд и одно обращение к клону metasploit, так что даже если вы необычный пользователь и имеете привычку даже банальный git pull дергать от nobody/special-git-runner, вас это вряд ли спасет.
	Ответить \| Правка \| ^ к родителю #34 \| Наверх \| Cообщить модератору


	37. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–1 +/–
	Сообщение от pripolz on 11-Авг-17, 18:11
	> В современных проектах столько скриптов, что при компроментации репозитория любая > попытка компиляции проекта мгновенно закончится запуском кода злоумышленника. Попытка компиляции - это уже после. Тут ты ловишь эксплойт ещё на этапе скачивания. Что несколько более смачно.
	Ответить \| Правка \| ^ к родителю #33 \| Наверх \| Cообщить модератору


	43. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+1 +/–
	Сообщение от Аноним (??) on 11-Авг-17, 19:32
	> Экранировать необходимо, при передаче ssh. Что экранировать, дефис? Так он правильно воспринимается. Просто такое имя хоста в принципе не должно передаваться ssh, потому что не является валидным. Ну и, как уже написали, после -- должно идти. > Запускает то наверняка с EUID=0! Если ты запускаешь ssh-клиент с EUID=0, то да. Только зачем ты это делаешь?
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	44. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от Аноним (??) on 11-Авг-17, 19:33
	> Если ты запускаешь ssh-клиент с EUID=0, то да. Точнее, запускаешь с EUID=0 git, который запускает ssh-клиент.
	Ответить \| Правка \| ^ к родителю #43 \| Наверх \| Cообщить модератору


	8. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–3 +/–
	Сообщение от nobody (??) on 11-Авг-17, 11:04
	> А то символ подчёркивания в именах хостов они вообще запретили Причём тут подчёркивание вообще? Дефис - нормальный символ в имени хоста: open-std.org
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	10. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 11-Авг-17, 11:11
	>> А то символ подчёркивания в именах хостов они вообще запретили > Причём тут подчёркивание вообще? Дефис - нормальный символ в имени хоста: open-std.org Боль системдешников от s-d-resolved, к которым "прилетело" от их фетиша...>http://www.opennet.me/opennews/art.shtml?num=46905
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	17. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+1 +/–
	Сообщение от EHLO on 11-Авг-17, 13:13
	>Дефис - нормальный символ в имени хоста: open-std.org не в начале имени. КО
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	27. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+2 +/–
	Сообщение от Аноним (??) on 11-Авг-17, 15:21
	> Дефис - нормальный символ в имени хоста: open-std.org Нормальный, если он не первый и не последний. Читай RFC.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	26. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от Аноним (??) on 11-Авг-17, 15:19
	> Так, наверное, это прокол IETF, прежде всего. Может сначала RFC3986 глянешь, а потом уже будешь на IETF наезжать? Such a name consists of a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumeric character and possibly also containing "-" characters.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору

11. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
Сообщение от YetAnotherOnanym (ok) on 11-Авг-17, 11:33
Так всегда бывает, когда для каких-то целей используется команда с избыточной функциональностью. Странно, что до сих пор не изобрели какой-нибудь EunuchSSH специально для таких целей. Тем, кто хочет ткнуть меня носом в rssh, отвечу заранее - это restricted shell for ssh, а не вариант ssh с урезанными возможностями.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	24. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+2 +/–
	Сообщение от пох on 11-Авг-17, 14:54
	> Так всегда бывает, когда для каких-то целей используется команда с избыточной > функциональностью. тебе надо выполнить некую команду на стороне сервера. Программа для этой задачи, используемая повсеместно - ssh (если, конечно, тебе не больше нравится rsh). Скорее побочной фичей является встроенная в него замена telnet (и она-то отключается). героически урезать ему возможности - бесполезная гонка за призраками.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	30. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от YetAnotherOnanym (ok) on 11-Авг-17, 16:57
	> тебе надо выполнить некую команду на стороне сервера В данном случае вопрос в том, чтобы не была выполнена нежелательная команда на стороне клиента.
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	39. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–2 +/–
	Сообщение от пох on 11-Авг-17, 19:15
	> В данном случае вопрос в том, чтобы не была выполнена нежелательная команда на стороне > клиента. от этого никуда не убежишь - слишком много ситуаций, когда требуется передавать аргументы. Контролировать это должен был код, вызывающий remote exec, а вот он-то у нас... мда... ну ладно, теперь они хотя бы минус в начале строки научились проверять. Не прошло и пятнадцати лет (когда там Линус разоcрался с биткиперами?)
	Ответить \| Правка \| ^ к родителю #30 \| Наверх \| Cообщить модератору


	31. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–2 +/–
	Сообщение от Аноним (??) on 11-Авг-17, 17:09
	Давно изобрели — используй любую из 9000 сторонних SHH-библиотек и всё ок. Проверил, — в sshj.jar бага не воспроизводится. Просто разработчики Git и Subversion в страшном сне не могли представить, что их под**ие будет напрямую вызываться из скриптов в потрохах какого-нибудь Gitlab. А гитлабовцы, как истинные PHP разработчики, верили, что все вокруг более продвинутые, и экранировать входные данные не нужно — git же это сделает за них!
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	35. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+1 +/–
	Сообщение от omnomnin on 11-Авг-17, 17:59
	>А гитлабовцы, как истинные PHP разработчики, верили, что все вокруг более продвинутые, и экранировать входные данные не нужно — git же это сделает за них! гитлабовцы ващета руби-на-рельсах хипстеры, но сути это не меняет да
	Ответить \| Правка \| ^ к родителю #31 \| Наверх \| Cообщить модератору

12. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+1 +/–
Сообщение от Аноним (??) on 11-Авг-17, 11:34
> при обработке URL "ssh://" допускается использование символа "-" вначале имени хоста Так уязвимость в гите или в стандартах на урлы вида ssh:// ?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	15. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+3 +/–
	Сообщение от пох on 11-Авг-17, 12:20
	очевидно, в гите - какого хрена я не могу назвать свой хост -oProxyCommand=gnome-calculator ? Метод, которым они эту уязвимость "победили" - должен бы, по идее, заставить задуматься о состоянии их мозга (тех, у кого еще осталась надежда, что там есть мозги)
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	22. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+1 +/–
	Сообщение от mmc (??) on 11-Авг-17, 14:15
	> какого хрена я не могу назвать свой хост -oProxyCommand=gnome-calculator ? скорее всего, имя уже занято можно использовать "-oProxyCommand=gnome-calculator(2)"
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	25. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от Аноним (??) on 11-Авг-17, 15:14
	В mercurial почти так же https://www.mercurial-scm.org/repo/hg/rev/739cc0f9cbb4
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	48. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от пох on 11-Авг-17, 19:48
	> В mercurial почти так же https://www.mercurial-scm.org/repo/hg/rev/739cc0f9cbb4 This paranoia probably isn't required, but it can't hurt either. то есть они совсем не уверены, что кто-то может такое вызвать и что оно вообще-то в их системе сработает. microsoft, кстати, отдает нынче "site maintenance", причем с неправильным mime-type. Совпадение? ДА, совпадение!
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору