[<prev] [next>] [day] [month] [year] [list]
Message-ID: <Pine.BSO.4.63.0612211022500.6539@shinobi.blackhats.it>
Date: Thu, 21 Dec 2006 10:39:55 +0100 (CET)
From: Marco Ivaldi <raptor@...eadbeef.info>
To: bugtraq@...urityfocus.com
Subject: Re: Oracle <= 9i / 10g File System Access via utl_file Exploit
Hey Bugtraq,
Just a quick clarification about the recently posted code.
On Wed, 20 Dec 2006, sumit kumar soni wrote:
> HI, I don't think so its any new vulnerability or exploit (make me
> correct).
Yeah, you're right, there's no bug here -- just a feature. I wrote this
code during a recent security audit and since i found it to be useful i
decided to publish it in the public domain, pretty much as i did in the
past with:
http://www.0xdeadbeef.info/exploits/raptor_udf.c
http://www.0xdeadbeef.info/exploits/raptor_udf2.c
http://www.0xdeadbeef.info/exploits/raptor_oraexec.sql
As a side note, although i don't believe the mentioned MySQL UDFs exploit
an actual vulnerability, i've seen similar code used to get unauthorized
access to (misconfigured) systems:
http://www.theregister.co.uk/2005/01/28/mysql_worm/
> What i believe its a feature to acess OS files. it never come as a good
> practice to set utl_file_dir=*. On OS you cant set acess for an
> database acoount like scott or others.
As the advisory you mentioned clearly states:
"Keep in mind NEVER to set the init.ora parameter utl_file_dir=* or to
grant the privilege CREATE ANY DIRECTORY to PUBLIC".
Nevertheless, it's not terribly uncommon to find such setups, which allow
to escalate privileges from DBMS user to OS user... Therefore, i though it
would have been nice to share this proof-of-concept code with the security
community;)
Ciao,
--
Marco Ivaldi
Antifork Research, Inc. http://0xdeadbeef.info/
3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707
Powered by blists - more mailing lists