Разработчики проекта Horde (http://www.horde.org/), в рамках которого развивается серия свободных продуктов для организации совместной работы корпоративных пользователей, сообщили (http://permalink.gmane.org/gmane.comp.horde.announce/708) о выявлении факта внедрения бэкора в некоторые из установочных пакетов. Подробности совершения атаки не приводятся, известно лишь то, что пакеты были модифицированы в результате взлома первичного FTP-сервера проекта. Интегрированный бэкдор позволяет удалённому злоумышленнику выполнить произвольный PHP-код на сервере.
Сообщается, что бэкдор был внедрён только в пакеты с Horde 3.3.12, Groupware 1.2.10 и Horde Groupware Webmail Edition 1.2.10. Модифицированные злоумышленниками версии распространялись с начала ноября по 7 февраля. Пользователям указанных версий рекомендуется удостовериться, что их системы не содержат вредоносного кода. Для этого достаточно осуществить поиск в исходных текстах по маске "$m[1]($m[2])".
Производители Linux-дистриб...URL: http://permalink.gmane.org/gmane.comp.horde.announce/708
Новость: http://www.opennet.me/opennews/art.shtml?num=33087
пааанеслась. год назад ещё писал, что при усилении позиций опенсорса собсвенно эксплуатация уязвимостей будет применяться реже, а вот атаки на "первоисточник" - гораздо чаще. там - ахиллесова пята. разработчикам - терпения и внимательности.
Ну нет же проблем если дистрибостроители верифицируют сорцы используя ЭЦП.
А откуда дистростроители берут исходники? С уже скомпрометированных серверов проектов. Вот если все будут вместе с архивами выкладывать контрольные суммы…
> А откуда дистростроители берут исходники?из окаменелостей. ну что стоит девелоперам перестать раздавать окаменелости и вместо этого просто публиковать sha релизного коммита?
Git не был скомпрометирован. Сломали только FTP.
Во люди. Пишут же про ЭЦП. Контрольную сумму легко подделать, ЭЦП - нет (если рядом приватные ключи не раскидывать). И ничего страшного нет в том чтобы публиковать релиз. Да хоть патчи (с ЭЦП) публикуйте в таком случае.
> Во люди. Пишут же про ЭЦП. Контрольную сумму легко подделать, ЭЦП - нет (если рядом приватные ключи не раскидывать). И ничего страшного нет в том чтобы публиковать релиз. Да хоть патчи (с ЭЦП) публикуйте в таком случае.А если приватный ключ лежит рядом с password.txt из которого по всей видимости и увели аки на FTP?
то ссзб, очевидно
> то ссзб, очевидноот этого не легче
Это уже давно и делается всеми, кто пользуется git.
А что мешает подменить запись о контрольной сумме на странице проекта?
Речь не о контрольной сумме, а о подписывании кода личной подписью разработчика, и последующей верификации авторами дистрибутивов.
^ пардон, не посмотрел кому отвечаю.
Я предлагаю посмотреть в общем и целом. Проблема стоит так, что опенсорс более уязвим именно на стадии написания и распространения исходников. И контрольные суммы - это даже не тень решения проблемы в целом.
- в проект надо набирать людей. надо как-то проверять их самих и требования к рабочему месту. это раз.
- разработчик должен иметь подпись.
- проект должен уметь работать с подписями и проверять валидность кода.
- должна быть секурити тим.
- тот, кто код берёт, должен иметь возможность проверить его аутентичность.в общем и целом это уже совсем не пионэрство "пишу для удовольствия", это очень серьёзно. и требует слаженного взаимодействия между всеми участниками. но этим заниматься не хочется, хочется же побегать босиком за Столлманом и покидаться какашками в BSD.
> в общем и целом это уже совсем не пионэрство "пишу для удовольствия", это очень серьёзно. и требует слаженного взаимодействия между всеми участниками. но этим заниматься не хочется, хочется же побегать босиком за Столлманом и покидаться какашками в BSD.Вообще-то, базарная разработка - это Торвальдс как популяризатор и Реймонд как теоретик. Столлман же описывает модель распространения, а не разработки.
> Вообще-то, базарная разработка - это Торвальдс как популяризатор и Реймонд как теоретик.тем не менее именно линукс паровоз опенсорса.
> Столлман же описывает модель распространения, а не разработки.
описал он её уже давно, и за это ему спасибо гигантское. сейчас он описывает, как все должны жить. это не модель разработки, это проповедь.
В таком случае все есть вероятность заражения исходников на машине разработчика, до подписывания.
Еще один аргумент за использование цифровой подписи.
поэтому порочную практику «публикования релизов» давно пора отменить. вместо этого указывать на сайте команду для гита, которая вытащит именно то, что девелоперы назвали релизом.
а всем желающим попользоватся активно ставить себе бегом клиента для коннекта к очередной _cvs_system_, ню ню
> а всем желающим попользоватся активно ставить себе бегом клиента для коннекта к
> очередной _cvs_system_, ню нюскажи мне, милый друг: сколько этих самых желающих таки тащат тарболы с офсайта, а не берут из репозиториев своих дистрибутивов? и если уж они таки тащат тарболы, то для них не составит труда взять не тарбол, а срез гита.
но ты вряд ли об этом подумал, у тебя типичная психология диванного мыслителя: «я-то, конечно, понимаю, как это и что, но вот люди — люди, увы, не поймут…»
> а всем желающим попользоватся активно ставить себе бегом клиента для коннектаapt-get отказывается ставить такие страшные вещи?
> к очередной _cvs_system_, ню ню
cvs, svn, git, mercurial. нет, я понимаю, что для рая на земле надо только apt-get, но у нас, обитателей мрачных лабиринтов соурс-бейзед, оно уже стоит. да. и я больше скажу. не будучи программистом как таковым приходится знать все четыре. хотя бы на уровне терминологии и общих принципов. и ты знаешь, ещё никто не умер. хотя я понимаю, проблема не в apt-get install mercurial, проблема потом разбираться. может случиться переполнение памяти ;)
А в чем принципиальная разница? Ну поломают сервер с репозиторием - результат тот же. Ну ладно, при взломе гит почует, что контрольные суммы изменились, а остальные версионники? Навскидку еще штук пять вспомнить можно (svn, mercurial, bazaar, fossil, darcs) - из них хоть половина целостность проверяет?
пользуйтесь гитом - и будет безопасно :)
а также гораздо более удобно и функционально (имхо)
(задумчиво) значит, надо переходить на те, которые проверяют. или допиливать проверки в любимые. то, что где-то фичи нет — не причина сидеть и плакать, это повод допилить фичу туда, где её нет. ну право, пора уже что-то с окаменелыми тарболами делать. ну, то есть, не «что-то», а «забыть о них в большинстве случаев».p.s. централизованые системы я вообще тут не рассматриваю: это такая же окаменелая фигня, как и тарболы.
> (задумчиво) значит, надо переходить на те, которые проверяют. или допиливать проверки в
> любимые. то, что где-то фичи нет — не причина сидеть и
> плакать, это повод допилить фичу туда, где её нет.истинно так. но легко свести лошадь к воде, но невозможно заставить её пить. фичи напишут, ещё бы на них не забивали.
Упс, не туда ответ воткнулся. Это вам http://www.opennet.me/openforum/vsluhforumID3/82997.html#15
> А в чем принципиальная разница? Ну поломают сервер с репозиторием - результат тот же.Ага, иди разломай гит так чтобы потом 100500 разработчиков не заметило этого. Удачи.
Да довольно легко на самом деле - если больше одного человека имеет право на пуш лишний коммит с большой вероятностью даже замечен особо не будет. Ну обновилось что-то. Для достаточно большого проекта - пройдёт со свистом.
> если больше одного человека имеет право на пуш...то это уже SVN какой-то.
> поэтому порочную практику «публикования релизов» давно пора отменить. вместо
> этого указывать на сайте команду для гита, которая вытащит именно то,
> что девелоперы назвали релизом.Сравним:
Вы предлагаете скачивать из $VCSNAME. При этом это может быть git, svn, cvs, ...
Нужно всегда знать, как проверять "релиз" в очередной VCS. Хорошо, если это всегда git.
Тарболл можно подписать. Чем этот вариант вам не понравился? Обычно подписывают с помощью gpg. Способ проверки всегда одинаков, будь это хоть бинарник. Вы предлагаете мне заочно стать разработчиком, хотя я ничего и не разрабатываю обычно?
(пожимает плечами) о боги, человек, ну что же вы такие линейные-то? вроде бы и скрипты давно придумали — а толку ноль… для этих ваших разных scs и билд-контролей можно скрипт написать. один раз. положить к себе в репозиторий. и больше не мучаться. попутно получив возможность проверять не только тарбол, который авторы выложить соизволили.дала природа мозг, а зачем — пояснить забыла…
> (пожимает плечами) о боги, человек, ну что же вы такие линейные-то? вроде
> бы и скрипты давно придумали — а толку ноль… для этих
> ваших разных scs и билд-контролей можно скрипт написать. один раз. положить
> к себе в репозиторий. и больше не мучаться. попутно получив возможность
> проверять не только тарбол, который авторы выложить соизволили.
> дала природа мозг, а зачем — пояснить забыла…Я совершенно не понял вашего возмущения. Наверное, мы с разными окружениями работаем.
>> поэтому порочную практику «публикования релизов» давно пора отменить. вместо
>> этого указывать на сайте команду для гита, которая вытащит именно то,
>> что девелоперы назвали релизом.
> Сравним:
> Вы предлагаете скачивать из $VCSNAME. При этом это может быть git, svn,
> cvs, ...
> Нужно всегда знать, как проверять "релиз" в очередной VCS. Хорошо, если это
> всегда git.в упор не вижу проблемы. md5/sha в портах/портежах проверяются, никто не парится. так же можно и подпись проверять.
> Вы предлагаете мне заочно стать разработчиком, хотя я ничего и не разрабатываю обычно?исходники вам зачем тогда? если нужны - нет же проблем разобраться?
> поэтому порочную практику «публикования релизов» давно пора отменить.Да ну, тарболы порой лучше полной истории.
> вместо этого указывать на сайте команду для гита, которая вытащит именно то,
> что девелоперы назвали релизом.Бишь аннотированный и (крайне желательно) подписанный тег.
>> поэтому порочную практику «публикования релизов» давно пора отменить.
> Да ну, тарболы порой лучше полной истории.по-моему, у всех нормальных scs есть возможность не качать полную историю. зато — в отличие от тарбола — можно взять и проверить любой интересный срез, а не только то, что на сайте положили.
>> вместо этого указывать на сайте команду для гита, которая вытащит именно то,
>> что девелоперы назвали релизом.
> Бишь аннотированный и (крайне желательно) подписанный тег.ну да. это уже частности организации конкретного процесса.
впрочем, «релизы» как таковые — тоже пережитки прошлого. зачем? «коммит xyz — стабильный коммит». чего ради релизы выпускать, номерами заморачиваться?
google "%myvcs% sign commit"git/mercurial/bazaar точно умеют коммиты подписывать. И на сервисах типа гитхаба генерация архивов интегрирована. C выкладыванием на ftp пацаны реально от жизни отстали. Так не делают.
> C выкладыванием на ftp пацаны реально от жизни отстали. Так не делают.Факт!
ftp://ftp.mozilla.org/pub/firefox/releases/latest-10.0/source/
ftp://ftp.kde.org/pub/kde/stable/latest/src/
ftp://ftp.gnome.org/pub/gnome/sources/
ftp://ftp.gnu.org/pub/gnu/
.............
>> C выкладыванием на ftp пацаны реально от жизни отстали. Так не делают.
> Факт!
> ftp://ftp.mozilla.org/pub/firefox/releases/latest-10.0/source/
> ftp://ftp.kde.org/pub/kde/stable/latest/src/
> ftp://ftp.gnome.org/pub/gnome/sources/
> ftp://ftp.gnu.org/pub/gnu/
> .............У большинства есть http-зеркала, откуда качать зачастую намного удобнее, чем выкачивать с ftp, обычно без многопоточной загрузки (ftp ограничивают это, уже за это его пора бы отправить на свалку).
>ftp сервера обычно ограничивают это,
7 февраля какого года?
Почему на kernel.org все исходники имеют свои цифровые подписи, а тут никто не позаботился? Чеще делать,чаще проверять - вот и все !)
Почему ты считаешь, что цифровая подпись хоть что-то гарантирует?В концепции PKI важна не цифровая подпись сама по себе, а то, кто ее ставит. И доверяешь ли ты тому, кто подписывает. Причем лично я считаю, что понятия "доверие" и "безопасность" ортогональны. Нет доверия. Есть знание.
> Нет доверия.
> Есть знание.Сколько будет два плюс два?
>> Нет доверия.
>> Есть знание.
> Сколько будет два плюс два?например, 11.
2+2=22
>> Нет доверия.
>> Есть знание.
> Сколько будет два плюс два?А сколько Вам надо? (С) ;)