Новости Security

Выпущен корректирующий релиз надежного, защищенного и высокопроизводительного FTP-сервера vsftpd 2.3.4, который вышел почти сразу после версии 2.3.3 в которой была оперативно исправлена проблема со сборкой. Кроме исправления нескольких незначительных ошибок, в новой версии устранена уязвимость, которая может быть использована злоумышленниками для совершения DoS-атаки через исчерпание ресурсов CPU и достижения лимита на число соединений. Наличие проблемы подтверждено в vsftpd 2.3.2 и более ранних версиях.

Суть уязвимости связана с особенностями обработки масок, например, выполнив команду вида "STAT {{*},{*}....}" процесс будет выполняться значительное время, нагружая при этом CPU. Отправив на сервер скриптом несколько сотен подобных запросов можно блокировать его работу из-за исчерпания числа запущенных процессов-обработчиков (если не настроен лимит на число соединений с одного IP). Из FTP-серверов, которые используют устаревшие версии vsftpd отмечаются: ftp.gnu.org (2.0.6), ftp.kernel.org (2.2.2), ftpgen.wip4.adobe.com (2.3.2), ftp.oracle.com (2.0.5), ftp.freebsd.org (2.2.0).

Сайт проекта  http://vsftpd.beasts.org/

Копипаста Opennet.ru

> Simple kernel attack using socketpair. easy, 100% reproductiblle, works under guest. no way to protect
Такими словами начинается сообщение в списке рассылки LKML. Дальше идёт код эксплоита. Процесс потребляет 100% ЦПУ, расходует все файловые дескрипторы и система начинает тормозить. Процесс невозможно убить через SIGKILL. Желающие могут проверить. Работает от любого непривилегированного пользователя. По сообщениям на лор0 работает также и в FreeBSD 8.1. Можно сказать, что это UNIX-wide проблема.

