Database Security and Patches - Part 5

Wednesday Jan 25th 2006 by Steve Callan

How do you validate and verify the fixes made in Oracle's critical patch updates? Sometimes you need to test on your own, but the test results may not be accurate because Oracle does not release all of the details about a bug or security flaw. What are the types of security holes present in Oracle, and where can you learn more about testing your own system?

Between Oracle's critical patch updates and security alerts, perhaps a better phrasing of "Unbreakable" would be "Unbreakable (when patched)." Other articles exist which qualify and clarify what "unbreakable" actually means, and defining "unbreakable" is not the point of this particular article. What is of interest here is the latest critical patch update (released 17 Jan 2006) and how it relates to defending database servers.

Patching and Updates in General

Oracle defines a critical patch update as "a collection of patches for multiple security vulnerabilities." An update "also includes non-security fixes that are required (because of interdependencies) by those security patches." The first is easy to understand: an update fixes vulnerabilities, but the second part is analogous to the devil you know versus the devil you don't. In other words, known problems are addressed in the first part, but fixing those problems introduces the potential for more problems because of interdependencies.

With this definition in mind and using software testing as a frame of reference, the concept of "don't cause other problems when fixing what's already broken" certainly applies here. More formally, the concept is known as regression testing. Regression testing is "Part of the test phase of software development where, as new modules are integrated into the system and the added functionality is tested, previously tested functionality is re-tested to assure that no new module has corrupted the system." (

How does this apply to Oracle (or any software vendor)? One would hope and expect that what was fixed related to the SQL injection vulnerability addressed in Security Alert 68 (the March 2005 Oracle Security Update) has not been re-introduced into later versions of the RDBMS software. So, the question is this: how do you know a problem has not been re-introduced? Rely on testing from Oracle or perform your own testing? One way to be sure is to conduct your own testing, but be aware that you may not have all of the information you need to fully evaluate a fix. One reason for not knowing everything is that Oracle does not necessarily publish all of the details behind an issue.

In fact, Oracle's policy regarding what or what is not published is posted at OTN.

Oracle will not provide additional information about the specifics of vulnerabilities beyond what is provided in the Critical Patch Update (or Security Alert) advisory, the pre-installation notes, the readme files, and FAQs. Oracle provides all customers with the same information in order to protect all customers equally. Oracle does not provide advance notification to individual customers. Finally, Oracle does not develop or distribute active exploit code (or proof of concept code) for vulnerabilities in our products.

Think you found a bug and want credit for reporting it? You will get credit provided you:

  • Do not publish the vulnerability prior to our releasing a fix for it
  • Do not divulge exact details of the issue, for example, through exploits or proof-of-concept code

For this particular CPU (critical patch update), one of the persons responsible for notifying Oracle of a vulnerability is David Litchfield, and it is Mr. Litchfield's work that leads us to the next part of this article.

Defending Database Servers

Mr. Litchfield is the lead author of The Database Hacker's Handbook: Defending Database Servers (Wiley Publishing, Inc., 2005). As a DBA (Oracle or otherwise), what is your role in defending your database server? Is your role passive or active? Being passive is asking for trouble, even if you trust all of your users. Being active is better for many obvious reasons, and also for some not so obvious reasons. Some users, although not intending to be malicious, attempting to try something out of curiosity, may inadvertently hack your database (see: The Law of Unintended Consequences).

Based on the authors' experience, the handbook categorizes classes of database security flaws. They include:

  • Unauthenticated Flaws in Network Protocols
  • Authenticated Flaws in Network Protocols
  • Flaws in Authentication Protocols
  • Unauthenticated Access to Functionality
  • Arbitrary Code Execution in Intrinsic SQL Elements
  • Arbitrary Code Execution in Securable SQL Elements
  • Privilege Elevation via SQL Injection
  • Local Privilege Elevation Issues

Privilege elevation via SQL injection is a "wildcard" category in that you (as a DBA) have no control over what a user attempts to pass in to a procedure. The injection attack (mentioned in Alert 68) is one such example (yes, it is still fixed as of 10g):

SQL> exec ctxsys.driload.validate_stmt('grant dba to public');

But how many other possibilities – as yet undiscovered – exist? Here is a situation, which is fairly common, that you should discuss with your UNIX (or Windows) administrator: users having accounts on the database server. What's the big deal about letting users have accounts on the server?

Extproc in Oracle 9i and 10g does not require authentication to load a library or execute a function, which allows local users to execute arbitrary commands as the Oracle user.

I would venture to say that many DBAs are not aware of this problem, especially production-type DBAs who do not deal with external procedures. See, (says it was superseded by Alert 57), and Alert 57, Buffer Overflows in EXTPROC of Oracle Database Server. This vulnerability was reported by Next Generation Security Software (NGSS reported 18 of the 88 bugs in the October 2005 CPU). David Litchfield also happens to be a co-founder and managing director of NGSS.

One of the handbook's key points is that "the best way to secure a system is to understand how to attack it." Aside from the "normal" steps you can take to enhance or provide security for your servers, having an understanding of the how's, where's and why's of (potential) weaknesses enables you to provide better security. The two best parts of the book, as it relates to Oracle, are the range of examples of how a database can be attacked and the preventative steps you can take.

In addition to Oracle, the handbook covers IBM DB2 Universal Database, Informix, Sybase, MySQL, SQL Server and PostgreSQL. If security of your RDBMS is a concern (and of course it should be), the information about these other systems will be of immediate use to you in formulating an acquisition strategy (think "Portal" with Oracle as the backend database and heterogeneous services – what other systems have security comparable to Oracle?).

In Closing

Some may question the ethics of learning techniques on how to attack a database system, but that opposition is misguided. Many organizations implement the principle of least privileges. If your intent is to follow that principle, and you take the necessary steps and measures in your database (and on your server) to implement the principle, one could argue that the next step would be to look for ways where the principle can be violated. In other words, wouldn't you prefer to find the holes and weaknesses of your system before an outsider does? How can you say "we are secure" if you do not even know what to look for in the first place beyond what the vendor's documentation provides? As we all know, documentation is not perfect and vendors do not always advertise their vulnerabilities.

Oracle Corporation by far is not perfect, but neither is any other relevant RDBMS vendor. Independent researchers such as those at NGSS provide a great service to the database management community, and having an understanding of the vulnerability categories helps you, the DBA, become better at safeguarding your data.

» See All Articles by Columnist Steve Callan

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved