bugtraq - Re: PHP Nuke <= 7.8 Multiple SQL Injections

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: Fri, 16 Sep 2005 15:27:43 -0800
From: Daniel Bonekeeper <thehazard@...il.com>
To: Paul Laudanski <zx@...tlecops.com>
Cc: jim999@....net, r.verton@...il.com, bugtraq@...urityfocus.com,
	bugs@...uritytracker.com, moderators@...db.org, news@...uriteam.com,
	vuln@...unia.com
Subject: Re: PHP Nuke <= 7.8 Multiple SQL Injections


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@...tlecops.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