phpbar.de logo

Mailinglisten-Archive

[php] PHP Expoit beim File-Upload und PHP3

[php] PHP Expoit beim File-Upload und PHP3

Matthias Jim Knopf jim_(at)_users.de
Wed, 20 Sep 2000 22:27:29 +0200 (MEST)


Hey-ho Chris Glutz! Am 2000-09-20 22:13 meintest Du

> hallo Matthias
>
> Das interessiert mich. kannst du mir den Hinweis in der PHP-Liste
> schicken.
> Ich kanns nicht finden.

  Ich habs jetzt nicht nachgebrueft, obs wirklich nicht  ueber  die 
Liste ging, aber da es  doch  ein  sehr  wirklichtiger  Punkt  ist, 
erlaube ich mir mal, die Mail (die ich  tatsaechlich  von  woanders 
bekommen habe) hier zu posten. Anbei war zwar auch  eine  URL,  die 
leider nicht mehr richtig ist, daher  weiss  ich  auch  nicht,  WER 
diesen Text eigentlich geschrieben  hat...  Fest  steht  allerdings 
(ich  habs  selbst  getestet),  dass  dies   ein   dickes   Problem 
darstellt.
  Da ich jetzt davon ausgehen  muss,  dass  die  Info  dieser  Mail 
nicht  jedem  bekannt  war,  moechte  ich  meine   Frage   nochmals 
(kuerzer) stellen: Ist der Work-Arround, der weiter unten  bei  (*) 
erklaert wird, und der unter  PHP4  problemlos  funktioniert  unter 
PHP3 nicht anwendbar? Dies zumindest ist meine Erfahrung,  und  ich 
haette gerne ein paar Comments gehoert, ob  tatsaechlich  mit  PHP3 
dieser Work-Arround evtl. nicht  funktioniert,  weil  (fuer  dieses 
Beispiel) die Variable HTTP_POST_VARS["hello"] gesetzt  waere  (und 
auf die temporaere Datei zeigt), auch  wenn  diese  Variable  NICHT 
von Hand von einem Angreifer  angegeben  wurde?!?  Falls  das  doch 
nicht ganz klar war: Bitte erst diese zuende, und dann  die  andere 
Mail von mir lesen ;-)

---CUT---

[Title]
Arbitrary file disclosure through PHP file upload

[Released]
04/09/2000

(We found this particular issue a while ago but were planning to disclose it
at a later date once we had a chance to investigate its imact on most
popular PHP software. However, the issue was recently half found/disclosed
by a poster on the php-general mailing list, who didn't appear to realise
its impact)

[Vulnerable]
_Almost_ any PHP program which provides file upload capability

[Overview]
PHP is a feature heavy web scripting language that has become widely
popular. One of its many features is easy handling of file uploads from
remote browsers. This functionality is very commonly used, particularly in
photo gallery, auction and webmail style applications.

The way that PHP handles file uploads makes it simple to trick PHP
applications into working on arbitrary files local to the server rather than
files uploaded by the user. This will generally lead to a remote attacker
being able to read any file on the server that can be read by the user the
web server is running as, typically 'nobody'.

[Impact]
1. File disclosure
2. (1) will often lead to disclosure of PHP code
3. (2) will often lead to disclosure of database authentication data
4. (3) may lead to machine compromise

[Detail]
When files are uploaded to a PHP script, PHP receives the file, gives it a
random name and places it into a configured temporary directory. The PHP
script is given information about the file that was uploaded in the form of
4 global variables. Presuming the file field in the form was called 'hello',
the 4 variables would be:
 $hello = Name of temporary file (e.g '/tmp/ASHDjkjbs')
 $hello_name = Name of file when it was on the remote computer (e.g
'c:\hello.tmp)
 $hello_type = Mime type of file (e.g 'text/plain')
 $hello_size = Size of uploaded file (e.g 2000 bytes)

The temporary file is automatically deleted at the end of the execution of
the script so the PHP script usually needs to move it somewhere else. For
example, it might copy the file into a blob in a MySQL database.

The problem is actually in the way PHP behaves by default. Unless
deliberately configured otherwise (via register_globals = Off in php.ini)
the values specified in form fields upon a submit are auctomatically
declared by their form name as global variables inside the PHP script.

If I had a form with an input field like
 <INPUT TYPE="hidden" NAME="test" VALUE="12">

When the PHP script is called to handle the form input, the global variable
$test is set. In my opinion this is a significant security risk, in fact,
I'll be posting quite a few security issues based around it in the coming
weeks). The problem is simple, cluttering the global namespace with user
defined input so destablizes the environment that it is almost impossible to
write in it securely.

Back to the issue at hand. Using the fact mentioned above, we can create the
four variables $hello $hello_name, $hello_type, $hello_size ourselves using
form input like the following
 <INPUT TYPE="hidden" NAME="hello" VALUE="/etc/passwd">
 <INPUT TYPE="hidden" NAME="hello_name" VALUE="c:\scary.txt">
 <INPUT TYPE="hidden" NAME="hello_type" VALUE="text/plain">
 <INPUT TYPE="hidden" NAME="hello_size" VALUE="2000">

This should lead the PHP script working on the passwd file, usually
resulting in it being disclosed to the attacker.

[Fix]
Unfortunately, I believe this style of problem to be impossible to fix with
the default behaviour/configuration of PHP, I'll be demonstrating this with
several adviories in the next few weeks.

My suggestion to all administrators of PHP enabled boxes is to change the
register_globals in php.ini to off, and switch track_vars to on. This will
however lead to most PHP scripts breaking. In the short term, disable any
PHP scripts you have that provide file upload functionality until the vendor
of those scripts can provide a fix/determine non vulnerability.

For PHP coders with little control over the configuration of the boxes they
work on. Hopefully track_vars has been enabled on the box. Check if 'hello'
is present in $HTTP_GET_VARS, $HTTP_POST_VARS or $HTTP_COOKIE_VARS, if it
is, ignore the input. (*)

[Disclaimer]
Advice, directions and instructions on security vulnerabilities in this
advisory do not constitute: an endorsement of illegal behaviour; a guarantee
that protection measures will work; an endorsement of any product or
solution or recommendations on behalf of Secure Reality Pty Ltd. Content is
provided as is and Secure Reality does not accept responsibity for any
damange or injury caused as a result of its use.

---CUT---

Diese Sendung wurde Ihnen praesentiert von Jim
PGP encrypted mails welcome! Key on any keyserver or ftp://users.de
---
 Unix“ view of sex:
 unzip ; touch ; finger ; mount ; gasp ; yes ; umount ; sleep




php::bar PHP Wiki   -   Listenarchive