История с обнаружением уязвимостей (http://www.opennet.ru/opennews/art.shtml?num=32450) в ProFTPD и ftpd из состава FreeBSD, связанных с загрузкой библиотек после создания chroot, получила интересное продолжение. Сообщается (http://seclists.org/fulldisclosure/2011/Dec/66) об обнаружении похожей проблемы в ftp-сервере vsftpd (https://security.appspot.com/vsftpd.html), но уязвимость больше носит теоретический характер, так как чрезвычайно сложно эксплуатируема, требует нереальных условий и в конечном итоге может привести лишь к выполнении кода с правами непривилегированного пользователя, что практически исключает выход за пределы chroot (для повышения привилегий из chroot можно дополнительно эксплуатировать локальную уязвимость в ядре).Проблема присутствует не в самом vsftpd, а в glibc. Для совершения атаки в системе необходимо наличие устаревшей версии glibc с неисправленной уязвимостью, устраненной ещё в 2009 году. В случае с vsftpd в каталог "~/usr/share/zoneinfo" помещаются с...
URL: http://seclists.org/fulldisclosure/2011/Dec/66
Новость: http://www.opennet.ru/opennews/art.shtml?num=32459
Всё гораздо проще: chroot в пользовательские каталоги делать не следует, точка.В документации к vsftpd это отражено:
chroot_local_user
If set to YES, local users will be (by default) placed in a
chroot() jail in their home directory after login. Warning:
This option has security implications, especially if the users
have upload permission, or shell access. Only enable if you know
what you are doing. Note that these security implications are
not vsftpd specific. They apply to all FTP daemons which offer
to put local users in chroot() jails.Default: NO
Альтернатива: для пользователя, который должен быть в chroot, но при этом иметь доступ на запись в свой домашний каталог, прописать путь к домашнему каталогу в /etc/passwd в виде: /home/user/./home/user (да, с "/./" внутри пути). На наружный /home/user выставить владельцем root, на /home/user/./home/user - user'а. При этом vsftpd с passwd_chroot_enable=YES будет делать chroot в наружный /home/user, в который у user'а записи нет, тогда как реальным домашним каталогом user'а является внутренний (после захода по FTP, будет виден как /home/user и текущий каталог). Вместо /home/user внутри можно использовать и один каталог - например, назвать его homedir - его имя должно быть выбрано таким, чтобы не оказаться частью одного из стандартных путей к чему-то, используемому системными библиотеками. (Вариант с повтором /home/user хорош тем, что /home по FHS предназначен именно для расположения в нем домашних каталогов, а какое-либо другое имя каталога в корневом каталоге мало ли что будет означать для системных библиотек в будущем.)
Правда, даже с такими настройками очень легко получить уязвимость если остальные настройки приведут к тому, что vsftpd будет делать chroot в домашний каталог не только для пользователей с явно указанным "/./". Тут надо внимательно смотреть все настройки и списки пользователей (у vsftpd есть несколько опций на эту тему).
Так что лучше таких chroot'ов не делать вообще, тем более что, как правило, смысла в них мало (например, если речь идет об обновлении контента динамического веб-сайта, включая скрипты, выполняемые сервером без chroot). Мы на эти вещи идем когда клиент настаивает несмотря на предупреждение о риске и бессмысленности. ;-)
В proftpd, через черуты настраиваются хомы у вирт-юзеров и это стандартная опция, например, DirectAdmin-а. С одной стороны полезная фича, с другой стороны - неожиданная свинья, хотя и предсказуемая...
Ну вот и результат. Посмотрите на CVE, в proftpd критические уязвимости находят намного чаще, чем во vsftpd. Последний оправдывает своё название и пользователей proftpd я просто не понимаю.
> Последний оправдывает своё название и пользователей proftpd я просто не понимаю.Секрет прост: vsftpd безопасен, потому что ничего не умеет. А разработчики proftpd о фичах заботятся гораздо больше, чем о безопасности. "Нет в жизни счастья"(с)
Банального перекодирования имен файлов из одной кодировки в другую и то нет. Приходится сторонние сборки брать.
Кто же вам виноват что FTP настолько древний и дебильный протокол что там даже при всем желании нельзя кодировку передаваемых данных указать?
RFC 2640 отменили?
Скорее, забили. В хттп например если кому всучили кодировку которую он не понимает, он хотя-бы может это понять, потому что как правило указано что это за кодировка. В FTP нигде не указывается какую кодировку вам отгрузили. FAIL.
> Скорее, забили.Кто забил? vsftpd и lftp прекрасно поддерживают RFC 2640, Win7 тоже. Не поддерживает только возможно explorer из WinXP.
Вот как раз один из форков vsftpd и поддерживает в полной мере стандарт в части кодировок, а исходный vsftpd с кодировками мягко говоря не дружит, особенно когда речь заходит про клиентов с UTF-8.
> Кто забил? vsftpd и lftp прекрасно поддерживают RFC 2640, Win7 тоже. Не
> поддерживает только возможно explorer из WinXP.Насколько я знаю, официальный vsftpd не поддерживает RFC 2640 (ведь чем больше фич - тем хуже безопасность), а что там в win7 - никого не волнует. Абсолютное большинство FTP-клиентов - это total commander из winxp.
> total commander из winxp.кажется, я нашёл корень проблемы. даже два корня. вот их пусть и лечат.
> кажется, я нашёл корень проблемы. даже два корня. вот их пусть и лечат.Почти в каждой конторе, предоставляющей шаред-хостинг, или просто IT-отделе, обслуживающем конторскую FTP-файлопомойку, примерно раз в год находится человек, предлагающий посылать лесом клиентов, юзающих TC. Почему-то к этим аргументам начальство не прислушивается, и выдвиженец, как правило, сам идет лесом.
(пожимает плечами) потому что 95% населения, увы…
> Почти в каждой конторе, предоставляющей шаред-хостинг, или просто IT-отделе, обслуживающем
> конторскую FTP-файлопомойку, примерно раз в год находится человек, предлагающий посылать
> лесом клиентов, юзающих TC. Почему-то к этим аргументам начальство не прислушивается,
> и выдвиженец, как правило, сам идет лесом.Просто начальство, как правило не дурнее предлагающего, и считает что напрячь 1 мальщега которому платят за его работу деньги несколько легче и разумнее чем бороть привычку + заниматься обучением 100500 мальщегов пользующихся сейчас ТС. И я их очень понимаю.
> В FTP нигде не указывается какую кодировку вам отгрузили.Это указано в стандарте на FTP. Нижняя часть таблицы ASCII.
> Это указано в стандарте на FTP. Нижняя часть таблицы ASCII.Естественно. Поэтому имена файлов с кириллическими, китайскими, арабскими etc символами невозможны в принципе.
> Естественно. Поэтому имена файлов с кириллическими, китайскими, арабскими etc символами
> невозможны в принципе.более того: они вдобавок и не нужны совсем.
> более того: они вдобавок и не нужны совсем.О, любители классической досовский FAT подтянулись.
нет, нелюбители бардака. цифры-английские-буквы-подчёркивание-точки. всё, больше в именах файлов ничего не надо. по крайней мере до тех пор, пока char не станет повсеместно размером в четыре байта и живы уродцы типа utf.кстати: очень интересно, как, например, вводить с клавиатуры композитные (или невидимые) unicode-символы. без извратов. и зачем они нужны в именах файлов — тоже дико интересно.
хинт: пользователю «имена файлов» вообще не нужны, ему нужна хорошая система индексации документов. на веб-хостингах имена с символами вне перечисленого выше диапазона не нужны ещё больше. и только любители жрать кактусы продолжают настаивать на том, что кактус — вкусно и полезно.
Мораль: если наш любимый софт чего-то не умеет, значит, это не нужно. И плевать на юзеров, которые кричат, что нужно - они просто дураки, лишь мы видим свет истины.
> Мораль: если наш любимый софт чего-то не умеет, значит, это не нужно.нет, мораль совсем другая: если древний протокол (или древняя парадигма) чего-то не умеет — пора менять протокол (или парадигму). а не прилепливать к старому костыли при помощи изоленты и какой-то матери.
> уродцы типа utf.Уродец типа utf хорош тем что софт получает поддержку многонационального алфавита условно-нахаляву, без внедрежа принципиально новых (tm) функций и сисколов.
> кстати: очень интересно, как, например, вводить с клавиатуры композитные (или невидимые)
> unicode-символы.В виндусе для этого IIRC было что-то типа Alt+NNNN (NNNN = коду символа, вводится на цифровой клавиатуре). Вроде и в *nix такое есть.
> без извратов. и зачем они нужны в именах файлов — тоже дико интересно.
Затем что Марье Петровне, бухгалтерше, удобнее называть отчеты в понятном ей виде. А английский она может вообще не знает. А какие-нибудь китайцы тоже вполне могут хотеть хранить внутренние документы с удобными им именами.
> хинт: пользователю «имена файлов» вообще не нужны, ему нужна хорошая система
> индексации документов.И как это поможет допустим буху послать отчет в налоговую? Все-равно придется с файлами иметь дело. И вообще, чем файловая система плоха как индексатор? Можно создать папки-категории и разложить в них файлы-документы. Зачем плодить какие-то еще сущности?
> на веб-хостингах имена с символами вне перечисленого выше диапазона
> не нужны ещё больше. и только любители жрать кактусы продолжают настаивать
> на том, что кактус — вкусно и полезно.Если уж на то пошло, надо добавить что не нужен сам FTP, древний и дебильный протокол из каменного века.
> Уродец типа utf хорош тем что софт получает поддержку многонационального алфавита условно-нахаляву,
> без внедрежа принципиально новых ™ функций и сисколов.да не получает, в том-то всё и дело. если софт не utf8-aware, то всё равно косяки полезут в разных местах. если это не «приветмир», конечно (да и там полезут, если «привет» не по аглицки написано).
зато невозможность перемещаться по строке простыми операциями прибавления и вычитания — ни в какие ворота не лезет.> В виндусе для этого IIRC было что-то типа Alt+NNNN (NNNN = коду
> символа, вводится на цифровой клавиатуре). Вроде и в *nix такое есть.я же сказал — без костылей типа альтов и композитов. и зачем это делать.
> Затем что Марье Петровне, бухгалтерше, удобнее называть отчеты в понятном ей виде.
марье петровне, как я сказал ниже, вообще не надо знать, что на свете есть какие-то «файлы». ей нужен реестр документов, где она может быстро найти документ по дате, по названию, по содержимому, посмотреть его без запуска тяжёлой программы редактирования и ты пы.
>> хинт: пользователю «имена файлов» вообще не нужны, ему нужна хорошая система
>> индексации документов.
> И как это поможет допустим буху послать отчет в налоговую?нашёл документ, правоклацнул, выбрал пункт «создать электронное письмо с этим файлом», заполнил в появившемся окне поля «кому», «зачем» и «тело», нажал «отправить».
а если в конторе знающие своё дело админы, то и вовсе выбрал пункт «отправить налоговый отчёт».
> И вообще, чем файловая система плоха как
> индексатор? Можно создать папки-категории и разложить в них файлы-документы.тем, что это неискабельно и не обеспечивает никакого сервиса. для меня, положим, хороша. а для марьи ивановны — плоха, неудобна и непродуктивна.
> Зачем плодить какие-то еще сущности?
консоль должна устраивать всех. зачем плодить ещё какие-то сущности — GUI там, etc?
> Если уж на то пошло, надо добавить что не нужен сам FTP,
> древний и дебильный протокол из каменного века.согласен — его тоже пора заменить на что-то нормальное, а не доделывать к нему костыли.
> согласен — его тоже пора заменить на что-то нормальное, а не доделывать
> к нему костыли.Займитесь. И когда ваш уродец встанет на ноги и получит мировое признание без выкриков со стороны "зачем этот уродец!" мы сразу выкинем этого уродца старый гадкий протокол ФТП.
Любой онаним в интернете горазд звиздеть а вот чтобы сделать дело о котором трепешься - оооо...
лично мне как-то без разницы, что там надо *вам*. я давно уже использую другой протокол. угу, с сервером и клиентом под пингвинус (патч к mc наличествует, debsrc тоже) и клиентом под шындошс (плугины к фару и тоталу наличествуют). нет, «продвижением» этого я заниматься не собираюсь, оно мне не надо. хватит того, что оно устраивает меня и моих клиентов.а теперь разрешаю «защитывать слив», кричать «покажи» и заниматься прочим словоблудием.
Может тогда вообще нафиг отменить имена файлов? Есть же номер inode, а там индексатор разберется
> Может тогда вообще нафиг отменить имена файлов? Есть же номер inode, а
> там индексатор разберетсяможет, ты не будешь идиотничать? говорят, если постоянно идиотничать, постепенно превращаешься в настоящего идиота.
> нет, нелюбители бардака. цифры-английские-буквы-подчёркивание-точки. всё, больше в
> именах файлов ничего не надо. по крайней мере до тех пор,
> пока char не станет повсеместно размером в четыре байта и живы
> уродцы типа utf.Вот так пожалуйста и оформляйте свои посты везде где бы вы ни писали. Если уж современные программные средства не позволяют ничего сделать с бардаком в вашей голове, простите...
> хинт: пользователю «имена файлов» вообще не нужны, ему нужна хорошая система
> индексации документов. на веб-хостингах имена с символами вне перечисленого выше диапазона
> не нужны ещё больше. и только любители жрать кактусы продолжают настаивать
> на том, что кактус — вкусно и полезно.Кактус на самом деле вкусно и полезно если он правильно приготовлен.
Хинт: программы пишутся программистами с целью понабирать на мониторе всякую тарабарщину.
извини, забыл тебя спросить, как мне посты писать.
Все нормально, не бери в голову. Мы ведь тоже у тебя не спросили, какие имена давать файлам
> более того: они вдобавок и не нужны совсем.Почему-то мне кажется что многие русскоговорящие, китайцы и прочие арабы с вами не согласятся. С вашим предложением насчет систем индексации можете пойти лесом, _ОСОБЕННО_ когда спич идет о FTP и подобных. Юзеж FTP подразумевает что я хочу обменяться информацией с различными людьми. Кто такое "система индексации контента"? У меня она одна, а у получателя она другая. И?
> Юзеж FTP подразумевает…что ты ищешь себе дополнительных проблем, которые потом будешь героически преодолевать. оно и правильно: если всё получается с первого раза и без труда — кто же поймёт, как тяжело ты работаешь?
Приятно видеть умного человека, знающего абсолютно все об окружающих, их желаниях и о том, как им следует поступать
можешь называть меня «Его Божественная Тень».
> Банального перекодирования имен файлов из одной кодировки в другую и то нет. Приходится сторонние сборки брать.Насколько я помню, ее ни у кого нет, по идеологическим причинам (аналогично тому, как в современных плеерах нет перекодировки тегов ID3v1).
Есть левые патчи для proftpd и pure-ftpd, но у последнего с безопасностью все еще хуже (проблемы с головой автора).
Что, в 2011м еще кто-то пользует FTP? Как зрелый и стабильный протокол, небось? Некрофилы повсюду, блжад.
> Что, в 2011м еще кто-то пользует FTP? Как зрелый и стабильный протокол,
> небось? Некрофилы повсюду, блжад.Альтернатив не существует, да и не нужны.
Обычно перекодирование делается на стороне клиента, не вижу смысла мучить сервер, тем более, весь вменяемый мир давно перешёл на utf8 как раз для того, чтоб проблем не было.
если бы весь. вечно кто-то использующий какой нить древний тотал командер жалуется на крякозябры. ну правильно, upoad делали из под линукса, а у них винда.
2. Многочисленные уязвимости безопасности в glibc
http://securityvulns.ru/news/GNU/glibc/1112.html
Опубликовано: 4 декабря 2011 г.
Источник: BUGTRAQ
Тип: библиотека
Опасность: 8
Описание: Повышение привилегий через разделяемые библиотеки,
переполнение буфера в fnmatch(), слабая реализация
шифрования blowfish в crypt(), DoS-условия.
Продукты: GNU: glibc 2.12
Документы: MANDRIVA: [ MDVSA-2011:178 ] glibc
http://securityvulns.ru/\document395.html
Обсудить: http://securityvulns.ru/board12065.html
Это раскрутка сайта securityvulns (.) ru?
А тут - http://securityvulns.ru/news/FreeBSD/nsscompat/CE.html - даже покруче.
> Опубликовано: 4 декабря 2011 г.
> Продукты: GNU: glibc 2.12Называется проснулись из анабиоза. Это в Mandriva баги за последний год в glibc удосужились поправить. Те дыры ещё весной исправили и степень опасности для них помечена как " "Less critical" (DoS-атака)
http://secunia.com/advisories/44353/
http://www.opennet.ru/opennews/art.shtml?num=30204
11.04.2011 В GNU C Library найдена уязвимость, которая может быть использована для повышения привилегий приложений при достаточно маловероятных обстоятельствах. Проблема вызвана ненадлежащим квотингом вывода команды locale - злоумышленник может установить определенным образом переменные окружения и добиться запуска привилегированного скрипта, в котором вызывается команда locale. Проблема решена в Glibc 2.13.http://www.opennet.ru/opennews/art.shtml?num=29818
07.03.2011 В системной Си-библиотеке Glibc найдена уязвимость, вызванная ошибкой в реализации функции "fnmatch()", которая может привести к повреждению стека при передаче на вход функции специально оформленного имени файла. Уязвимости подвержены использующие данную функцию приложения, например, браузер Chrome. Проблема устранена в Glibc 2.12.2;