PHP 3.0.18-4.1.1 Security Update !!!

Вы уже поставили заплату?

  • Да! Еще вчера (27 февраля)

    Голосов: 3 21,4%
  • Только узнал пошел ставить..

    Голосов: 5 35,7%
  • У страха глаза велики ... не буду ставить

    Голосов: 4 28,6%
  • Смешная дырка .. не буду даже думать

    Голосов: 2 14,3%

  • Всего проголосовало
    14
  • Опрос закрыт .

dak

Guest
Новая серьезная бага в PHP

Подробности здесь:
http://security.e-matters.de/advisories/012002.html
Ошибка наблюдается во всех версиях вплоть до php 4.1.1, в 4.2.0 dev уже исправлена, но понятно, что ставить девелоперскую версию на боевую машину никто не будет...
 

confguru

ExAdmin
Команда форума
PHP 3.0.18-4.1.1 Security Update !!!

PHP Security Update
[27-Feb-2002] Due to a security issue found in all versions of PHP (including 3.x and 4.x), a new version of PHP has been released. All users of PHP are strongly encouraged to either upgrade to PHP 4.1.2, or install the patch (available for PHP 3.0.18, 4.0.6 and 4.1.0/4.1.1).

e-matters GmbH
www.e-matters.de

-= Security Advisory =-



Advisory: Multiple Remote Vulnerabilites within PHP's fileupload code
Release Date: 2002/02/27
Last Modified: 2002/02/27
Author: Stefan Esser [[email protected]]

Application: PHP v3.10-v3.18, v4.0.1-v4.1.1
Severity: Several vulnerabilities in PHP's fileupload code allow
remote compromise
Risk: Critical
Vendor Status: Patches Released
Reference: http://security.e-matters.de/advisories/012002.html



Overview:

We found several flaws in the way PHP handles multipart/form-data POST
requests. Each of the flaws could allow an attacker to execute arbitrary
code on the victim's system.


Details:

PHP supports multipart/form-data POST requests (as described in RFC1867)
known as POST fileuploads. Unfourtunately there are several flaws in the
php_mime_split function that could be used by an attacker to execute
arbitrary code. During our research we found out that not only PHP4 but
also older versions from the PHP3 tree are vulnerable.


The following is a list of bugs we found:

PHP 3.10-3.18

- broken boundary check (hard to exploit)
- arbitrary heap overflow (easy exploitable)

PHP 4.0.1-4.0.3pl1

- broken boundary check (hard to exploit)
- heap off by one (easy exploitable)

PHP 4.0.2-4.0.5

- 2 broken boundary checks (one very easy and one hard to exploit)

PHP 4.0.6-4.0.7RC2

- broken boundary check (very easy to exploit)

PHP 4.0.7RC3-4.1.1

- broken boundary check (hard to exploit)


Finally I want to mention that most of these vulnerabilities are
exploitable only on linux or solaris. But the heap off by one is only
exploitable on x86 architecture and the arbitrary heap overflow in
PHP3 is exploitable on most OS and architectures. (This includes *BSD)

Users running PHP 4.2.0-dev from cvs are not vulnerable to any of the
described bugs because the fileupload code was completly rewritten for
the 4.2.0 branch.


Proof of Concept:

e-matters is not going to release exploits for any of the discovered
vulnerabilities to the public.


Vendor Response:

Because I am part of the php developer team there is not much I can
write here...

27th February 2002 - An updated version of php and the patch for
these vulnerabilities are now available at:
http://www.php.net/downloads.php


Recommendation:

If you are running PHP 4.0.3 or above one way to workaround these
bugs is to disable the fileupload support within your php.ini
(file_uploads = Off) If you are running php as module keep in mind
to restart the webserver. Anyway you should better install the
fixed or a properly patched version to be safe.


Sidenotice:

This advisory is so short because I don't want to give out more info
than is needed.

Users running the developer version of php (4.2.0-dev) are not
vulnerable to these bugs because the fileupload support was completly
rewritten for that branch.
 

lyonchik

Guest
А вот частичный перевод:

Вкратце суть дыры такова:
обнаружен баг в том, как PHP обрабатывает запросы multipart POST. Эта дыра может позволить хакеру удаленно выполнить код на атакуемой системе. Ошибка кроется в функции php_mime_split(). Данный баг присутствует не только в PHP4, но и в PHP 3 версии.

Вот список багов, которые мы обнаружили:

PHP 3.10-3.18

- неправильная проверка границ в теле формы (broken boundary check) (трудно использовать)
- переполнение динамической области памяти (arbitrary heap overflow) (легко использовать)

PHP 4.0.1-4.0.3pl1

- неправильная проверка границ в теле формы (broken boundary check) (трудно использовать)
- heap off by one (легко использовать)

PHP 4.0.2-4.0.5

- 2 неправильных проверки границ в теле формы (одну легко использовать, другую трудно)

PHP 4.0.6-4.0.7RC2

- неправильная проверка границ в теле формы (broken boundary check) (очень легко использовать)

PHP 4.0.7RC3-4.1.1

- неправильная проверка границ в теле формы (broken boundary check) (трудно использовать)

Хотелось бы упомянуть, что большинство из этих багов можно использовать только на Linux или Solaris.
Но heap off by one сработает только на x86 архитектуре, а arbitrary heap overflow в PHP3 работает на большинстве ОС и архитектур (включая *BSD).

Пользователям, работающим на PHP 4.2.0-dev скачанной с CVS, не опасен ни один их этих багов,
так как код, ответственный за загрузку файлов был полностью переписан для серии 4.2.0.

