а где вообще ищутся секурити баги для того же гита? я смог найти только CVE-2015-7545 ну и CVE-2014-9390 , и ни тот ни другой языком никак нельзя предотвратить, хоть на агде пиши.
Ещё 3 buffer overflow. И 2 bobby table сравнимой опасности. И куча багов менее важный.
Но вообще C смешной. Мой любимый был баг в том же гите с git_path, где они использовали статический циклический массив для результатов с длиной емнип 4, и регулярно кто-то вылезает за эту цифру.
>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).
... то есть в теории это все правильно, но практическая ценность именно этого кейса нулевая.
"я бы не смог такое проэксплуатировать" не означает "никто не сможет", а скорее всего оно комбинируется с каким-нибудь другим невинным багом котороый позволяет слепить такую структуру данных не аллоцируя гигабайты оперативки.
или даже аллоцируя, вон последние эксплойты на PDF засырают сотни мегабайт, и ничего, надежно работают вполне
пойнт был про то что эксплойт нельзя сделать существующим софтом, только специально конструировать. а если специально конструировать, то не факт что именно упадет первым гит. отправил я как-то своего дев-тестера смотреть исправление баги про юникод в путях. когда он вернулся с ответом "все остальное падает раньше" =) решено было оставить игру в покое =).
> если это популярный опенсорс, то в нем найдут все уязвимости, невзирая на то, что язык, на котором он написан, этому активно сопротивляется?
Ну, справедливости ради, каждый найденный баг как бы приближает нас к этому светлому моменту (если принять за аксиому, что багов конечное количество).
Кроме того, твой вопрос некорректен. Правильный вопрос звучит так: «...то в нем найдутзакроют все уязвимости...». Потенциально опенсорс безопаснее именно поэтому. Я в VisualSourceSafe от микрософтов в 1997 году наткнулся на проблему эксплуатации в довольно нетривиальных условиях: у нас был репозиторий в Бостоне, а я был в Питере, а файлов было много, а канал был тогда довольно тонкий. И вот разработчики VSS, пользуясь привилегией «соседнего отдела», что-то спросили у осников. При синхронизации в условиях забитого канала оно пыталось всеми силами, и _все_ имевшие доступ к корню, получали доступ везде, насколько я понимаю, за счет какого-то твика в dll, которое отвечало за шифрование
( ... )
Comments 11
PS на самом деле среднеуровневая либа для доступа к репозиториям и правда есть
Reply
Reply
Reply
Reply
Reply
Но вообще C смешной. Мой любимый был баг в том же гите с git_path, где они использовали статический циклический массив для результатов с длиной емнип 4, и регулярно кто-то вылезает за эту цифру.
Reply
Reply
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).
...
то есть в теории это все правильно, но практическая ценность именно этого кейса нулевая.
Reply
или даже аллоцируя, вон последние эксплойты на PDF засырают сотни мегабайт, и ничего, надежно работают вполне
Reply
Reply
Ну, справедливости ради, каждый найденный баг как бы приближает нас к этому светлому моменту (если принять за аксиому, что багов конечное количество).
Кроме того, твой вопрос некорректен. Правильный вопрос звучит так: «...то в нем найдутзакроют все уязвимости...». Потенциально опенсорс безопаснее именно поэтому. Я в VisualSourceSafe от микрософтов в 1997 году наткнулся на проблему эксплуатации в довольно нетривиальных условиях: у нас был репозиторий в Бостоне, а я был в Питере, а файлов было много, а канал был тогда довольно тонкий. И вот разработчики VSS, пользуясь привилегией «соседнего отдела», что-то спросили у осников. При синхронизации в условиях забитого канала оно пыталось всеми силами, и _все_ имевшие доступ к корню, получали доступ везде, насколько я понимаю, за счет какого-то твика в dll, которое отвечало за шифрование ( ... )
Reply
Leave a comment