On Mon, 3 Feb 2003, Maxim Maletsky wrote:

> "James E. Flemer" <[EMAIL PROTECTED]> wrote... :
>
> > I found a more evil example:
> >
> > <?php
> >   $a = "___! `rm -rf /tmp/sess_*` !___";
> >   $b = preg_replace("/!(.*)!/e", "print(\\1);", $a);
> > ?>
> >
> > This happily executes "rm -rf /tmp/sess_*".  I will not
> > give out more examples, but if one examines the code for
> > addslashes() it is quite obvious what you can an cannot do
> > here.  Thus it is clearly a Bad Thing for someone to use
> > preg_replace with the /e modifier and not use quotes around
> > the \\n or $n backrefs.
> >
> > The docs should be updated to include a very noticeable
> > warning about this hole.  I am contemplating possible
> > solutions for this problem...
--snip--
>
> In fact, /e eval()uates the code. It does with the replaced result just
> what eval() does with a string PHP code. At most, it could be noted in
> docs.

Yes, I am aware of that, that is what /e is for.  The issue
is not that it eval()s the code, the issue is weather or
not the backrefs (\\1 or $1 etc) are enclosed in single
quotes.  The preg_replace()  code calls php_addslashes() on
the backref data, so if the backref is enclosed in quotes
then there is no way to do anything malicious.  However if
a PHP coder writes a script that uses preg_replace()
without placing quotes around a backref, and the subject
(arg 1) of the function can be supplied by the remote user,
then the remote user can easily insert potentially
dangerous code that will be executed on the server with the
running permision of the web server.

Now consider the use of this expliot in conjunction with a
know local-user expliot for some OS.  PHP provides
convinient easy access to execute arbitrary commands as a
local user...  I think it should be explicitly stated in
the docs for preg_replace() that Bad Things can occur if
backrefs are not enclosed in single quotes, and that mildly
bad things can occur if they are enclosed in double quotes
(i.e. variable expansion of possibly sensative local
variables).

-James


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to