FAQ
Block Browser Editor

They cannot call it DBED (datablock editor ) because Veritas already has
first dibs on the acronym (Veritas database edition, which includes qio ad
cached qio) and allows true direct IO to UFS (Vxfs) without requiring raw
device, another story though.

Check Metalink, they have some info on it (BBED) . I first heard of this
indirectly from Jeff Holt (blimin genius if I ever met one).

Ferenc Mantfeld

-----Original Message-----

From: Arup Nanda [SMTP:arupnanda_at_hotmail.com]
Sent: Wednesday, November 27, 2002 1:24 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Oracle OS level security

What is BBED? I never heard of it.
From: "K Gopalakrishnan"
Reply-To: ORACLE-L_at_fatcity.com
To: Multiple recipients of list ORACLE-L
Subject: RE: Oracle OS level security
Date: Tue, 26 Nov 2002 16:09:27 -0800
MIME-Version: 1.0
Received: from newsfeed.cts.com ([209.68.248.164]) by
mc8-f17.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov
2002 17:06:39 -0800
Received: from fatcity.UUCP (uucp_at_localhost)by newsfeed.cts.com
(8.9.3/8.9.3) with UUCP id RAA43612;Tue, 26 Nov 2002 17:01:24 -0800 (PST)
Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 0050CFBE;
Tue, 26 Nov 2002 16:09:27 -0800
Message-ID:
X-Comment: Oracle RDBMS Community Forum
X-Sender: "K Gopalakrishnan"
Sender: root_at_fatcity.com
Errors-To: ML-ERRORS_at_fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0g, build 72; ListGuru (c) 1996-2001 Bruce A. Bergman
Precedence: bulk
Return-Path: root_at_fatcity.cts.com
X-OriginalArrivalTime: 27 Nov 2002 01:06:39.0079 (UTC)
FILETIME=[3D590770:01C295B1]
Jared:

Any one with a reasonable knowledge of Oracle Data Storage
Internals can use the Data block Editor (BBED) to update
anything in your database without the knowledge of the
RDBMS kernel auditing mechanisms.

Agreed,BBED is protected by a password in Windoze ports
and one need to explicitly make the executable in Unix
ports. But the point here is the hacker can do anything
using the BBEd and this can be done even while your
database is up and running !!

What is their take on this kind of attack(!)s?>


Best Regards,
K Gopalakrishnan




-----Original Message-----
Jared.Still_at_radisys.com
Sent: Tuesday, November 26, 2002 3:05 PM
To: Multiple recipients of list ORACLE-L


Dear list,

Let me toss a hypothetical situation at you.

Say some auditors looked at some of your primary systems,
and concluded that they had no assurance that someone with
admin access to the server had not changed financial information
to benefit themselves, or to falsify financial records for the
gain of the company.

Not that they might have any proof that something like that
had been done, but rather, just not proof that it had *not*
been done.

I've been pondering this for a bit, and it seems to me that if
someone had good knowledge of both the OS and the
database (Oracle), as well as having admin rights on the
server, there are few things you can do to prevent such a person
from changing data in the database, and completely
covering his or her tracks.

The platforms in question are Unix, Windows NT and
Windows 2000. I've limited it to those as most database
systems use one of those, and besides, that's all I know. :)

Consider what steps you might take to audit unauthorized
transactions performed by an admin.

Oracle Auditing could be used, but someone with admin
access to the server and database could easily alter the
records created by system auditing.

You could create an audit table, using a trigger to audit
sensitive tables. A materialized view on a remote database
could be created on sensitive tables to remotely log all
actions.

In the case of the audit table, that could easily be disabled,
and then re-enabled after the nefarious DML had completed.

The materialized views might be more difficult to circumvent.

If the remote end is using a dblink to the server employing a
password that is *different* than that of it's own account at the
remote server, it should be impossible for someone to completely
cover the traces of transactions created to falsify data.

The MV Logs could be dropped, but without access to the MV's
at the remote server, the MV's would have to be left in place.

These could be used as a reference to look for unauthorized transactions
in the primary server. If this same admin has access to the remote
server where the MV's are, then this can also be circumvented.

There is also the logs created as when logging in as internal
or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud )

These can simply be deleted. Some system could be used to save
these to a remote server, but it would have to run *very* frequently to
be effective.

Oracle password files could also be used. While this can prevent
someone from logging in as SYS or SYSTEM while in place, all it
takes is a change to init.ora, and a database bounce to fix that.

Make your bogus data changes, change the init.ora back and
bounce the database again.

A somewhat clever person could set this up to automatically
take place the next time the DB is bounced.

The conclusion I have come to is that the only effective method
that could be used to create an audit trail for such a scenario is
to create Materialized Views on sensitive tables, and create them
on a server that admins are guaranteed to not have access to.

Of course, I may be missing something. I'm not always one to
catch all the details right off. Input, comments, suggestions, far
out ideas are all welcome.

If you've read this far, thanks!

Jared





--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: Jared.Still_at_radisys.com

Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).


--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: K Gopalakrishnan
INET: kaygopal_at_yahoo.com

Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Arup Nanda
INET: arupnanda_at_hotmail.com

Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: mantfield
INET: mantfield_at_connexus.net.au

Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedNov 27, '02 at 3:14a
activeNov 27, '02 at 3:14a
posts1
users1
websiteoracle.com

1 user in discussion

Mantfield: 1 post

People

Translate

site design / logo © 2022 Grokbase