bugtraq - Re: PHP 5.2.4 <= various mysql functions safemode & open

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 11 Sep 2007 22:59:36 -0700
From: Ronald Chmara <ron@...s1.COM>
To: laurent.gaffie@...il.com
Cc: bugtraq@...urityfocus.com
Subject: Re: PHP 5.2.4 <= various mysql functions safemode & open_basedir bypass

Two years ago, I wrote a semi similar post to this one, but, well,  
I'm old and tired of seeing this now. Time for folks to upgrade.

On Sep 10, 2007, at 9:38 PM, laurent.gaffie@...il.com wrote:

> Application: PHP <=5.2.4
> Web Site: http://php.net
> Platform: unix
> Bug: safemode & open_basedir bypass
> ======
> 2) Bug
> ======
> various mysql functions safemode & open_basedir bypass
> ( LOAD_FILE , INTO DUMPFILE , INTO OUTFILE )

Not a PHP *bug*, so much as yet another reason why "safe mode" and  
"open_basedir" are fundamentally wrong ideas (and are being  
terminated, with prejudice, in future PHP development). Users (and  
hosting companies) are unedumacated on how the whole concepts of  
permissions work, turn on something they think is "safe", and are  
surprised by the results.

> <?php
> mysql_connect("localhost", "granted_user","something");
> mysql_query("select load_file(0x2F6574632F706173737764)into  
> dumpfile'/test/123.txt';");
> ?>

In this case:
PHP has basedir restrictions.
Apache has directory restrictions.
....But, well, mysql?

What restrictions have you placed upon it, per user, and filesystem?

Apparently, it's allowed to write to /test/, *and* the user perms  
used to talk to mysql seem horribly broad, since it can get user  
perms. So, since any Apache/PHP/mysql user on a shared host (or  
whatever) in the above scenario can write to whatever they want from  
mysql to /test/, it's fair game.

You see, any PHP library used, be it mysql, odbc, *whatever*, that  
can be given arguments, *and does not filter* those arguments *in the  
library*, based on per-apache-instance-per-user restrictions, can be  
used to cross boundaries, escalate boundaries, etc.

Since on a shared host, it's often the case that 20. or 50, or  
whatever many users have permissions (though apache and mysql) to  
write to any directories that apache and mysql have write permissions  
to, yes, PHP can *try* to clean up the activities involves, but it's  
a fools errand.

mysql_query("select load_file (foo) into dumpfile'/ 
massive_directory_pool/user_i_hate/index.html;");
# if the mysql user has perms, Game over. PHP/apache isn't even  
relevant anymore, if *mysql*
# has perms to write to the user's directory

So, for mental exercise: A GD library creating an "image" in another  
directory, because apache and PHP trust GD? How about a PDF file? A  
blog backup file?

You see, the problem *isn't* PHP, it's underlying libraries  
inheriting perms, and using perms, that are not appropriate for the  
purpose of isolating users.

The fix?

Give each user their own apache, their own mysql, their own chroot'ed  
box (or vm/xen image..).

Since that's not gonna happen anytime soon for resellers who over- 
subscribed their hardware, the current solution seems to be "point  
and giggle".

-Ronabop