full-disclosure - I have fixes for the Geeklog vulnerabilities

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] [day] [month] [year] [list]

From: jouko at iki.fi (Jouko Pynnonen)
Subject: I have fixes for the Geeklog vulnerabilities

Hello,

On Sun, Oct 05, 2003 at 09:00:30PM +0200, Lorenzo Hernandez Garcia-Hierro wrote:

> - sql injections fix  -
> 
> // Geeklog SQL Injection prevention fix
> // by Lorenzo Hernandez Garcia-Hierro
> function DB_query($sql, $ignore_errors=1)

<snip>

> Thats all but if you want to have a strong sql injection and error control
> go to line  441 , you see:
> 
> function DB_error()
> {
>     global $_DB;
> 
>     return $_DB->dbError();
> }
> 
> you can edit the function to write the ip of the client that make the error
> and block it , more agressive technics are easy to code ;-)

This is probably obvious, but ignoring errors or banning clients who 
cause them is not a particularly strong SQL injection control. This fix 
merely hides the error message, which is way insufficient. When
exploiting a remote buffer overflow, you don't get an error message 
telling you which parameter or offset was wrong, but that hardly stops 
people from exploiting them.

Even with this fix, it's possible to exploit an SQL injection 
bug in Geeklog (even though one you didn't mention) to hijack the admin 
or any other account - without  generating an error message. I sent an 
exploit to the Geeklog developers today and will post it later if 
needed.

And a couple of observations about Mr. Garcia-Hierro's IP banning 
code... Firstly, if X-forwarded-for: and Via: headers are set, you 
trust them and ignore the client's IP. These can be set by the client 
to anything, so a banned user can just choose an IP to send and 
circumvent the ban (using netcat, their own web proxy, patched browser, 
etc.). So both the IP (REMOTE_ADDR) and HTTP headers should be checked.

Secondly, your MySQL backend does this:

> $doit = mysql_query("SELECT * FROM banninip WHERE ip='$ip'",$db); 

If the $ip variable comes from those HTTP headers too, your code has 
another SQL injection bug and probably exploitable with newer MySQL 
servers.

A solution to both this one and Geeklog's problems is AFAIK use of 
addslashes(), which escapes single quotes and backslashes from user 
input.

Thanks,

-- 
Jouko Pynn?nen          Web: http://iki.fi/jouko/
jouko@....fi            GSM: +358 41 5504555