The Oracle Hacker's Handbook

The Oracle Hacker's Handbook
Hacking and Defending Oracle
byDavid Litchfield
John Wiley & Sons 2007

It's terribly important that Oracle get security right, and so far their record has been poor. The Oracle RDBMS has had more critical security vulnerabilities than any other database server product. By critical, I mean those flaws that can be exploited by a remote attacker with no user ID and password and which gives them full control over the database server. To put these critical security vulnerabilities in context, IBM's DB2 has had 1; Informix has had 2; and Microsoft's SQL Server has had 2. Oracle has had 9. That's more than the other database servers put together. In terms of flaws that require a user ID and password but yield full control when exploited, again Oracle outstrips the rest by far. These facts stand in stark contrast to Oracle's marketing campaigns claiming that their product is "unbreakable." When Oracle executives say, "We have the security problem solved. That's what we're good at … ," it makes you wonder what they're talking about. So far the problem is not solved, and complacency should have no home in an organization that develops software that is installed in most governments' networks. This is why it is absolutely critical for Oracle to get it right-national security is at stake.

Oracle's idea of what security means is formed largely on the U.S. Department of Defense's assurance standards. This is why Oracle can state that they "get security." This may have worked 15 years ago, but the security landscape has entirely changed since then. Let me explain further. The Oracle RDBMS was evaluated under the Common Criteria to EAL4-assurance level 4-which is no mean feat. However, the first few versions of Oracle that gained EAL4 had a buffer overflow vulnerability in the authentication mechanism. By passing a long username to the server, a stack-based buffer is overflowed, overwriting program control information, and allowing an attacker to take complete control. How on earth did this get through and how was it missed? The answer is that there is a vast divide between what "standards" security means and what real security means. There is, of course, an important place for standards, but they are not the be all and end all, and Oracle would do well to learn this lesson. Standards imply rules but hackers don't play by the rules.

Perhaps Oracle is beginning to understand, though. By all accounts they have shaken up and improved their coding standards, and have invested in numerous tools to help them develop more secure code; and there is evidence to suggest that things are getting better on the security front. Oracle 10g Release 2 is a dramatic improvement over 10g Release 1. Security holes are still being discovered in 10g Release 2, but nowhere near the numbers that have been found with 10g Release 1. Oracle has also improved their security patch release mechanism. Every quarter, Oracle releases a Critical Patch Update (CPU), and up until July 2006 every CPU was reissued multiple times because of failings and missing fixes and other problems. The July 2006 CPU was different; it was released once-hopefully the start of a trend.

Considering that things are improving, where exactly is Oracle on this journey to "security" utopia-by which I mean a secure product that actually matches the marketing speak? In answering this question, for any vendor, a key pointer is to look at how they respond to security researchers. In the summer of 2006 at the Blackhat Security Briefing, I was on a panel that discussed the issues surrounding the disclosure of security flaws. The panel moderator, Paul Proctor from Gartner, insightfully suggested that "Microsoft is in the acceptance phase. Cisco is slowly moving out of the anger stage and into the acceptance stage. Oracle, on the other hand, is just coming out of the denial stage and into the anger stage."

This is an accurate assessment in my estimation. Like Microsoft a few years ago, when Scott Culp published his "Information Anarchy" paper, Oracle too had their say about security researchers when Mary-Ann Davidson, the Chief Security Officer of Oracle wrote her article "When Security Researchers Become the Problem." The difference between Mary-Ann's article and Scott's paper is that Scott's needed to be said, as it was published at a time when there was information anarchy and not much responsible disclosure going on; it was an attempt at convincing security researchers to work with the vendor. This is why Mary-Ann's article a few years later failed to hit home: The security researchers she disparaged were already working with Oracle to try to help improve their product. Oracle failed to see that they and security researchers were working toward the same goal-a more secure database server. Part of the article discusses security researchers making explicit and implicit threats, such as "Fix it in the next three weeks because I am giving a paper at Black Hat." However, Oracle should understand that a security researcher is under no obligation to inform them that they are going to present a paper; and if they do tell them, Oracle should appreciate the heads up. Such information is a courtesy. Calling this an "implicit threat" is disingenuous and risks alienating the very people best placed to help them secure their product. It would be in the best interests of all for Oracle to get over their anger stage and embrace the acceptance phase.

Enough commentary on Oracle, however, at least for the time being. Let's look at why we need a book that details vulnerabilities in their RDBMS and examines how those flaws are exploited. In short, precisely because it is such a popular database server, it is a prime target for hackers, organized crime, and those involved in espionage, be it industrial or foreign. Therefore, there should be a reliable resource for database and security administrators that shows them how their systems are attacked and where they are vulnerable. This puts them in a position of strength when designing defense strategies and mitigations.

This book is that resource. Yes-such a book is, by nature, paradoxical: intended to aid defense, it arms not only the defender with the information but also the attacker. It is my experience, however, that most attackers already know much of this information already, whereas the defenders don't but should. Yet even today, given all the evidence to the contrary, you hear Oracle "experts" claiming that Oracle is secure, citing as proof that Oracle is "always installed behind a firewall" and that it "runs on Unix." Frankly, these "reasons" have nothing to do with whether Oracle is secure or not. It's as easy to break into an Oracle server running on Linux or Solaris as it is on Windows. A firewall becomes irrelevant as soon as you poke a hole through it to allow your business logic and web applications to connect to the database server-SQL injection is a major problem.

Furthermore, it is a myth that Oracle is always installed behind a firewall. According to the "Database Exposure Survey" I performed in December 2005 and published in June 2006, an estimated 140,000 Oracle database servers are out there accessible on the Internet, compared to 210,000 Microsoft SQL Servers. Given that many of these SQL Servers will be MSDE installs, one wonders what effect Oracle Express will have on the number. Oracle Express was released after the survey. Getting back to the core of the problem, however, there is not nearly enough understanding by those in the Oracle world that their servers are exposed to risk. When you consider that Oracle has committed to releasing a Critical Patch Update every three months until at least July 2007 (at the time of writing), this means that in the interim Oracle database servers are in a critically insecure state. Food for thought, indeed. This is the "why" then. If we are to take responsibility for the security of our own systems, knowing that they are critically insecure, we need to know how they're insecure-only then can we take steps to prevent our systems from being compromised.

I hope that as well as finding this book useful and informative, you have fun reading it. I'm always willing to answer questions so please feel free to ask.

Cheers,

David Litchfield

For Download: