Call: +44 (0)7759 277220 Call

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "CPU July 2007 is out"] [Next entry: "Checksumming on all supported versions of Oracle"]

First exploit released for CPU July 2007

Today Alex posted that Andrea Purificato has released an exploit for the view bug fixed in the July 2007 CPU. Bunkers exploit code is here. Alex has shown a similar example in his post "Exploit for create view published" but he points out an issue with the exploit in that the changed password cannot be used without restarting the database.

I have not tested but i suspect that flushing the SGA may allow its use as well as the reason that it doesnt work is likely to be because the old hash is likely to be buffered. Also SYS.USER$ is not likely to be accessible to create a view like this anyway.

There has been 4 Comments posted on this article

July 25th, 2007 at 10:24 am

Jr says:

From user TEST with the privileges as shown, doesn't work :

SQL> desc sys.user$
ORA-04043: object sys.user$ does not exist

neither :

select,x.password from sys.user$ x left outer join sys.user$ y on
ERROR at line 2:
ORA-00942: table or view does not exist

July 25th, 2007 at 11:53 am

bunker says:

Obviously sys.auth$ must be accessible by the target user (normally dbsnmp or application users can do that).

Otherwise you can use the sample to craft a special view that can access everything you want with only the select privilege (i think about insert or update on application's tables and more...)


July 27th, 2007 at 07:14 am

seydon says:


Tried this.
don’t work.


Have right for select on table Contragent.
Write script:
create or replace view test_hack_view as select, x.insiderid from cret.contragent x left outer join cret.contragent y on;
update test_hack_view set insiderid='1' where id='12345';


and receive error:
ORA-01031: insufficient privileges.

What’s right I must have for this exploit?

July 27th, 2007 at 05:01 pm

Pete says:

As i pointed out in the post, the code as described wont work as a user with simple privileges cannot access SYS.USER$ but as bunker points out the attack is useful if you have access to a user who does have access to key tables.

The exploit is fine, the issue is its usefulness for a user with limited privileges as bunker points out in this case the main usefulness would be to attack tables the user can see for example application data.