bugtraq - More on the workaround for the unpatched Oracle PLSQL Gateway flaw

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: Thu, 2 Feb 2006 18:39:44 -0000
From: "David Litchfield" <davidl@...software.com>
To: <bugtraq@...urityfocus.com>, <full-disclosure@...ts.grok.org.uk>,
	<dbsec@...elists.org>
Subject: More on the workaround for the unpatched Oracle
	PLSQL Gateway flaw

According to Oracle, the workaround I posted, that prevents exploitation of 
a critical vulnerability that Oracle has so far failed to fix, breaks 
certain applications that sits atop their PLSQL Gateway. Though my 
workaround prevents exploitation of the critical flaw and thus protects 
vulnerable systems against attack, Oracle has made no effort to furnish me, 
or anyone else for that matter, with more information on how the workaround 
breaks some of their applications. As such, improving the workaround so it 
doesn't break these few applications has been mildy annoying. But I think 
I've tracked it down. The workaround as is

RewriteEngine  on
RewriteCond %{QUERY_STRING} ^.*\).*|.*%29.*$
RewriteRule ^.*$ http://127.0.0.1/denied.htm?attempted-attack
RewriteRule ^.*\).*|.*%29.*$ http://127.0.0.1/denied.htm?attempted-attack

will trigger if a right facing bracket ')' appears in the PATH_INFO or 
_anywhere_ in the query string. Thus, if the value of a query string 
parameter contains a bracket the workaround will trigger. As far as the flaw 
is concerned, we need only concern ourselves with brackets that appear in 
the query string parameter name - not in the value for the parameter name. 
As such, if we modify the workaround to

RewriteEngine  on
RewriteCond %{QUERY_STRING} ^.*\).*=|.*%29.*=$
RewriteRule ^.*$ http://127.0.0.1/denied.htm?attempted-attack
RewriteRule ^.*\).*|.*%29.*$ http://127.0.0.1/denied.htm?attempted-attack

we can prevent exploitation if the query string parameter name has a bracket 
whilst still allowing brackets it the paramter value. This can be tidied up 
to read

RewriteEngine  on
RewriteCond %{QUERY_STRING} \).*=|%29.*=
RewriteRule .? http://127.0.0.1/denied.htm?attempted-attack
RewriteRule \)|%29 http://127.0.0.1/denied.htm?attempted-attack

# Thanks, Mike Pomraning!

For those that haven't been able to adopt the workaround because it would 
break their specific application, then the modified workaround should work 
in your situation.

Cheers,
David Litchfield

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/