SVN exploit

[kika]

По-моему в этой истории самое интересное - не сам эксплойт (он-то как раз довольно скучен, в смысле hack value) а тот факт, что в такой массе (крупных!) компаний совершенно отсутствует понятие релиз-менеджмента. Делают просто svn co в корень сайта и понеслось.
Фактическая statelessность HTTP протокола сыграла с индустрией злую шутку in da long run.

Comments

[itman.livejournal.com]

"Мадам знает толк в извращениях" (цытато, если что)
Ну, как бы можно, и бинарники тоже можно положить. И может даже кому-то так и удобно, но я бы не в жисть так не сделал. И не в последнюю очердь из-за директорий .svn и .cvs. А потом все равно надо как-то бинарники выкладывать. Что же их собирать и складировать в svn? А если нет, зачем тогда огород городить, когда часть вываливается через svn, а часть - еще как-то, нужно иметь отдельную утилиту для выкладывания релиза.

[lionet.livejournal.com]

Какие бинарники, ты о чём? PHP бинарники что-ли выкладываем? Всё что сервим, то и выкладываем. Не только в Java и C++ девелопмент ведётся.

Плюс ещё, есть очень большой смысл делать девелоперскую среду и продакшн среду как можно меньше различающуюся между собой. Что, когда девелопер код разрабатывает, он rpm'ом каждый результат изменения кода себе на тачку ставит? Не смеши.

Минимизация разницы между девелоперской средой и продакшном — это проблема управления рисками и затратами. Мы получаем, что релиз инжиниринг упрощается, упрощаются какие-то скрипты (какие? самописные? работающие лучше чем svn up?), какие-то процедуры. Не возникают проблемы с устареванием релиз-процедур с развитием проекта, так как девелоперы, не очень заботящиеся о релиз процедурах, всё равно имеют существенно похожую на продакшн систему у себя, так что если они что-то сделали, то это "что-то" взлетит на продакшне точно так же, как у них на девелоперской тачке.

Зачем жизнь себе усложнять в случаях, когда тяжёлая компиляция не является частью девелоперского процесса?

У нас некоторые девелоперы вообще не останавливают никогда продукт на своих тачках: он у них на _девелоперских_ тачках работает так, как на продакшне: апдейты накатываются таким же образом, как на продакшн, etc. Причём, не через RPM, а через svn up.

Вот ещё:

http://dmzlj.livejournal.com/67155.html

[itman.livejournal.com]

Лучше чем svn up? А прости за нескромный вопрос, а чем так svn up хорош и умеет ли он компилировать бинарники? Или после него надо таки делать, как минимум, make install?

[dmzlj.livejournal.com]

Он ничем не хорош. Но если его достаточно -- почему бы его не использовать. Почему весь срач стоит вокруг svn-а, а не вокруг, собственно, незакрытой дырки.

[itman.livejournal.com]

Потому что он выкладывает на сервер кучу мусора. Точка.

[dmzlj.livejournal.com]

и что?

[kika.livejournal.com]

Этот мусор оказался дыркой. В следующий раз окажется дыркой другой мусор.
Изолента.

[dmzlj.livejournal.com]

Дыркой то оказался не мусор, а настройки сервера.

А если сайт на скриптовых языках, каких большинство, то он и есть исходники. Какая разница, есть при этом .svn или нет.

[kika.livejournal.com]

Ну там же написано - в нгинксе нельзя запретить локацию глобально.

Еще раз, отчетливо, хоть и утро: класть в дистрибутив говно - это нарываться на проблемы, даже если говно сейчас очень мирно выглядит. Мы берем и затыкаем дыру, не отдаем .svn/ и т.д. Выходит новая версия svn, которая кладет теперь свой хлам в .ssvn, для несовместимости с предыдущими версиями или еще почему (например там просто опечатка :-)). В какой момент админ это заметит и где у него написано "если изменилась скрытая директория .svn, то пойти туда и сделать то" ? Да нигде. А если нигде, то он 100% забудет.
Если пехапешники поменяют .php на .pphp, то это заметят все, а вот скрытую директорию скорее всего не заметит практически никто. Сказано в ридми что новую версию svn надо использовать со свежим чекаутом, ну ладно, так и сделаем.

Постулат номер два - в общем случае невозможно написать кофигурацию сервера, которая будет непробиваема no matter what вне зависимости от действий девелоперов. Плохой программист хорошего админа всегда заборет.

[dmzlj.livejournal.com]

Про nginx это вопрос, скорее, к авторам nginx.

Про невыкладывание говна... А вот какие-нибудь третьи скрипты или сам rsync - это не говно? А ну как уязвимость будет в них. И еще --- я понимаю, если бы мы знали каждый файл ОС в лицо. А так - там целый дистрибутив говна, в принципе. В случаях, когда каждый файл на сервере классифицирован --- наверное, имеет смысл уже бороться за чистоту.

Т.е. я где-то согласен про мусор и борьбу за чистоту, но по сравнению с тем, что у нас на сервере Линукс, а не какой-нить SELinux или там Trustix или еще что вообще OpenBSD, мне кажется, что все эти выкладывания svn --- такая мелочь.

Опять же, разбиение на морду и бэкенд, видимо, многое решает. Если в интернет торчит только морда, то потери от ее потенциального взлома должны быть минимальными. Ну то есть надо делать так, что бы это было верно.

[kika.livejournal.com]

Про nginx это вопрос, скорее, к авторам nginx.

Сысоев ответил что это by design и так правильно. Я, в принципе, с ним согласен.

А вот какие-нибудь третьи скрипты или сам rsync - это не говно? А ну как уязвимость будет в них.

Это аргумент из категории "уж лучше я, чем какой-нибудь мерзавец". От того что в rsync может быть уязвимость, не следует что надо умножать ожидание эксплойта собственными непрофессиональными действиями. Я уже писал - реальная разница между профессионалом и любителем именно в матожидании.

Т.е. я где-то согласен про мусор и борьбу за чистоту, но по сравнению с тем, что у нас на сервере Линукс, а не какой-нить SELinux или там Trustix или еще что вообще OpenBSD, мне кажется, что все эти выкладывания svn --- такая мелочь.

Это противоречие реальности данной нам в ощущениях. Давно ли был remote exploit для линукса как такового, причем exploit такой чтобы реально explotable, чтоб его скрипт киддис в руткитах использовали? А svn - вот он, пожалуйста.