Audit shows used privilege not owned by the user

[Nicolau Roca]

Hi,
we have lots of records in the audit file like this

Security alarm (SECURITY) and security audit (SECURITY) on V2, system id: 63497
Auditable event: Object access
Event time: 29-AUG-2008 06:00:03.27
PID: 21C08678
Process name: ORA_FUEI_J000
Username: ORACLE10R2
Process owner: [DBA,ORACLE10R2]
Image name: DSA11:[ORACLE10R2.ORA_HOME.BIN]ORACLE.EXE
Object class name: FILE
File name: _DSA10:[USR.SCI.ALUBATCH.EDI.REMESES.PENDENTS.RECEPCIO]0061FUEQ57_0710020806.qdn;1
File ID: (33022,20,0)
Access requested: READ
Privileges used: BYPASS
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)
Sequence key: 113DDC5E
Status: %SYSTEM-S-NORMAL, normal successful completion

But username ORACLE10R2 does NOT have the BYPASS privilege.

Any ideas of what's going on?

Thank you

[Oswald Knoppers_1]

The ORACLE.EXE image is probably installed with privileges. You can check this with:

$ install list/fu dsa11::[ORACLE10R2.ORA_HOME.BIN]ORACLE

Oswald

[Nicolau Roca]

Hi Oswald

The oracle.exe image doesn't seem to have special privileges:

V2::> install list/full DSA11:[ORACLE10R2.ORA_HOME.BIN]ORACLE

DISK$ORA10R2:.EXE
ORACLE;1 Open Hdr Shared
Entry access count = 23317
Current / Maximum shared = 98 / 194
Global section count = 1

Thank you anyway

[Jon Pinkley]

How do you know it doesn't have BYPASS priv?

Are you looking at the proess or the UAF record?

Does ORACLE10R2 have SETPRV? That would be the easiest explanation. If not, does it have any in the ALL class? I.e. does

$ mcr authorize show/br oracle10r2 show privs as "ALL"

If the process with pid 21C08678 is still around, what do the follwoing show?

$ write sys$output f$getjpi("21C08678","AUTHPRIV")

$ write sys$output f$getjpi("21C08678","CURRPRIV")

$ write sys$output f$getjpi("21C08678","IMAGE_AUTHPRIV")

$ write sys$output f$getjpi("21C08678","IMAGE_PERMPRIV")

$ write sys$output f$getjpi("21C08678","PERSONA_AUTHPRIV")

$ write sys$output f$getjpi("21C08678","PERSONA_PERMPRIV")

$ write sys$output f$getjpi("21C08678","PERSONA_WORKPRIV")

Jon

[Nicolau Roca]

Hi Jon

I'm looking both at the process and in the UAF record, and yes, ORACLE10R2 has privileges in the ALL class:

Owner Username UIC Account Privs Pri Directory

Oracle 10gR2 DBA ORACLE10R2 [30,2] All 4 DISK$ORA10R2:[ORACLE10R2]

These are the authorized privileges as shown in the UAF record and also with a show process/priv:
ALTPRI CMKRNL GROUP GRPNAM IMPERSONATE LOG_IO
NETMBX OPER PFNMAP PRMGBL PRMMBX SHARE
SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX VOLPRO
WORLD

So is this enough to explain the use of the BYPASS privilege in the audit record?

(The process with PID 21C08678 is already finished)

Thank you

[Jon Pinkley · Accepted solution]

Short answer: Yes; that could explain it.

Of the privs listed, CMKRNL is one of the easiest to exploit for enhanced access. It allows user provided code to be executed in Kernel mode, which has access to everything. And when in kernel mode, privs do not mean much

That isn't the only possible explanation. Unfortunately, the audit record does not show which of the "current" privilege masks was providing BYPASS. It could be the processes mask, or a privilege from the image activator (installed image priv, although that did not appear to be the case), or from a persona. (I am not 100% sure that it is impossible to tell the difference from the audit record, just that there is noting in the one you provided that indicated what priv mask was used.

You stated you also looked at the process privileges.

In a process with CMKRNL as an authorized privilege, it is certainly possible to write a program that will turn privs on, do something and then return them to the previous state, such that a show proc/priv before running and after running would show no enhanced current privileges. And it is possible to turn the privs on and off, so even looking at the privs from another process isn't a guarantee that you would see the privs turned on.

You may want to ask Oracle why you are seeing these audit records.

Jon

[Jerry Eckert]

A program running with CMKRNL can grant itself any other privilege. Whether this is what happened in your case, I don't know.

[Nicolau Roca]

Ok, so I will assume that somewhere in the Oracle code the CMKRNL privilege is exploited in order to provide the BYPASS privilege.

Thank you Jon, Jerry and Oswald for your answers

Regards

Nicolau