Pete Finnigan's Oracle security weblog

[Previous entry: "Some training and speaking dates"] [Next entry: "One more point on Oracle password crackers"]

Update to Dennis Yurichevs FPGA cracker plus exploit code for the CPU CVSS 10.0 bug

October 30th, 2009 by Pete

Post to del.icio.us   Post to Furl  

I got an email from Dennis Yurichev to say that he has improved the output of his FPGA cracker to now include the speed at which its cracking. Great, I asked for this enhancement. To test it i have created two sample users for my 11.1.0.7 database as follows:

SQL> connect system/oracle1@ora11gpe Connected. SQL> create user AA identified by zzhg76j; User created. SQL> create user AB identified by aaghb6g; User created. SQL> select name,password from sys.user$ 2 where name in ('AA','AB'); NAME PASSWORD ------------------------------ ----------------------- AA 3FC24C0BFAED94B1 AB 111E83722DB9BF88 2 rows selected. SQL>

I then added them to Dennis's FGPA cracker page. You can see this here:


I had created two tests before looking at the screen and as there is now another test running that has 3 or so hours left i didnt want to now wait before blogging. I deliberately created the two sample users above with passwords starting at "A" and "Z" because I wanted to test whether the password choice has an effect on the time to crack. From the screen dump above it would seem that this will be the case. When mine finish I will know for sure. From the output above it seems that passwords starting later in the alphabet take more than 15 minutes and those earlier in the alphabet around 10 or less.

There should be a possible improvement that could be made to the algorithm of Dennis's cracker that requires some math and statistics calculations to be made. If passwords generally have a skew towards starting with certain characters more than others then there will be a benefit in start choice for the cracker or in randomizing the journey through the brute force choices. If passwords for instance were spread evenly across the character set for start point then having the cracker always start at A could be a good choice (you have to start somewhere) but if the spread is not even then a better start choice could be made.

The speeds shown for runs already completed are good, 62M, 69M, 85M hashes per second...

The cracker page also now shows the elapsed time taken.

Dennis has also published proof of concept code for CVE-2009-1979 which was found by him and fixed in the October 2009 CPU. The C code and a binary is available from here. This is the CVSS 10.0 bug on Windows that relates to improper AUTH_SESSKEY parameter length validation.