Re: Fw: OT - Getting fired for database oops
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: dbvision@xxxxxxxxxxxx
- Date: Tue, 26 May 2009 12:46:19 +0100
On Tue, May 26, 2009 at 11:36 AM, Nuno Souto <dbvision@xxxxxxxxxxxx> wrote:
> Andre van Winssen wrote,on my timestamp of 26/05/2009 3:58 PM:
>
> That’s the reason I bring it up. Oracle server processes, including TNS
>> listener, can be used to write entries into this file, remotely, through
>> database calls (using DIRECTORY, java stored procedures that are allowed to
>> write to the os, UTL_FILE, UTL_TCP, FTP,..). No protection on OS level
>> whatsoever will prevent this because these actions will be run in oracle
>> security context and oracle server process owns the glogin.sql. Once
>> glogin.sql on the server side is tampered with the first (sys)dba user on
>> the server who starts up sqlplus will run the statements from glogin.sql
>> without a problem.
>>
>
> I quite don't get this. If someone executes one of
> these things remotely, don't they have to be logged in anyway?
> Or are we saying it's possible to execute a UTL_FILE for example
> without being logged on? And hopefully duly authorized to run it?
>
depending on version and security patch level then yes there are without
authentication exploits available. Even if they aren't UTL_FILE is commonly
granted to quite a lot of people that you wouldn't allow anywhere near your
server. I believe by default it is granted to PUBLIC for example. I'm not
sure that (g)login.sql is the most likely attack vector for someone savvy
enough to be mounting this sort of attack, but I must admit I had an 'of
course you could do that, doh!' moment when I read his post, now helpfully
available via google unfortunately.
Niall
--
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision@xxxxxxxxxxxx
--
>
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
