Re: PHP Nuke <= 7.8 Multiple SQL Injections

[Daniel Bonekeeper <thehazard () gmail com>]

I made some tests and seems to me that just environments where
magic_quotes_gpc = 'Off' are affected (which is not default on php).
When magic_quotes_gpc = On, the query that is sent to database is
interpreted as:

SELECT active, view FROM nuke_modules WHERE title='\' OR 1=2 /*'

Which is properly slashed. But, if we do have magic_quotes_gpc = Off,
it's interpreted as:

SELECT active, view FROM nuke_modules WHERE title='' OR 1=2 /*'

Which is exploitable. 


On 9/15/05, Paul Laudanski <zx () castlecops com> wrote:
> On Fri, 16 Sep 2005, Matthias Jim Knopf wrote:
>
> > What do you gain from that? In what way would you think your advice did
> > ANYTHING GOOD?
> > You did neither issue a "addslashes()" as appropriate for SQL-commands,
> > nor did you explain, why a variable set by a POST or a COOKIE could be
> > worse than anything you could give any URL by appending '?name=...' or
> > '&name=...' (->GET vars)
>
> If you read the code and original advisory, there is filtering already in
> place within the PHP-Nuke framework that monitors HTTP GETs.  As such,
> this 'exploit' makes of variables which should only be passed via HTTP
> GETs and not POSTs nor cookies.
>
> Proper data sanitization for this is simply to retrieve what is expected:
>
> $name = $_GET['name'];
>
> The function you specify like http://php.net/addslashes is neither here
> nor there.  Why use that function for a variable in POST or cookies when
> it is clearly expected to be returned via GET alone?
>
> Ergo:
>
> register_globals off !
>
> --
> Paul Laudanski, Microsoft MVP Windows-Security
> CastleCops(SM), http://castlecops.com
>
>
>
> ________ Information from Computer Cops, L.L.C. ________
> This message was checked by NOD32 Antivirus System for Linux Mail Server.
>
>  part000.txt - is OK
> http://castlecops.com


-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil