Three Tier Oracle Security in London ~ Paul M. Wright

(nix, oracle, java, www, cloud ) intersect (safety, security, reliability, integrity)

Three Tier Oracle Security in London ~ Paul M. Wright RSS Feed

JAVA$POLICY$ Past Exploitation Check

Hello Oracle Security interested folks,

Firstly thanks to Oracle for referencing my Oracle Wallet article on as well as the interesting comments from our readers. This blog has become quite popular so thank you for your support.

I have some excellent news as my company has been selected as a Channel Partner for Sentrigo covering the South East of England. Some of you may be aware that I have already successfully deployed the Hedgehog solution within the financial services sector in London over the past 2 years.
Reliable, low resource consuming, host-based DB/Application monitoring has been the holy grail for the last decade and is provably with us in the form of Sentrigo Hedgehog. Effective DB/App security has to be host-based and Sentrigo’s is the best host-based agent because they specialise in this technology. Further details can be provided to backup this assertion by emailing myself at

So.. here is a simple query for finding user accounts which have had their Java privileges escalated and then the user has subsequently been dropped:

select * from JAVA$POLICY$ where grantee# in (select grantee# from sys.JAVA$POLICY$ minus select user# from sys.user$);

If this check returns a resultset it is potentially indicative of historic Java exploit testing in the DB… more in-depth information to come on Java Security at ISSD.


4 Responses to “JAVA$POLICY$ Past Exploitation Check”

  1. 1

    Thanks for this Paul. This is the list of users that have been deleted that also had Java privileges.
    How does that give us a history of past exploitation?

  2. 2
    Paul Wright:

    Hi Don,
    If DB users were to test the Java exploitation code in Oracle the normal process would be to create a test user, escalate it and then drop the user so that it can ascertained if the exploit works using this test account, but without leaving evidence of this testing. This would usually be on a dev box. The idea is that the exploit has been tested but no evidence of that fact left behind. HOWEVER, historic privileges of dropped users are still recorded in JAVA$POLICY$ as first pointed out at this blog entry . The other potential scenario is the privs are granted and then revoked from the attacker’s account. These grants for existing users are recorded as well of course but that is easily viewable in DBA_JAVA_POLICY view.

  3. 3
    Pete Finnigan:

    Hi Paul,

    In respect to Don’s comment. What if a clever hacker decides not to test it first?



  4. 4
    Paul Wright:

    Hi Pete,

    First of all apologies for not getting back to you on this one sooner. I had to freeze comments on here as WordPress was suffering from spam terribly.

    I have upgraded the wordpress and it enables spam removal, so I can now see your reply.

    The answer is that the query will identify users that have been granted Java privileges and then been dropped. Classic attack scenario. Attacker creates another account and grants it DBA or in this case JAVA_ADMIN. As you know normally oracle does not record dropped users. Therefore for post incident response this is a useful base table to select from. The fact that the view above ommits this information is interesting. This is a great example of where knowledge of the base tables can pay dividends.

    My point about testing was that just because this query results in finding users that have been escalated and dropped does not mean that the DB has been attacked as it may just be that someone has been testing exploit code. Either way the check is obviously useful for identifying Java priv escalation in Oracle DBs. I think it is the first incidence of a Java Forensics test, but would like to hear if anyone has an earlier example.


Leave a Reply

You must be logged in to post a comment.