PDA

Bekijk Volledige Versie : Re: [Full-Disclosure] Possible bug in PHPNuke and other CMS



Sam Bashton
01/06/04, 23:05
On Sun, May 30, 2004 at 04:53:18PM +0200, Luca Falavigna wrote:
> There is a vulnerability in PHPNuke that permits execution of arbitrary
> SQL queries on a database located in the same server of an attacker's
> account. This is the procedure: first of all attacker must create a
> symlink pointing to victim's db directory in PHPNuke home directory
> because of mainfile.php include method. After that he can build a simple
> php code executing a query to the PHPNuke database. Here is an example:
>
> <?php
> require_once ("/location_of_victim's_PHPNuke/mainfile.php");
> $sql = $db->sql_query("SELECT aid,pwd FROM ".$prefix."_authors");
> while($record = $db->sql_fetchrow($sql))
> ~ echo "Username: $record[aid]\n<br>\nPassword: $record[pwd]\n<br><br>\n";
> unset($sql);
> ?>

This is an administration issue rather than a security vulnerability.
In order to use this attack the attacker requires access to:

1. Another site on the victim's server
2. A sufficiently poorly administered server on which (s)he can:
a. Create a symlink
or
b. Specify an absolute path for includes

Those hosting multiple PHP sites ought to be using PHP's open_basedir
directive to limit the files that can be opened by PHP. If this isn't
being used they are plenty of other easy attacks open to anyone with an
account on the same server.


--
Sam Bashton
Systems Administrator
IP Support

Alexander GQ Gerasiov
01/06/04, 23:35
Hello Luca,

Sunday, May 30, 2004 you wrote:

LF> -----BEGIN PGP SIGNED MESSAGE-----
LF> Hash: SHA1

LF> There is a vulnerability in PHPNuke that permits execution of arbitrary
LF> SQL queries on a database located in the same server of an attacker's
LF> account. This is the procedure: first of all attacker must create a
LF> symlink pointing to victim's db directory in PHPNuke home directory
LF> because of mainfile.php include method. After that he can build a simple
LF> php code executing a query to the PHPNuke database. Here is an example:

I'm sure that such problems must be fixed not with some hacks like
yours (checking domain name), but with webserver configuration (uid
and permissions, php abilities (like safe mode or open_base_dir
option) etc.)

--
Best regards,
Alexander GQ Gerasiov <bugtaq@gq.pp.ru>

BlueRaven
05/06/04, 19:45
Il giorno 01/giu/04, alle 19:13, Luca Falavigna ha scritto:

> File permissions must always permit execution of php pages by web
> servers. And symlink is followed and code executed because web servers
> must have access to that directory and code. We can operate with php
> security options too and obtain the same result but what if we cannot
> modify them? We are uncovered!!!

Agreed, but I think that, in this case, the real problem would be an
insecure configuration of the underlying webserver: any security-aware
administrator should configure it to NOT follow symlinks or, at last,
follow them if and only if the destination file belongs to the same
user (SymLinksIfOwnerMatch directive in Apache).

--
BlueRaven

Did you know that, if you play a Windows 2000 CD backwards,
you will hear the voice of Satan? That's nothing!
If you play it forward, it will install Windows 2000!!!