E-matters не собирается делать доступными общественности эксплойты, связанные с этими багами.

На сайте разработчика http://www.php.net/downloads.php уже можно скачать обновленную версию.

Если Вы работаете на PHP версии 4.0.3 или выше, можно отключить поддержку загрузки файлов в php.ini (file_uploads = Off). Если PHP работает у Вас как модуль, не забудьте перезапустить Web сервер. В любом случае, лучше всего установить пропатченную версию PHP.

Copyright 2002 Stefan Esser. All rights reserved.
 

Serg

Guest
И чего так засуетились - шуму больше чем риска:

>>PHP 4.0.7RC3-4.1.1
>>- broken boundary check (hard to exploit)

Ну и попробуйте использовать? Варианты??? У меня за полчаса проб пока не вышло - продолжаю... :))

Опять же:

>>there are several flaws in the php_mime_split function
>> that could be used by an attacker to execute arbitrary code

Ну может быть, исходники лень копать, но даже если все плохо - системную секурити никто не отменял и видимость будет не дальше апачинского аккаунта. Если конечно Апача у кого-то под рутом ходит, тогда конечно, но это уже в большей степени генетическая ошибка :)
 

Serg

Guest
Автор оригинала: DiMA
> Serg
идиотская позиция, имхо
Зато позиция. Чего паниковать-то не разобравшись!Пересобрать не сложно, но это время, что на рабочих проектах не всегда имеется. Конечно стоит, кто спорит, но пороть горячку опаснее чем любая бага.

Да и повежлевее, молодой человек, крайние высказывания, как правило, применяются при отсутствии разумных аргументов.

З.Ы. Кстати, если у кого получитля воспользоваться сими дырками - поделитесь впечатлениями, интересно...
 

Alien

Новичок
> PHP supports multipart/form-data POST requests (as described in RFC1867) known as POST fileuploads. Unfourtunately there are several flaws in the php_mime_split function that could be used by an attacker to execute arbitrary code.

Таким образом - если нет открытых аплоадов - то нет и дыры. Или все хуже?
 

Serg

Guest
Автор оригинала: Альен
Таким образом - если нет открытых аплоадов - то нет и дыры. Или все хуже?
Описано только про аплоады, если поинтересоваться патчем - так и там только аплоад исправляется, больше ничего - следовательно все лучше чем у мелкомягких, котрые под видом одной заплатки половину проги меняют.

Но... Но что значит "нет открытых аплоадов"?? Любой скрипт может быть вызван якобы из multipart формы. Следовательно, если дыра позваляет запустить аплоад - он запустится, без содействия вызываемого скрипта, а точнее - до его исполнения...

Попрвьте, если я не прав!
 

Сытник

Guest
If you are running PHP 4.0.3 or above one way to workaround these bugs is to disable the fileupload support within your php.ini (file_uploads = Off) If you are running php as module keep in mind to restart the webserver. Anyway you should better install the fixed or a properly patched version to be safe.

http://security.e-matters.de/advisories/012002.html
 

Alien

Новичок
То есть если мне на любой скрипт (который и не думает обращатся к соответствующим функциям) "кто то умный и большой" зальет multipart/form-dat' у - то таки дыра есть?
Я никогда не интересовался как внутри работает php - как то времени не было
(-:


p.s.
/me ушел пинать админов.
 

DiMA

php.spb.ru
Команда форума
хоть на моем пеньке 233 компиляция и заняла много времени, но зато это было чрезвычайно легко. Параметры для ./configure у меня лежат в отдельных файлах у пхп и апача, все необходимое типа gif/jpg/png уже скомпилировано и валялось ранее, после make install у апача сделал рестарт ему и все. У меня даже чат не прервался (коннекты), там люди общались. Кто там говорил о проблемах переустановки пхп?
 

dimsi

Guest
Делюсь впечатлениями.

Нашел я кусок exploit'а для заваливания Apache+PHP через vulnerabilities in PHP's fileupload
Exploit'а никому не дам так как у самого дыра, да и нехорошо это, но могу поделится впечатлениями.

Полностью завалить Apach'у мне не удалось так как несилен я в ассемблерных кодах но это точно возможно так как процессы мрут как мухи но Apach'а успевает их создавать.
Проверял на Win2k/PHP4.0.4pl1, FreeBSD4.4/PHP3.0.18.

2.) Атаке подвержен любой PHP скрипт даже если он пустой.
3.) В Apach'евских логах ничего не пишется, единственное что остается сообщения что помер такой-то процесс, а под Win2k выскакивют окошки:
Apache.exe - Ошибка приложения :
Инструкция по адресу "0x78028cd3" обратилась к памяти по адресу "0x00000001". Память не может быть "read".
"ОК" -- завершение приложения
"Отмена" -- отладка приложения

Если бы я был хакером то мог бы сделать все что позволено делать user'у под которым работает Apache.
 

[VS]

Guest
Re: Делюсь впечатлениями.

Автор оригинала: dimsi
Если бы я был хакером то мог бы сделать все что позволено делать user'у под которым работает Apache.
Только почему-то никто этого еще не сделал. Это намек.
А эксплойтов я кучу видел. Все что они могут - прибить отдельного childа апаче.
 

su1d

Старожил PHPClubа
Re: Re: Делюсь впечатлениями.

Автор оригинала: [VS]
Только почему-то никто этого еще не сделал. Это намек.
А оно нам нужно? Эксплойт переполнения стека не так уж и трудно сделать, да вот только, если такая штука получит широкое распространение (а всякие script kiddies только этого и ждут), то начнутся всякие нездоровые движения. Много народу плакать будет. ;)
 
Сверху