In June of 1997, Larry Ellison and Robert Miner founded a company called Software Development Labs. Both had worked together at Ampex; Robert had been Larry's supervisor. Together they had a vision, inspired by the work of Edgar Codd. Codd worked as a researcher for IBM and developed ideas for relational database systems. In 1970 he published a paper entitled "Relational Model of Data for Large Shared Data Banks." While IBM was slow to see the potential of Codd's ideas, Larry and Robert were not. They changed their company's name to Relational Software, Inc., in 1979, and not long after that it again underwent a name change—becoming Oracle. "Oracle" had been the code name for a CIA project that both Larry and Robert had worked on while at Ampex. Indeed, by all accounts, in the early years, the biggest consumers of Oracle's software was the CIA and the NSA. Given this, one would assume that security would have been at the top of Oracle's agenda.
In 1999 Oracle started to gain the attention of the security research community. The first public record of a security bug in Oracle, according to SecurityFocus.com, was on April 29 of that year: Dan Sugalski posted that the oratclsh program was setuid root and executable by the *nix group, "others". This meant that anyone could run TCL scripts as the root user. Not long after this a number of flaws were revealed relating to the Oracle Web Listener, posted by the author and Georgi Guninski, as well as additional problems relating to default permissions. Oracle started releasing their own advisories in the year 2000, but these were released on an ad-hoc basis and often months after a flaw was announced publicly.
The graph shown in Figure 1 shows the number of bugs reported in the "early" years. As you can see, the number of bugs grew exponentially, and indeed this is the only reason why 2003 and beyond are not shown on this graph—the numbers went through the roof, so to speak. Most of these bugs relate to buffer overflows in the RDBMS or the Application Server. One of the key weaknesses in Oracle, PL/SQL injection, didn't come to light until 2003, when on the fifth of November Oracle released Alert 61—an advisory that dealt with a number of injection flaws discovered by the author. This began a spate in the discovery of PL/SQL injection flaws, and even today most of the issues being fixed by Oracle are injection problems. As you'll see later in the book, flaws in PL/SQL are the Achilles' heel for the RDBMS, and when exploited allow an attacker to gain full control of the database server.
The "Unbreakable" Marketing Campaign
With the release of Oracle 9i, Oracle began a new marketing campaign in December 2001. They announced that their product was "unbreakable" and that no one could "break it" or "break in." To many in the security industry this was one of those Kennedy moments: Everyone can remember what they were doing when they first heard what Oracle announced. I certainly remember what I, and no doubt many others, did after—which was to download this "unbreakable" software and see just how tough it actually was. Within days of the announcement, my brother Mark and I had sent Oracle a bunch of reports detailing a great number of ways in which the server could be both broken and broken in to. After Oracle fixed these flaws I presented a paper on the issues at the Blackhat Security Briefings in the February of 2002. Oracle was thoroughly broken.
Today, Oracle will tell you that the campaign spoke of their commitment to security, and was not to be taken as a statement about their product's security. Hmmm.
Independent Security Assessments
So what are we to make of Oracle's commitment to security? What do they mean by that? Well, Oracle has invested a great deal of money in having their products independently assessed. These are foisted upon the consumer public as proof positive that Oracle is secure. In "real" security world terms, however, being evaluated to EAL4 (Assurance Level 4) under the Common Criteria means nothing. How could it? Both Oracle and IBM's Informix (EAL2) were accredited under the Common Criteria yet both had a buffer overflow vulnerability due to a long username. All the right features are in the product to be able to get accredited but they're all holey. A castle is no castle if its door is made of cheese.
The first version of Oracle to gain EAL4 was 7.2 in September 1998. Next came Oracle 8.0.5 in October 2000, and then 22.214.171.124 in July 2001. In September 2003, Oracle 9iR2 was certified, followed by 10g Release 1 in September 2005. Since attaining certification, all of these versions have been weighed and found wanting—badly.
If you haven't guessed by now, I'm not a big fan of independent security evaluations but I suppose they do have their place and they give developers something to aim toward. This only holds true, though, if the development of the software is not a whitewash or mere window dressing.
The Future of Oracle Database security
Oracle 10g Release 2 is a good product. It's a vast improvement over 10g Release 1 when it comes to security. Oracle should be commended for that. However, it's not "mission accomplished" yet. There are still bugs in 10g Release 2—many of which are discussed in this book - and there are more to be found. Still, whereas it took only 5 to 10 minutes of searching to find a new bug on 10g Release 1, it takes a good day's effort or more to find one on 10g Release 2. The improvements are largely due to a heavy investment in source code auditing tools. While these tools do a great job of catching most flaws, they have a problem with boundaries—for example, when a PL/SQL procedure calls out to a C function or a Java function. The tools seem unable to pick up flaws that occur in these crossover points. Oracle needs to make improvements to these tools in order to catch these last remaining issues, too. Source code auditing tools should be used as a "last defense" mechanism. The real key to making great strides when it comes to improving security is in the way developers code. Good secure coding standards and procedures are a must. Much like the way Microsoft has published the standards and procedures relating to its Security Development Lifecycle, I'd invite Oracle to do the same. It can only be good for the industry as a whole.