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

Уязвимость в Git, Subversion и Mercurial, допускающая подста..., opennews (??), 11-Авг-17, (0) [смотреть все] +1 Не прокатило , Аноним (-), 09:46 , 11-Авг-17, (1) // Читер CODE --- git-2 13 4 connect c 2017-08-01 21 56 34 000000000 0300 , Andrey Mitrofanov (?), 11:06 , 11-Авг-17, (9) +9 Прокатило, запустился калькулятор CentOS 7 git clone ssh -oProxyCommand gnom, Аноним (-), 09:50 , 11-Авг-17, (2) +2 Так, наверное, это прокол IETF, прежде всего А то символ подчёркивания в именах, Аноним (-), 09:57 , 11-Авг-17, (4) –1 // Можно подумать, что передача других внешних данных в exec это нормально За 20, Аноним (-), 10:12 , 11-Авг-17, (5) +5 // Т е , твое мнение команды ProxyCommand быть не должно , Аноним (-), 10:24 , 11-Авг-17, (6) –1 // Я другой анон, но отвечу тут Мое мнение, -oProxyCommand gnome-calculator не д, Аноним (-), 17:20 , 11-Авг-17, (32) +2 А при чем здесь IETF Экранировать необходимо, при передаче ssh Запускает то наве, Аноним (-), 10:25 , 11-Авг-17, (7) –3 // Головой думать надо, а не экранировать Если по хорошему поддерживать использован, Аноним (-), 17:21 , 11-Авг-17, (33) –1 // Да, думать надо 99 , ничего скоро зима Согласен По этому безопаснее работать об, Аноним (-), 17:56 , 11-Авг-17, (34) в моих системах ровно _ноль_ важных данных, принадлежащих не этому обычному пол, пох (?), 19:40 , 11-Авг-17, (47) –2 Попытка компиляции - это уже после Тут ты ловишь эксплойт ещё на этапе скачиван, pripolz (?), 18:11 , 11-Авг-17, (37) –1 Что экранировать, дефис Так он правильно воспринимается Просто такое имя хоста, Аноним (-), 19:32 , 11-Авг-17, (43) +1 // Точнее, запускаешь с EUID 0 git, который запускает ssh-клиент , Аноним (-), 19:33 , 11-Авг-17, (44) Причём тут подчёркивание вообще Дефис - нормальный символ в имени хоста open-s, nobody (??), 11:04 , 11-Авг-17, (8) –3 // Боль системдешников от s-d-resolved, к которым прилетело от их фетиша http , Andrey Mitrofanov (?), 11:11 , 11-Авг-17, (10) +2 не в начале имени КО, EHLO (?), 13:13 , 11-Авг-17, (17) +1 Нормальный, если он не первый и не последний Читай RFC , Аноним (-), 15:21 , 11-Авг-17, (27) +2 Может сначала RFC3986 глянешь, а потом уже будешь на IETF наезжать Such a nam, Аноним (-), 15:19 , 11-Авг-17, (26) Так всегда бывает, когда для каких-то целей используется команда с избыточной фу, YetAnotherOnanym (ok), 11:33 , 11-Авг-17, (11) // тебе надо выполнить некую команду на стороне сервера Программа для этой задачи,, пох (?), 14:54 , 11-Авг-17, (24) +2 // В данном случае вопрос в том, чтобы не была выполнена нежелательная команда на с, YetAnotherOnanym (ok), 16:57 , 11-Авг-17, (30) // от этого никуда не убежишь - слишком много ситуаций, когда требуется передавать , пох (?), 19:15 , 11-Авг-17, (39) –2 Давно изобрели 8212 используй любую из 9000 сторонних SHH-библиотек и всё ок , Аноним (-), 17:09 , 11-Авг-17, (31) –2 // гитлабовцы ващета руби-на-рельсах хипстеры, но сути это не меняет да, omnomnin (?), 17:59 , 11-Авг-17, (35) +1 Так уязвимость в гите или в стандартах на урлы вида ssh , Аноним (-), 11:34 , 11-Авг-17, (12) +1 // очевидно, в гите - какого хрена я не могу назвать свой хост -oProxyCommand gnome, пох (?), 12:20 , 11-Авг-17, (15) +3 // скорее всего, имя уже занятоможно использовать -oProxyCommand gnome-calculator , mmc (??), 14:15 , 11-Авг-17, (22) +1 В mercurial почти так же https www mercurial-scm org repo hg rev 739cc0f9cbb4, Аноним (-), 15:14 , 11-Авг-17, (25) // This paranoia probably isn t required, but it can t hurt either то есть они совс, пох (?), 19:48 , 11-Авг-17, (48) Не можешь, потому что стандарт не разрешает ни дефис в начале, ни где бы то н, Аноним (-), 15:23 , 11-Авг-17, (28) +1 // провижу массу интересных ремоут-хаков на теме того, что у нас не принято, а у и, пох (?), 19:19 , 11-Авг-17, (40) –3 --Маленький Бобби Тейблс, как мы его зовём , Andrey Mitrofanov (?), 19:23 , 11-Авг-17, (41) +1 Создай и продемонстрируй, тогда поговорим , Аноним (-), 19:37 , 11-Авг-17, (45) etc bind rndc reload localzone reload queued etc bind tail var log messagesA, little Boby Tables (?), 19:56 , 11-Авг-17, (49) –1 а зачем вообще гиту ssh , pripolz (?), 13:41 , 11-Авг-17, (20) –3 // Вместо smb Очевидно же , Andrey Mitrofanov (?), 13:49 , 11-Авг-17, (21) +6 не все хотят торчать в инет еще одним кривым сервисом не все хотят настраивать в, ваш К.О. (?), 14:49 , 11-Авг-17, (23) +3 Потому, что в голом git gitd вообще нет авторизации Она реализуется сторонн, Аноним (-), 09:29 , 12-Авг-17, (52) Это не баг, а фича , Аноним (-), 16:32 , 11-Авг-17, (29) –5 Нормальный такой нежданчик всё-таки Просто клонировал себе репозиторий Получил , pripolz (?), 18:00 , 11-Авг-17, (36) –2 // да ну, ожидаемый, на самом деле а зачем ему, он-то и через http неплохо могет , пох (?), 19:30 , 11-Авг-17, (42) –1 Ты клонируешь репозитории под рутом Может и perl-одностроки под ним запускаешь , Аноним (-), 19:39 , 11-Авг-17, (46) –1 // rm -rf и без рута может дров наломать, axredneck (?), 02:53 , 12-Авг-17, (50) +1 Я правильно понимаю, что параметр передаётся _ВМЕСТО_ имени хоста и это по сути , Аноним (-), 09:27 , 12-Авг-17, (51) Смотрю я на все эти уязвимости и у меня вопрос доколе будут делать все монолитом, Аноним (-), 02:30 , 13-Авг-17, (53) –1   // Потому что Торвальдс не эксперт по безопасности Он использовал самый простой пу, Аноним (-), 03:54 , 13-Авг-17, (54)   // Иксперд, ты же в курсе, что в самом git вообще не предусмотрено ни шифрования, н, anonymous (??), 19:08 , 14-Авг-17, (56)   // он вероятно как раз в курсе, и здраво относит это к банальному неумению линуса и, пох (?), 22:03 , 14-Авг-17, (58) –1   Это не здраво , а как раз больная фантазия фанатика Иди ещё раз кури идеолог, Аноним (-), 23:33 , 10-Сен-17, (64)   На вот, почитай https git-scm com book en v2, anonymous (??), 19:12 , 14-Авг-17, (57) –2   он использовал самый кривой путь, какой только можно - и теперь, к сожалению, эт, пох (?), 22:18 , 14-Авг-17, (60) –1   _git_ ssh Какая тебе разница Если ты не пользуешься git over ssh, то тебя эта, Ordu (ok), 07:32 , 13-Авг-17, (55)   // затрагивает - subrepo на сервере своем или гитхабе может попользоваться без , пох (?), 22:06 , 14-Авг-17, (59) –1   // При чём тут с ведома Если тебе понадобился ssh плагин, а его у тебя нет, то т, Ordu (ok), 22:45 , 14-Авг-17, (61)   только что проверил на ansible, тоже работаетГлобальная проблема то, Аноним (-), 10:46 , 02-Сен-17, (62) // указал в hosts -oProxyCommand gnome-calculator -m advanced Работает, в ковычках , Аноним (-), 11:04 , 02-Сен-17, (63) 1,2,4,11,12,20,29,36,51,53,62

