Previous Entry Share Next Entry
2016-01

Git <2.7.1 server/client remote code execution

http://seclists.org/oss-sec/2016/q1/645

Вполне стандартный buffer overflow, да. Даже уже в очередной раз писать стандартные вещи не хочется.

Можно ли на этом считать закрытым вопрос "если это популярный опенсорс, то в нем найдут все уязвимости, невзирая на то, что язык, на котором он написан, этому активно сопротивляется"? Я уж не говорю про баги.

This entry was originally posted at http://wizzard.dreamwidth.org/466987.html. It has comment count unavailable comments. Please comment there using OpenID.
Tags:

  • 1
avnik March 16th, 2016
Даешь гит на хаскеле!

PS на самом деле среднеуровневая либа для доступа к репозиториям и правда есть

thedeemon March 17th, 2016
Был же darcs, только тормозил нещадно, говорят.

dimez March 16th, 2016
Если у кого-то ещё были сомнения, то да, стоит закрыть :)

max630 March 16th, 2016
а где вообще ищутся секурити баги для того же гита? я смог найти только CVE-2015-7545 ну и CVE-2014-9390 , и ни тот ни другой языком никак нельзя предотвратить, хоть на агде пиши.

max630 March 17th, 2016
Ещё 3 buffer overflow. И 2 bobby table сравнимой опасности. И куча багов менее важный.

Но вообще C смешной. Мой любимый был баг в том же гите с git_path, где они использовали статический циклический массив для результатов с длиной емнип 4, и регулярно кто-то вылезает за эту цифру.

wizzard0 March 16th, 2016
но да, я нынче не слежу за темой и оно порядком рассеяно, надо какую-то подписку снова купить что ли

sleepy_drago March 16th, 2016
>If you have a
sequence of path components, each less than 2^31, they can sum to a much
smaller positive value due to integer overflow (e.g., A/B/C with lengths
A=2^31-5, B=2^31-5, C=20 would yield len=10).

...
то есть в теории это все правильно, но практическая ценность именно этого кейса нулевая.

wizzard0 March 16th, 2016
"я бы не смог такое проэксплуатировать" не означает "никто не сможет", а скорее всего оно комбинируется с каким-нибудь другим невинным багом котороый позволяет слепить такую структуру данных не аллоцируя гигабайты оперативки.

или даже аллоцируя, вон последние эксплойты на PDF засырают сотни мегабайт, и ничего, надежно работают вполне

sleepy_drago March 17th, 2016
пойнт был про то что эксплойт нельзя сделать существующим софтом, только специально конструировать. а если специально конструировать, то не факт что именно упадет первым гит. отправил я как-то своего дев-тестера смотреть исправление баги про юникод в путях. когда он вернулся с ответом "все остальное падает раньше" =) решено было оставить игру в покое =).

mudasobwa March 19th, 2016
> если это популярный опенсорс, то в нем найдут все уязвимости, невзирая на то, что язык, на котором он написан, этому активно сопротивляется?

Ну, справедливости ради, каждый найденный баг как бы приближает нас к этому светлому моменту (если принять за аксиому, что багов конечное количество).

Кроме того, твой вопрос некорректен. Правильный вопрос звучит так: «...то в нем найдутзакроют все уязвимости...». Потенциально опенсорс безопаснее именно поэтому. Я в VisualSourceSafe от микрософтов в 1997 году наткнулся на проблему эксплуатации в довольно нетривиальных условиях: у нас был репозиторий в Бостоне, а я был в Питере, а файлов было много, а канал был тогда довольно тонкий. И вот разработчики VSS, пользуясь привилегией «соседнего отдела», что-то спросили у осников. При синхронизации в условиях забитого канала оно пыталось всеми силами, и _все_ имевшие доступ к корню, получали доступ везде, насколько я понимаю, за счет какого-то твика в dll, которое отвечало за шифрование.

Да, это не уязвимость в обычном понимании, но, если учесть, что на тот момент я такой был, наверное, один — сам понимаешь, в чем-то сродни. В 99-м, кажтся, мы переползли на cvs, и ту проблему еще не закрыли (нужды не было, а зачем?).

  • 1
?

Log in

No account? Create an account