Несколько недавно обнаруженных уязвимостей:
- В реализации NFS-сервера из состава FreeBSD выявлена уязвимость (http://lists.freebsd.org/pipermail/freebsd-announce/2013-Apr...), позволяющая злоумышленнику организовать выполнение своего кода на стороне NFS-сервера через формирование специального READDIR-обращения к примонтированному NFS-разделу на стороне клиента. При экспорте данных с ZFS-разделов уязвимость может привести к организации записи произвольных данных в стек, при отдаче данных с UFS не исключено переполнение кучи. Теоретически не исключён сценарий выполнения кода в пространстве ядра при успешной эксплуатации уязвимости. Проблема проявляется во всех поддерживаемых ветках FreeBSD, но затрагивает только новую реализацию NFS-сервера, которая используется по умолчанию во FreeBSD 9 и доступна в качестве опции для FreeBSD 8;- В выпущенной (http://kernel.org) на днях серии обновлений ядра Linux 3.8.10, 3.2.44, 3.4.42 и 3.0.75 устранено несколько уязвимостей (http://permalink.gmane.org/gmane.linux.kernel/1482203):
- Проблема CVE-2013-1959 связана с некорректной проверкой привилегий при организации доступа к файлу /proc/pid/uid_map, что может быть использовано для получения прав пользователя root.
- Проблема CVE-2013-1979 проявляется в в коде сокетов из-за передачи euid вместо uid, что также может быть использовано для поднятия своих привилегий до прав пользователя root. Примечательно, что для указанной уязвимости уже имеется готовый прототип эксплоита (PoC).
- Уязвимость, позволяющая изменить маппинг идентификаторов пользователей для пространств имён, без наличия привилегий;
- Несколько проблем (http://secunia.com/advisories/53174/) в гипервизоре KVM, позволяющих вызвать отказ в обслуживании хост-системы или повысить свои привилегии через выполнение операций в гостевой системе;
- В свободном сервере для создания VPN-соединений tinc 1.0.21 (http://www.tinc-vpn.org) устранена уязвиомсть (http://www.tinc-vpn.org/pipermail/tinc/2013-April/003240.html), позволяющая выполнить код на сервере, отправив специально оформленный TCP-пакет на номер привязанного к tinc сетевого порта;- В memcached выявлена (http://permalink.gmane.org/gmane.comp.security.oss.general/1...) проблема безопасности, позволяющая инициировать крах рабочего процесса через отправку специально оформленного запроса (http://insecurety.net/?p=872). Исправление пока недоступно.
- В системе управления web-контентом Joomla 2.5.10 и 3.1.0 (http://www.joomla.org/announcements/release-news/5493-joomla...) устранено 7 уязвимостей, среди которых присутствуют проблемы, позволяющие без аутентификации удалить приватные сообщения и осуществить подстановку на сайт JavaScript-кода;
- В плагинах к системе управления контентом WordPress WP Super Cache 1.3.2 (http://secunia.com/advisories/53178/) и W3 Total Cache 0.9.2.9 (http://secunia.com/advisories/53052/) устранены критические уязвимости (http://wordpress.org/extend/plugins/wp-super-cache/changelog/), позволяющие выполнить произвольный PHP-код на сервере путём подстановки (http://blog.futtta.be/2013/04/18/wp-caching-plugin-vulnerabi.../) команд через теги mfunc и mclude. Проблема усугубляется тем, что плагин WP Super Cache пользуется большой популярностью (загружено более 6 млн копий) для организации кэширвоания динамических web-страниц WordPress.
URL:
Новость: http://www.opennet.me/opennews/art.shtml?num=36829
Интересно, memcached под CentOS 6.4 глохнулся, а memcachedb устоял. Надо поближе exploit рассмотреть :-)
Жумла радует беспредельно. 24 апреля был стабильный релиз 3.1.0, 26 апреля стабильный релиз 3.1.1 с закрытыми критическими багами =) Сегодня 30-е апреля, 3.1.2 что-то запаздывает...
> Жумла радует беспредельно. 24 апреля был стабильный релиз 3.1.0, 26 апреля стабильный
> релиз 3.1.1 с закрытыми критическими багами =) Сегодня 30-е апреля, 3.1.2
> что-то запаздывает...Это волнующий мир php. Сводки с некоторых проектов, типа phpbb, раньше можно было читать, как фронтовые. :)
мне еще в школе в классе 6-м преподаватель информатики в программу, вычисляющую функцию, вместо числа ввела букву. С тех пор (а прошло уже почти 30 лет) я до сих пор помню: любые пользовательские данные - ложь, требующая обработку. И да - системные данные/параметры, прошедшие через сеть или API, надо тоже считать враждебными, ибо никто не гарантирует, что они пришли такими, как вы ждете. Разработчики Жумл/Вордпресов/*ББ в школах не учились и вообще далеки от программирования? Скорее всего это так. А раз так, то язык не имеет значения. Они и в городе найдут коровью лепешку и наступят на нее.
дело-то не столько в этом, сколько в том, что существо, сложившее буквы в «приведмыр» на похапэ начинает радостно плясать, кричать «маааам! я тоже программист!» и показывать свои «шедевры» таким же идиотам, которые приветмиры ещё не осилили. вместо чтобы спрятать, никому не признаваться и пойти учиться.
>> А почему бы вам просто не признать, что PHP ужасен? Что в мире есть ужасные и непроработанные вещи, или просто устаревшие по своей сути, и что php в их числе?
> У shell-языков таких проблем не меньше. Но почему-то об этом никто не заикается.Можно напомнить про последнюю массовую shell-уязвимость, когда были затронуты десятки тысяч серверов?
Можно. Напомни.
> На мой взгляд при желание можно было бы: Начать параллельно разрабатывать новую веткуКстати, php6 там как, умер? Им ещё давным-давно пугали, ещё в эпоху 5.0, вроде. Что вот выйдет, и всё. Всё - вижу, php6 не вижу.
PHP был интересен тогда когда он появился, но на данный момент он уже не актуален. Про PHP 6 были в интернете всякие новости по поводу этой версии, лет так 5 назад, но по факту в 2010 году было объявлено, что php 6 не будет, и почти все его наработки были перенесены в версию 5.4. Так что по сути 5.4 это и есть 6, но это ничего не меняет. Мне вот что интересно во времена появления PHP как языка, компьютеры не были столь мощными, хотя и сам язык был не столь функциональным, но все равно как же это все работало. Я к тому, что даже на современном оборудование он работает не столь быстро как хотелось бы. Что в свою очередь рождает вопрос, а подходит ли вообще данный язык для современных веб разработок, мой личный ответ нет, не подходит. И разрабатывать на нем что-то очень функциональное, это значит сразу задрать планку с системными требованиями. Не целесообразно я считаю, но это только мое мнение на этот счет, я никого не хочу обидеть.
> PHP был интересен тогда когда он появился, но на данный момент он
> уже не актуален. Про PHP 6 были в интернете всякие новости
> по поводу этой версии, лет так 5 назад, но по факту
> в 2010 году было объявлено, что php 6 не будет, и
> почти все его наработки были перенесены в версию 5.4.То есть, php умрёт после 5-й ветки?
Мы подождём? Мы подождём!
похапэ просто плох. defective by design. и это неисправимо, это родовая травма.а если учесть, что сейчас модно делать «странички» с кучей формочек, кнопочек, свистелок и перделок, то почти все остальные языки, которые пытаются использовать «для веба» плохи не сильно меньше. потому что для комфортной разработы нужен язык с first class continuations и сделаный на этой основе фрэймворк. без подобного написание кода «для веба» — костыли над костылями для костылей.
Язык и мышление - связаны. И программист выбирает язык, согласно своему интеллекту, и язык формирует какую-то часть мышления. PHP, Java - довольно специфические языки нашего времени: примитивные, топорные, местами туповатые. И главное: НАЧИСТО УБИВАЮТ ДУХ "ХАКЕРСТВА" - вот за это их не любят. И наоборот, любят школьники, студенты, недоучки...
> И главное: НАЧИСТО УБИВАЮТ ДУХ «ХАКЕРСТВА»Петер Норвиг в афиге. впрочем, мне отчего-то кажется, что ты о нём сейчас узнаешь в первый раз, когда в гугель и википедию побежишь.
Просто от некоторых детских ошибок хорошо защищает правильный дизайн системы.Сейчас в PHP есть PDO, дизайн которого слизан с модуля DBI из Perl (подобный же дизайн используется в Python, и, думаю, в других языках). Если в запрос подставлять данные только с использованием символов-заменителей ?, то довольно сложно допустить в коде возможность SQL-инъекции. Если использовать какой-нибудь ORM, то ещё сложнее.
Однако, мне кажется, что большинство пишущих на PHP продолжают писать запросы вроде "SELECT COUNT(*) FROM users WHERE login = '" . $_POST['login'] . "' AND password = '" . $_POST['password'] . "'"; При таком способе формирования запросов довольно легко забыть воспользоваться функцией mysql_escape_string или ей подобной и в итоге пускать в свою систему кого ни попадя, кто догадается передать вместо логина и пароля нечто вроде "' OR '' = '".
http://www.php.su/functions/?mysql-real-escape-string
> http://www.php.su/functions/?mysql-real-escape-stringНаверное, главная киллер-фича (убивающая фича) php - это принципиально разная работа скрипта в зависимости от настроек сервера - это и методы роутов, и когда-то актуальный register_globals, и всякие magic_quotes.
http://pastebin.com/8vQnNtfZ
для первой (по списку) уязвимости тоже есть эксплоит
> для первой (по списку) уязвимости тоже есть эксплоит(зевая) а пострадавшие есть?
ps. проще всего получить уязвимость - это запускать всякие неведомые эксплоиты.
понятия не имею есть ли, у меня не работает (:
>> для первой (по списку) уязвимости тоже есть эксплоит
> (зевая) а пострадавшие есть?
> ps. проще всего получить уязвимость - это запускать всякие неведомые эксплоиты.
> (зевая) а пострадавшие есть?Пока ты тут зеваешь, с твоего десктопа уже шлют спам :)
>> (зевая) а пострадавшие есть?
> Пока ты тут зеваешь, с твоего десктопа уже шлют спам :)причём мне
>> (зевая) а пострадавшие есть?
> Пока ты тут зеваешь, с твоего десктопа уже шлют спам :)и прямо сюда в комментарии