Несколько недавно обнаруженных уязвимостей:- В библиотеках libupnp4 (http://seclists.org/fulldisclosure/2013/Feb/5) и libupnp (http://seclists.org/fulldisclosure/2013/Feb/4), представляющих свободную реализацию протокола UPnP, выявлено 8 уязвимостей, в том числе позволяющих организовать удалённое выполнение кода через эксплуатацию использующего libupnp серверного приложения. Уязвимость может быть эксплуатирована путем отправки специально оформленных SSDP-запросов. Проблемы устранены в выпуске libupnp 1.6.18 (http://pupnp.sourceforge.net/).
- В системе мониторинга Nagios XI выявлена порция уязвимостей (http://seclists.org/fulldisclosure/2013/Feb/10), среди которых присутствует проблема, позволяющая удалённо выполнить с правами root код на сервере путём отправки специально оформленных параметров в административном интерфейсе, в том числе при наличии доступа в web-интерфейс в режиме только для чтения. Проблема исправлена в выпуске 2012R1.5 (http://library.nagios.com/library/products/nagiosxi/download...).
- В штатном FTP-сервере ftpd из состава FreeBSD 9.1 найдена проблема (http://seclists.org/fulldisclosure/2013/Feb/3), позволяющая удалённо инициировать отказ в обслуживании через подстановку в качестве аргумента команды stat специально оформленной маски. Выполнение запроса приводит к чрезмерной нагрузке на CPU. Сообщается, что проблема вызвана особенностью реализации функции glob в BSD libc и также проявляется варианте данной функции из состава Glibc. В NetBSD и OpenBSD проблема была исправлена в 2011 году.
- В Glibc найдена проблема безопасности (http://permalink.gmane.org/gmane.comp.security.oss.general/9271), проявляющаяся в форме краха при обработке (http://sourceware.org/bugzilla/show_bug.cgi?id=15078) регулярными выражениями специально оформленных многобайтовых последовательностей в функции re_search. Например, атакующий может добиться краха sed и других приложений, использующих функцию re_search. Исправление пока доступно только в виде патча (http://sourceware.org/ml/libc-alpha/2013-01/msg00967.html).
- В медиаплеере VLC найдена уязвимость (http://www.videolan.org/security/sa1302.html), позволяющая организовать выполнение кода при воспроизведении специально подготовленных ASF-файлов. Проблема устранена в репозитории проекта. В скором времени ожидается выпуск VLC 2.0.6 с устранением уязвимости.
- В сетевом анализаторе Wireshark 1.8.5 и 1.6.13 устранено около десятка уязвимостей (http://www.wireshark.org/docs/relnotes/wireshark-1.8.5.html), в том числе две проблемы, позволяющие организовать выполнение кода при разборе трафика NTLMSSP и DCP-ETSI.
- В библиотеке libvirt выявлена уязвимость (https://rhn.redhat.com/errata/RHSA-2013-0199.html), позволяющая организовать выполнение кода при отправке специально оформленных запросов. Проблема устранена (http://libvirt.org/git/?p=libvirt.git;a=commit;h=46532e3e8ed...) в Git-репозитории проекта.
URL:
Новость: http://www.opennet.me/opennews/art.shtml?num=36020
Представил ситуацию как кулхацскеры снифят Wireshark траффик пытаясь выциганить пароли. А тут им приходит хитрый NTLMSSP пакет и ломает их систему )))
А ещё многие хацкеры про setcap не знают и запускают Wireshark под рутом ^_^
ftpd мусор, использует pure-ftpd
а proftpd не используете?
в любом случае, держите нас в курсе.
Спасибо!
>FTPВыкиньте уже этот привет из 70-х. Кроме отсталых веб-хостеров он уже никем не используется.
rsync ?
> rsync ?sftp, webdav
rsync и ftp вообще не конкуренты, ибо слишком разные цели применения.
>sftp, webdavА еще можно гвозди забивать микроскопом..
>>sftp, webdav
> А еще можно гвозди забивать микроскопом..это вы пытаетесь так намекнуть на то, что эти протоколы для передачи файлов не подходят для передачи файлов?
это я пытаюсь понять, причем тут sftp?
При том, что выполняет ту же самую ф-ию, но безопасно и самое главное для меня, через один порт, а не через несколько рандомно, что сильно мешает работе за натом
> Кроме отсталых веб-хостеров он уже никем не используется.А кто пишет? Эмогей с айфоном?
> ftpd мусорТогда зачем его втюхивают?
>> Тогда зачем его втюхивают?не дай бог!
> не дай бог!Это вы бсдоидам скажите.
>> бсдоидамбсдшники юзают pure-ftpd если они не полные слоупоки
на ftpd кулхацкеры выкладывают взломы в ютуба
пюре - ДЫРЧАТЫЙ.
Если уж приспичило FTP - юзайте vsftpd - и точка!
Попроси маму подтереть попку, горе-эксперт.http://web.nvd.nist.gov/view/vuln/search-results?query=proft...
http://web.nvd.nist.gov/view/vuln/search-results?query=pure-...
А вот твой "недырявый" vsftpdhttp://web.nvd.nist.gov/view/vuln/search-results?query=vsftp...
Раз уж ты сам не в состоянии найти.
>> не дай бог!
>Это вы бсдоидам скажите.А я расскажу лапчатым:
>Сообщается, что проблема вызвана особенностью реализации функции glob в BSD libc
>и также проявляется варианте данной функции из состава Glibc.разжевать тебе жЫрненький о чём тут написано?
ftp вообще пользоваться нельзя, если заливать файлы из винды, то русская буква я теряетсяsftp рулит
Это проблемы вашего ftpd
вы наверно никогда не пользовались фтп сервером с UTF-8
> вы наверно никогда не пользовались фтп сервером с UTF-8Трабла в том что в FTP протоколе вообще IIRC не указывается в какой кодировке происходит работа. Вот вкатили вы уникод на сервере, а потом пришел хомяк с 1251. И что будет? Правильно - ничего хорошего.
>> вы наверно никогда не пользовались фтп сервером с UTF-8
> Трабла в том что в FTP протоколе вообще IIRC не указывается в
> какой кодировке происходит работа. Вот вкатили вы уникод на сервере, а
> потом пришел хомяк с 1251. И что будет? Правильно - ничего
> хорошего.если клиент забанен или принудительно не использует утф посылаем его лесом
в Welcome message
Суровый сибирский мужик вернулся из анабиоза.Для вас новости ftp:
RFC2640, Internationalization of the File Transfer Protocol, July 1999в ответе от сервера (211): UTF8
может спать дальше.
Никогда не пользовался ftpd. Зачем это, если есть scp и nfs?
Для тебя, Изя, только smb и dfs, притом в нативной реализации, желательно в АДу.