Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Full Disclosure: Re: More on the workaround for the unpatched Oracle PLSQL Gateway flaw

Re: More on the workaround for the unpatched Oracle PLSQL Gateway flaw

From: Thor (Hammer of God) <thor_at_hammerofgod.com>
Date: Thu, 2 Feb 2006 12:51:54 -0800

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_at_ngssoftware.com>
To: <bugtraq_at_securityfocus.com>; <full-disclosure_at_lists.grok.org.uk>;
<dbsec_at_freelists.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/
Received on Feb 02 2006

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos