Pete Finnigan's Oracle Security Weblog

The paper "Identifying Yourself in the Oracle Database" is available as a pdf to download from my Oracle security white papers page.

This is new paper in terms of it has not been posted to my site before but i have presented this paper at around 4 conferences so far; the UKOUG conference last year, a SIG, the OWASP chapter in Leeds and also the Norway Oracle user group earlier this year. I wrote a paper last year about identity and accountability in the Oracle database to illustrate the problem that in a normal database (EE or SE) without additional identity products what you see in the database as session details is not much and in terms of identifying an individual its difficult unless the individual can be tied to external sources first (smart card, two factor authentication, ldap, fixed IP address....). What I show next is that there are other sources of data that can help add some "bulk" such as the listener log or trace output or other logs.

What is worse is that when the database audit is enabled little sesison data that is useful ends up in the audit trail; in fact the worse issue is that only one value can be manipulated (legally) that ends up in the database audit trails. We can manipulate other values that do end up in the audit trail but that is spoofing. So we look at spoofing session details and cover those that are easy and those that are slightly harder. In fact the only one that is not easy to spoof is the proxy user; the actual username can be spoofed by use of BECOME USER. This leads to the fact that some spoofing can be done before the session and some like BECOME USER after so these should be detectable.

I also look at customising identity via application interfaces available in PL/SQL or via OCI or JDBC.

One the the issues with session values besides relying on them in audit trails is that they are often used to set up FGA, or VPD or system triggers or label security or.... This is a potential issue as security often uses security and we therefore have to protect the security features in just the same way as none security features; in other words if you rely on some value such as "os user" or "database user" in a context used in a secure application role or in VPD then you must ensure it has not been changed or meddled with.

I finish with a short discussion on detecting spoofing of session values and then talk about solutions. The detection and solutions are three slides from the total so most of the paper is about discussing the issues rather than how to detect and correct.

Maybe it would be a good topic for a new paper for me to create "part 2" and talk in much more details about detecting identity spoofing in the database and also about hardening and protecting against changes in these areas.