The article starts with a quote from a conversation between Alex and Lisa:
"Within 42 hours I was able to find 42 bugs with security potential (e.g., denial of service, SQL Injection, �)," RDS' Alexander Kornbrust said from Germany via an e-mail conversation. "I stopped after 42 bugs."
Alex goes on to say that ten bugs are not fixed in the latest patch set - CPU April 2005. Oracle had not made a formal comment to Lisa on the reporting of the 42 bugs by Red Database Security but they did point out some inaccuracies in Alex's report. I do not believe that these inaccuracies take anything away from the seriousness of the issue though.
The technique Alex has used has been coined as Metalink hacking. This is a technique made famous by Johnny Long with his Google hacking exploits.
I have known about this research by Alex for some weeks as we have had conversations about it when Alex started to look at it. I have seen an early version of Alex's paper on the same subject and made comments so I was not surprised to hear from Lisa Vaas last week to ask for comments on this paper and Alex finding 42 previously unpublished Oracle security bugs. The fact that Alex was able to find 42 security bugs in a product support database is probably not surprising but it should not be. The technique of Google hacking has been known for a long time now as has the issues of information leakage. Oracle should be embarrassed by this revelation by Alex, to their credit they have responded quickly and blocked access to the data found by Alex. Alex let me know by email on Friday that all of the data he found has now been blocked. The problem for Oracle now is that they will need to search the whole of the Metalink database and close off any other bugs waiting to be found - or at least not make them public. Databases like Matalink are a great resource for customers but they also need to be appropriately policed for any potential information leakages on security issues.
The article on its first page gives a good example of the sort of leakage found by Alex. A customer had posted details of a bug where she was able to get logged in as SYS by running a scheduler job on 10g. The user had used an escalation of privileges exploit and given out the full source code for it, she almost certainly did not realise the seriousness of what she was reporting though. BUT someone in Oracle should not have allowed this to occur.
The first page of the article goes on to explain the search strings Alex used and also has some comments from Aaron Newman of Application Security Inc. The second page of the article goes on to talk about the most serious issue in Alex's discoveries. This is an explanation of the fact that the listener is not password protected by default before 10g. The issue Alex found is a conversation between an Oracle employee and a customer where the employee says words to the affect of "no one likes to password protect the listener, I am the first person to help customers turn off password protection", as Alex says this is a funny comment for an Oracle employee to make. The employee emphasises that listener security and password protection is very important but says that she was one of the first people to "help" customers turn it off in the past. As Aaron says "If Oracle employees are out there turning security off, it's a little bit scary.". The article then goes on to quote me! and finishes with some comments on how Metalink can be made more secure.
Of course this same issue of Metalink hacking is also a potential issue for other large companies that use similar databases. Microsoft springs to mind but this issue does not just have to apply to software vendors.