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." (http://foldoc.org/?regression+testing)
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.
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
Unauthenticated Flaws in Network
Authenticated Flaws in Network
- Flaws in Authentication Protocols
Unauthenticated Access to
Arbitrary Code Execution in
Intrinsic SQL Elements
Arbitrary Code Execution in
Securable SQL Elements
Privilege Elevation via SQL
- 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
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?
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 http://www.seifried.org/security/index.php/CVE-2002-0567,
(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?).
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.