Re: Interesting Exploit in PL/SQL
- From: "Stefan Knecht" <knecht.stefan@xxxxxxxxx>
- To: "Niall Litchfield" <niall.litchfield@xxxxxxxxx>
- Date: Fri, 1 Dec 2006 12:02:59 +0100
ORA-20001 ? :) Assuming you've created a before noaudit trigger... Could be
several reasons why someone has such a trigger. If the reason was a foolish
developer playing around, then we lost with our approach, and an unwanted
audit could stay in place. If it's legitimate, and the audit has to stay in
place no matter what (which I suppose is the purpose of such a trigger) then
no harm done either.
Aside from that, the "disable" procedure was sort of an emergency only
thing. That would just turn off auditing wherever possible as quickly as
possible, should problems - of performance or other nature - arise. And we
really wouldn't want that to abort no matter what. And WHEN OTHERS THEN
NULL; is just what we need.
Stefan
On 12/1/06, Niall Litchfield <niall.litchfield@xxxxxxxxx> wrote:
On 12/1/06, Stefan Knecht <knecht.stefan@xxxxxxxxx> wrote:
> Well yeah, for the 'enable' procedure we do. But when we try to disable
it,
> and Oracle doesn't like that, we just don't care - because if it can't
be
> disabled, it couldn't have been enabled in the first place :)
Have a think about this then.
SQL> CONN NIALL/JASPER@ASDB
Connected.
SQL> AUDIT INSERT ON T;
Audit succeeded.
SQL> ALTER TRIGGER AUDIT_TRIGGER ENABLE;
Trigger altered.
SQL> NOAUDIT INSERT ON T;
NOAUDIT INSERT ON T
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-20001: AUDIT CHANGES NOT ALLOWED
ORA-06512: at line 2
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
