Remember Oracle’s ludicrous ads about their ‘unbreakable’ database product? Bruce Schneier was predictably unimpressed:
‘Last November, Oracle started touting its security with an “Unbreakable” ad campaign and the slogan: “Oracle9i. Unbreakable. Can’t break it. Can’t break in.” This was a ludicrous claim then, but I decided to wait until it was actually broken before writing about it.
Well, it’s been broken. In several places. Using some pretty basic attacks. Unbreakable, it’s not.
On the one hand, I (and most people reading this newsletter) always knew that. We knew that the claims were exaggerated. We knew that the Oracle marketing department was lying. But it’s a sad commentary on the state of security discourse that Oracle wasn’t immediately laughed out of the room. Oracle9i won’t ever be unbreakable, unless the company makes some major changes in the way they design and develop software.
On the other hand, maybe it’s not just hubris. Maybe Oracle management actually believed that their product was unbreakable. Maybe they’re that clueless about security. If that’s the case, the problems run deeper than they look. The problem with believing your product is unbreakable is that you don’t bother to secure it in depth. If you think your walls are impenetrable, you’re not going to bother with guards and alarms and anything else. This is the case with Oracle9i. The attacks completely take over the database. Once the attacker has broken the “unbreakable” security, there’s nothing else to stop him.
In their backpedaling, Oracle has said that “unbreakable” didn’t mean what normal people take the word to mean. Oracle’s security chief, Mary Ann Davidson, claims that the campaign “speaks to” fourteen independent security evaluations that Oracle’s database server passed. This, to me, is the real story here. What good is a security evaluation, what good are FOURTEEN different security evaluations, if none of them can catch something as trivial as a buffer overflow? Security is hard. Think of a chain; any single weak link can break the chain. Buffer overflows are an obvious link: easy to avoid, easy to test for, easy to fix. Catching all buffer overflows doesn’t make your software secure; it’s the price of admission. The hard stuff is really hard.
So, I tried to find the fourteen independent security evaluations. I wanted to make fun of them: “Look at the fourteen security evaluations that don’t even guarantee buffer-overflow-free code.” Unfortunately, I could only find five: TCSEC, ITSEC, Common Criteria, Russian Criteria, and FIPS 140-1. Oracle marketing turned five into fourteen by counting multiple levels of TCSEC and ITSEC as independent security evaluations, and counting identical evaluations of different Oracle products as independent security evaluations. I don’t know about you, but when I hear “fourteen different,” I don’t think it means “five different, some of them multiple times with different products or different levels.” Seems like Oracle has trouble with math as well as with English.
“Unbreakable” has a meaning. It means that it can’t be broken. It doesn’t mean “Unbreakable, except by people who know how to break things.” It doesn’t mean “Passes five or so questionable security evaluations, but is still vulnerable to buffer overflows.” I don’t care who Larry Ellison is; he can’t rewrite the dictionary.’