Re Re: PHP 5.2.4 <= various mysql functions safemode & open_basedir bypass

Hi Ronald

"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@gmail.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."

I totally agree on this, PHP is currently very used because it's easy to use. You know i see the safemode function in PHP AS an anti-virus on a windows box . "you dont know what you use , where you click, you just want it working,and "safely" ? dont worry we will protect you ."
To me,that's all the reason to be of the "safemode". Now in a context like this .. we can call this as a PHP *bug* even if we know that no.

> <?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. ==> & safemode     Apache has directory restrictions.
    ....But, well, mysql?

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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

==> mysql_connect => granted_user(for load_file)/or_misconfigurated_user_perms. (as in many case[like the into outfile/dumpfile -> select 'hello i dont like you' into dumpfile '/bla/not_my_friend/www/index.html'; -> considering too that his www or some other folder is not properly chmoded ...as also in many many case .]

PHP offers the possibility to interact with mysql/&others i think safemode/open_basedir should totally watch what's going to mysql ( like those "into outfile/dumpfile" , for sure "load_file" it's different, but considering the fact that they build/integrate a "safemode" into PHP then they should watch this kind of stuff.)

but once again .. i totally agree with your point,in a shared webhosting context, if you start to trust theses kinds of functions and then let some holes in the wall letting in the water, your shared env will be down very soon .
So i guess the question should be :
"shall i let a software drive my security or shall i rtfm and start to know what i'am doing ?"//not talking only about php here. anyways that's another subject...

regards laurent gaffié

   "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.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

    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 oversubscribed      their hardware, the current solution seems to be "point     and giggle".

    -Ronabop Received on Wed Sep 12 12:41:39 2007