Pete Finnigan's Oracle Security Weblog

I don't talk much about security bugs anymore here primarily because my focus has always been at the auditor / help secure end of the spectrum rather than others who focus at the research/find security bugs/exploits/penetration test end of the spectrum. My services are focused correctly to help clients secure their database. They are non-intrusive, non-invasive... A lot of what I do is around configuration / parameters / security privileges / segregation of duties issues / privilege duplications / privilege redundancy and a lot more.

But, that said, I am always of course still interested in security bugs, exploits and outright Oracle security research so when I saw Darius Wiles post "Security Defect Testing" i read it with great interest; any public insight into the machinations of the internal security team at Oracle is interesting. Darius shows that Oracle has used most free and commercial code auditing and security tools over the years and indeed is now using commercial/free and internally developed tools at all stages of their own development process.

The interesting part of Darius's post is that he says they categorise security bugs into three groups, "internal", "external" and "customer". The internal ones are easy to understand, they are found through automented testing during development or via ethical hacking. The customer bugs are not described but i assume these are normal bugs reported via metalink, whats significant is these must be security bugs to be counted but they exceed those found by researchers by a three fold factor. The researcher found bugs are clumped with posts to the net and also bugs in third party products.

The upshot is that its difficult for us mortals to make a lot of sense of the figures; Darius does warn against interpreting the figures. The first comment that I have is that I am warmed by the fact that Oracle are now publishing figures such as this; it's a good move for us to see. Can we make some simple calculations?

The figures given are for the year, 3% for external (researchers, external products and web posts), 10% for customers and 87% for internal. If we take a very simplistic view and say that the CPU recognises all non-internal bugs (porbably not true, I know) and also just look at the Database product bugs; there were 12 in July, 16 in April and 20 in January. I chose the database product set numbers because I focus on the security of the database layer with my company.

So continuing the simplistic sums (you know where this is going) thats 12+16+20 = 48 security bugs in the database product set this year. If this represents 13% of the total then 100% would be 369 security bugs fixed in the database. I stress this is not accurate but its all I can work with. I have said in the past that Oracle credits those who find bugs on the CPU advisory but fixes other bugs silently. The guys who spend time reverse engineering the Oracle patches may be able to confirm this.

What would be really great now would be for Oracle to give us more details of the free tools and commercial tools they use but also release some of the internal tools developed so that customers can review their own application code. Its agreed that Oracles code is getting better so we now need to get customer code to the same state and letting us see what tools are used would be a good first step.