Forum OpenACS Q&A: Security: cgi-bin/cachemgr.cgi A*4096 attack?

Collapse
1: Security: cgi-bin/cachemgr.cgi A*4096 attack?
Posted by Andrew Piskorski on 10/26/04 03:16 PM
Early this morning, my old OpenACS 4.6.3 site (still running AOLserver 3.3+ad13, and using Oracle 8.1.7.4) threw an error I hadn't seen before, exactly twice. The info from my AOLserver access and error logs is shown below. Note that the 'host' bind variable conists of 65.202.186.194 followed by exactly 4096 'A' characters, which is why I'm calling this an "A*4096 attack".

Googling for cgi-bin/cachemgr.cgi seems to show that cgi-bin/cachemgr.cgi is used by Squid, and had a known exploit way back in Red Hat 6.0! That was fixed long ago, so possibly this was a probe by some sort of automated exploit tool which still has that exploit in its database? Has anyone else seen this attack recently?

As far as I can tell nothing bad happened to my website because of this, it's merely annoying that the attempted attack throws an Oracle error rather than being trapped in some nicer fashion. Is there any risk here that I'm not seeing?

The client IP address in my AOLserver access log is owned by UUNET. Am I correct in assuming that the attack really did originate from that address, that the client IP wasn't forged or anything like that? 

$ whois -h ws.arin.net 65.198.80.3
[ws.arin.net]
UUNET Technologies, Inc. UUNET65 (NET-65-192-0-0-1)
                                  65.192.0.0 - 65.223.255.255
E Commerce Group UU-65-198-80-D1 (NET-65-198-80-0-1)
                                  65.198.80.0 - 65.198.83.255

My access log has this:

65.198.80.3 - - [26/Oct/2004:04:19:11 -0400] ""200 0 "" "" -
65.198.80.3 - - [26/Oct/2004:04:19:11 -0400] "GET /cgi-bin/cachemgr.cgi HTTP/1.1" 302 338 "" "Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT;+DigExt)" -
65.198.80.3 - - [26/Oct/2004:04:19:11 -0400] ""400 0 "" "" -
65.198.80.3 - - [26/Oct/2004:04:19:11 -0400] ""200 0 "" "" -

And the corresponding error in my server log is:

Note: To avoid the annoying extrememly long line, I've replaced the 4096 A's in the string below. To convert back to the original, where you now see 'AAAAAAAAAA[atp-A-4096]', replace that with 4096 A characters: 

[26/Oct/2004:04:19:11][18353.14351][-conn11-] Notice: SQL():  

        select node_id 
	from host_node_map
	where host = :host

[26/Oct/2004:04:19:11][18353.14351][-conn11-] Notice: bind variable 'host' = '65.202.186.194AAAAAAAAAA[atp-A-4096]'

[26/Oct/2004:04:19:11][18353.14351][-conn11-] Error: ora8.c:3964:ora_tcl_command: error in `OCIStmtExecute ()': ORA-01460: unimplemented or unreasonable conversion requested

SQL: 

        select node_id 
	from !>>>!host_node_map
	where host = :host
      
[26/Oct/2004:04:19:11][18353.14351][-conn11-] Error: tclop: invalid return code from filter proc 'ora8.c:3964:ora_tcl_command: error in `OCIStmtExecute ()': ORA-01460: unimplemented or unreasonable conversion requested

SQL: 

        select node_id 
	from !>>>!host_node_map
	where host = :host

      ': must be filter_ok, filter_return, or filter_break
Collapse
2: Re: Security: cgi-bin/cachemgr.cgi A*4096 attack? (response to 1)
Posted by Don Baccus on 10/27/04 12:58 AM
Looks like Oracle varchars are limited to 4096 characters ... which we already know, right?

It's converting the bindvar to a varchar in order to do the comparison.

I'd say that it's probably not worth bothering to change the code to return a more immediately comprehensible error message.

Collapse
3: Re: Security: cgi-bin/cachemgr.cgi A*4096 attack? (response to 1)
Posted by russ m on 10/28/04 09:21 AM
The client IP address in my AOLserver access log is owned by UUNET. Am I correct in assuming that the attack really did originate from that address, that the client IP wasn't forged or anything like that?
odds are it is, but nslog (in AOLserver 4 at least) transparently replaces the remote host address with the content of an X-Forwarded-For: header if one exists... I suppose this is meant to be a good thing if you run nsd behind an accelerator like squid or pound, but it also allows an attacker to spoof their address to you and (if you're not behind an accelerator) can fill up your logs with potentially meaningless client addresses... personally I fix nslog to not do that on all my live servers...