Сообщения

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

53. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–1 +/–
Сообщение от Аноним (-), 13-Авг-17, 02:30
Смотрю я на все эти уязвимости и у меня вопрос доколе будут делать все монолитом. Я лично этим svn+ssh пользовался 1 раз в жизни. Почему нельзя например сделать было просто svns (svn over ssl)? Что с XML уязвимость была смешная что тут ... Такое чувство что назло и специально делают кривые и уязвимые программы... Расстроен... Можно же было сделать ssh через плагины или вообще не делать ...
Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от Аноним (-), 13-Авг-17, 03:54
	Потому что Торвальдс не эксперт по безопасности. Он использовал самый простой путь. Нормально в SSL/TLS могут лишь профи, которым это интересно. Те, кто недоросли до TLS используют STARTTLS, хотя он тоже не лишен недостатков. И нужно еще не забыть, что все текущие свободные реализации TLS имеют херову тучу багов. Поэтому, чтобы сделать что-то реально защищенное и стабильное нужны знания, опыт и куча времени (если нет первых двух). И да, ща набежит школота, которая скажет, что TLS прикрутить может любой студентик. Прикрутить-то он сможет, а на деле будет дырявое п0делие, которое никому нафиг не сдалось. Старая песня.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от anonymous (??), 14-Авг-17, 19:08
	Иксперд, ты же в курсе, что в самом git вообще не предусмотрено ни шифрования, ни авторизации, и эти задачи по определению перекладываются на внешние средства? Ты говоришь про ssh так, будто в git встроена реализация ssh или хотя бы ssh клиента. Хотя на само деле git работает внутри ssh туннеля Ты говоришь про ssl, будто не знаешь, что кроме работы внутри ssh туннеля git так же прекрасно работает внутри любого другого защищённого туннеля. В том числе - через любой веб-сервер, настроенный с поддержкой кошерного TLS 1.2 Не путай тёплое с мягким, и над тобой не будут смеяться Про идеологию unix что-нибудь слышал? git решает одну задачу и решает его хорошо. Авторизацию и шифрование обеспечивает другое ПО, с которым git взаимодействует
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–1 +/–
	Сообщение от пох (?), 14-Авг-17, 22:03
	> Иксперд, ты же в курсе, что в самом git вообще не предусмотрено ни шифрования, ни он вероятно как раз в курсе, и здраво относит это к банальному неумению линуса и компании сделать хорошо и надежно. Что, конечно, не грех для средней руки менеджера и программиста, но, постойте-постойте... > авторизации, и эти задачи по определению перекладываются на внешние средства? одна проблема - даже этими внешними средствами он пользуется через задницу (потому что "авторизация" через ssh сваливает всех внешних юзеров в одну кучу, слепо доверяя тому, что они о себе напишут внутри незащищенного и лишенного минимальной авторизации git-протокола - вот и гадай потом по таймстемпам, хто насрав - даже subversion еще умел при этом отдельно различать юзеров, но не подeлие линуса - потому что он, не умея пользоваться vcs, и категорически не желая учиться, годами принимал патчи в почту, и гит написан для автоматизации именно этой работы, а удаленный доступ к репо приделан на соплях левой задней ногой). и остаются либо сны разума вроде гитлаба, либо самодельная авторизация через веб+ssl, которую сделать хорошо, надежно и удобно не получится при всем желании, но при совсем ненулевой грамотности и затратах времени можно хотя бы любые два. справедливости ради - у hg такая же точно херня (ибо копипастили понятен откуда, зато-на-пихоне), и гитлаба для нее нет и не будет никогда. B общем-то поляна и загажена уже...
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от Аноним (-), 10-Сен-17, 23:33
	> он вероятно как раз в курсе, и здраво относит это к банальному неумению линуса и компании сделать хорошо и надежно Это не "здраво", а как раз "больная фантазия фанатика". Иди ещё раз кури идеологию UNIX > дна проблема - даже этими внешними средствами он пользуется через задницу (потому что "авторизация" через ssh сваливает всех внешних юзеров в одну кучу, Да ёмаё, ты похоже вообще не в курсе, как работает ssh. В такой ситуации рассказывать тебе про gitolite бесполезно Если ты болезный ни разу в жизни не настраивал авторизацию для доступа к git, не надо нести бред в массы - кури доки
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–2 +/–
	Сообщение от anonymous (??), 14-Авг-17, 19:12
	На вот, почитай  https://git-scm.com/book/en/v2
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	60. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–1 +/–
	Сообщение от пох (?), 14-Авг-17, 22:18
	> Потому что Торвальдс не эксперт по безопасности. Он использовал самый простой путь. он использовал самый кривой путь, какой только можно - и теперь, к сожалению, это стандарт навеки. > Нормально в SSL/TLS могут лишь профи, которым это интересно. Те, кто нормально в ssl уметь не надо - stunnel (если уж вштырило ssl) или https о тебе позаботится. Нормальная не-плэйнтекст авторизация и нормальная аутентификация, с нормальным разделением пользователей - без всякого криптотуннеля (если мне понадобится, туннель я сделаю без вас, на проверенных и надежных технологиях, а коммиты в паблик гитрепо вообще незачем прятать - но очень даже есть зачем точно знать кто коммитил) - это вот то, что никакой ssl за тебя не сделает. Увы, что-то похожее есть разьве что в mysql, ни одной vcs с таким функционалом мне вообще неизвестно. Все остальные либо тупейшим образом полагаются на внешние обертки, которые вовсе для этой цели не предназначены, и которые, к тому же, не умеют правильно готовить, как в данном случае, либо, как в svn, в них есть и аутентификация и разделение полномочий, но все эти замки - исключительно от честных людей.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	55. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от Ordu (ok), 13-Авг-17, 07:32
	> Я лично этим svn+ssh пользовался 1 раз в жизни. _git_ + ssh? > Можно же было сделать ssh через плагины или вообще не делать ... Какая тебе разница? Если ты не пользуешься git over ssh, то тебя эта уязвимость вообще никак не затрагивает. А если ты пользуешься, то она тебя затронет вне зависимости от того, будет ли поддержка ssh в плагине или в основной коде.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	59. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	–1 +/–
	Сообщение от пох (?), 14-Авг-17, 22:06
	> Какая тебе разница? Если ты не пользуешься git over ssh, то тебя > эта уязвимость вообще никак не затрагивает. А если ты пользуешься, то затрагивает - subrepo на сервере (своем или гитхабе) может "попользоваться" без твоего ведома.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Уязвимость в Git, Subversion и Mercurial, допускающая подста..."	+/–
	Сообщение от Ordu (ok), 14-Авг-17, 22:45
	>> Какая тебе разница? Если ты не пользуешься git over ssh, то тебя >> эта уязвимость вообще никак не затрагивает. А если ты пользуешься, то > затрагивает - subrepo на сервере (своем или гитхабе) может "попользоваться" без твоего > ведома. При чём тут "с ведома"? Если тебе понадобился ssh плагин, а его у тебя нет, то тебе придётся его ставить. Плагин, в данном случае -- это не более чем иллюзия контроля.
	Ответить | Правка | Наверх | Cообщить модератору

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

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