Вскоре после обнаружения предыдущей дыры (  http://www.lor-ng.org/message.php?newsid=30924 ), которая, однако, работала только на redhat-based дистрибутивах, опубликованы сведения о новой дырке в основной библиотеке большинства дистрибутивов -- glibc. На этот раз подвержены большинство дистрибутивов. Желающие узнать механизм работы могут посмотреть его по ссылке, остальным интересующим можно сразу перейти к изучению эксплоита:

Дальше всё зависит только от вашей фантазии. Авторы на opennet-е запихнули этот файл в список заданий cron-а. Другой вариант -- поместить его в /etc/profile.d. Выразившие особое рвение предлагают сразу писать в /dev/sda.

В реализации поддержки сетевого протокола RDS (Reliable Datagram Sockets), разработанного компанией Oracle, найдена уязвимость, позволяющая локальному злоумышленнику выполнить код с повышенными привилегиями через отправку специально оформленного запроса к RDS-сокету. Наличие уязвимости подтверждено в Linux-ядрах с 2.6.30 по 2.6.36-rc8, собранных с включенной опцией CONFIG_RDS. Большинство Linux-дистрибутивов подвержены уязвимости, так как поддержка RDS включена в виде модуля (проверить можно командой "cat /boot/config-2.6.3* |grep CONFIG_RDS").

Опасность уязвимости усугубляется наличием эксплоита в открытом доступе. Исправление пока доступно только в виде патча к Linux-ядру.

 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=799c10559d60f159ab2232203f222f18fa3c4a5f

В качестве временной меры защиты, рекомендуется запретить автоматическую загрузку RDS-модуля:

echo "alias net-pf-21 off" > /etc/modprobe.d/disable-rds

Дополнительно сообщается об исправлении в тестовой сборке Linux-ядра 2.6.36-rc7 уязвимости в DRM-модуле для видеокарт i915. Отправка специально оформленного запроса через i915 GEM ioctl потенциально может привести к выполнению кода локального злоумышленника с привилегиями ядра системы.

Кроме того, в реализации функции "snd_ctl_new()" из звуковой подсистемы Linux-ядра найдено целочисленное переполнение, используя которое локальный злоумышленник может вызвать крах ядра или потенциально организовать выполнение кода с повышенными привилегиями через отправку специально подготовленного запроса к устройству "/dev/snd/controlC*. Проблема устранена в тестовой сборке 2.6.36-rc7.

//Эксплоит  http://www.vsecurity.com/download/tools/linux-rds-exploit.c

Копипаста с Opennet.ru

Ошибка в реализации функции glob() в различных Си-библиотеках, например в glibc и BSD libc, может быть использована удалённым атакующим, чтобы нарушить работу FTP/SFTP серверов. В связи с тем, что на многих серверах разрешён анонимный вход, ошибку легко эксплуатировать и многие программные продукты являются уязвимыми. В отчёте утверждается, что серверы даже таких крупных компаний, как Adobe и HP, подвержены этой проблеме.

Проблема возникла из-за того, что переменная GLOB_LIMIT, которую добавили в 2001 году для ограничения объёма памяти функцией glob() c целью защиты от аналогичной уязвимости, не эффективна. Проверка на совпадение (globbing) вызывает функцию glob(), чтобы сравнить список файлов с шаблоном и вернуть на выход список совпадающих файлов. В виду того, что GLOB_LIMIT не действует в ситуациях когда в пути фигурирует несуществующий путь, данная проблема теоретически позволяет исчерпать доступную процессу память, используя определённый шаблон ("*/../*/../*строка" или "{..,..,..}/*/{..,..,..}/*строка"), и, в зависимости от операционной системы и мощности оборудования, может привести к полной остановке работы или неожиданному завершению работы FTP/SFTP сервиса.

Уязвимость на данный момент подтверждена в следующих продуктах: OpenBSD 4.7, NetBSD 5.0.2, FreeBSD 7.3 / 8.1, Oracle Sun Solaris 10 и GNU Libc (glibc), поставляемой в Linux. Для демонстрации проблемы выпущен эксплоит. Разработчики NetBSD уже закрыли эту проблему, другие компании пока даже не заявляют о её существовании: Slackware, Gentoo, Mandriva, openSUSE, CentOS, Fedora, RHEL, Debian, Ubuntu, FreeBSD, OpenBSD.

Vsftpd проблеме не подвержен.

Источник Opennet.ru

В 2007 году была обнаружена уязвимость в 64-разрядных Linux-ядрах, которая позволяла непривилегированному локальному пользователю получить root-доступ к системе из-за небезопасной трансляции 32-битных вызовов. Ошибка на тот момент была исправлена и всё про неё благополучно забыли.

Ben Hawkes, который изначально нашёл эту уязвимость, недавно обнаружил, что проблема снова возникла в ядре в виду того, что в 2008 году из-за первоначального патча появилась регрессия и код был поправлен таким образом, что ядро снова стало уязвимо. Сделав небольшую правку изначального кода exploit'a, Ben Hawkes добился его работоспособности во всех свежих 64-битных Linux-ядрах.

Таким образом, все свежие 64-битные ядра являются уязвимыми к локальной атаке, и в случае использования Linux для организации работы системы совместного доступа, например, для обеспечения работы хостинга, следует незамедлительно обновить Linux-ядро или временно запретить shell-доступ.

Компания RedHat заявила, что ядра, поставляемые в дистрибутивах RHEL 3, 4 и 5 (соответственно и в CentOS), не являются уязвимыми, так как проблемный патч d4d67150 не был принят. Информацию о появлении обновлений с исправлением уязвимости в других популярных Linux-дистрибутивах, можно узнать по следующим ссылкам: Ubuntu, Slackware, Gentoo, Mandriva, openSUSE, Fedora и Debian. Эксплоит для проверки подверженности системы вышеописанной уязвимости можно загрузить здесь.

\list{Кроме того, на днях в Linux-ядре обнаружены еще несколько менее серьезных уязвимостей:

{*} При вызове некоторыми функциями (например, "compat_mc_getsockopt()") процедуры "compat_alloc_user_space()" не осуществляется проверка корректности данных о возвращаемой области памяти, что может быть использовано для повреждения содержимого памяти ядра; {*} Ошибка в коде проверки допустимости границ в функции "niu_get_ethtool_tcam_all()" из состава драйвера NIU, может привести к краху ядра или потенциальному выполнению кода на уровне ядра при отправке специально оформленного ETHTOOL_GRXCLSRLALL IOCTL. Проблеме подвержены только системы, использующие драйвер для Ethernet-адаптеров Sun Neptune (NIU). Проблема исправлена в выпуске 2.6.36-rc4; {*} В реализации файловой системы XFS зафиксирована проблема, связанная с отсутствием очистки памяти перед передачей некоторых структур данных на пользовательский уровень. Используя ошибку, злоумышленник может получить доступ к некоторым закрытым областям памяти ядра через отправку XFS_IOC_FSGETXATTR IOCTL. Проблема устранена в ядре 2.6.36-rc4; {*} В функциях "de4x5_ioctl()", "cxgb_extension_ioctl()", "eql_g_master_cfg()" и "hso_get_count()" найдены ошибки, приводящие к копированию неинициализированных областей памяти ядра, в которых могут содержать закрытые данные из области стека ядра. Проблема проявляется при отправке соответствующих IOCTL драйверам de4x5, cxgb, eql и hso.

Цельнотянуто с Opennet.ru

Раскрыта информация об обнаруженной месяц назад ошибке, присутствующей практически во всех Linux-ядрах серии 2.6.x, которая позволяет непривилегированному пользовательскому процессу, который имеет доступ к X-серверу (т.е. любому графическому приложению), безоговорочно получить привилегии суперпользователя, при этом, стоит отметить, что проведение атаки не затрагивает никакие ошибки X-сервера.

Другими словами, любое, имеющие уязвимости, непривилегированное графическое приложение в результате атаки может обойти все механизмы защиты безопасности Linux-ядра и скомпрометировать систему целиком. Атака может быть произведена даже из изолированного окружения системы безопасности SELinux, которая не спасает от данной уязвимости. Например, злоумышленник может воспользоваться уязвимостью в PDF-просмотрщике, запущенном в chroot или под контролем SELinux, и добившись от пользователя открытия специально оформленного документа, получить доступ к машине с правами суперпользователя. Ошибка, судя по всему, существует уже несколько лет практически во всех ядрах серии 2.6.x.

Новость взята с opennet.ru

В ветке OpenSSL 1.0 найдена опасная уязвимость, теоретически позволяющая организовать выполнение кода на стороне клиента, путем отправки с контролируемого злоумышленником сервера (в ответ на запрос клиента) специально оформленного SSL-сертификата. Уязвимость связана с ошибкой в коде функции "ssl3_get_key_exchange()", приводящей к обращению к буферу в уже освобожденной области памяти. Исправление пока не выпущено разработчиками OpenSSL, ветка 0.9.8 проблеме не подвержена.

Дополнительно можно упомянуть, что в GnuPG тоже найдена похожая уязвимость, потенциально способная привести к выполнению кода злоумышленника при обработке утилитой GPGSM некорректного сертификата X.509 или сообщения S/MIME. Наличие проблемы подтверждено в последнем релизе GnuPG 2.0.16, для устранения проблемы подготовлен патч.

Взято с Opennet.ru

Компания Adobe объявила о выходе критического обновления безопасности Flash-проигрывателя. В данном релизе устранены следующие ошибки в безопасности:

* Исправлено несколько ошибок, которые могли привести к повреждению областей памяти и потенциальной возможности выполнения кода злоумышленника при открытии специально оформленного SWF-файла (CVE-2010-0209, CVE-2010-2188, CVE-2010-2213, CVE-2010-2214, CVE-2010-2216); * Исправлена уязвимость, которую можно использовать для проведения атаки по подмене сайта, на который осуществляется переход (click-jacking attach) - CVE-2010-2215.

Всем пользователям рекомендуется незамедлительно обновить Flash-плагин.

Новость цельно тянута с Opennet.ru

В коде генерации номеров уникальных пользовательских сессий и уникальных идентификаторов (uniqid) PHP найдена недоработка, позволяющая злоумышленнику предсказать другие номера последовательности, зная текущий номер сессии (например, войдя на форум можно подобрать номера сессий других пользователей). Проблема вызвана некорректной инициализацией генератора случайных чисел в PHP, начальные значение затравки для которого можно предсказать с достаточно высокой степенью вероятности.

Проблеме подвержены все версии PHP, включая 5.3.2. Интересно, что при выпуске версии PHP 5.3.2 разработчики знали о существовании данной проблемы и даже изменили метод инициализации генератора случайных чисел, но то изменение по сути сводилось к добавлению предсказуемой константы, т.е. принципиально не устраняло суть проблемы, а лишь защищало от определенного эксплоита. Защита от подобного рода проблем в проекте Suhosin (защищенный вариант PHP) была добавлена начиная с версии 0.9.31, выпущенной 5 лет назад. Впервые проблема с генератором случайных чисел PHP была озвучена еще в 2001 году.

Взято с  http://www.opennet.ru