bugtraq - Re: 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 12:51:54 -0800
From: "Thor \(Hammer of God\)" <thor@...merofgod.com>
To: "David Litchfield" <davidl@...software.com>, <bugtraq@...urityfocus.com>,
	<full-disclosure@...ts.grok.org.uk>, <dbsec@...elists.org>
Subject: Re: More on the workaround for the unpatched
	Oracle PLSQL Gateway flaw


Actually, there is a patch that addresses this, and other critical Oracle 
security issues:

http://tinyurl.com/b4yws

HTH

t

-----
"I'll see your Llama and up you a Badger."
John T



----- Original Message ----- 
From: "David Litchfield" <davidl@...software.com>
To: <bugtraq@...urityfocus.com>; <full-disclosure@...ts.grok.org.uk>; 
<dbsec@...elists.org>
Sent: Thursday, February 02, 2006 10:39 AM
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/