http://www.eweek.com/article2/0,1895,1850287,00.asp
By Lisa Vaas
August 19, 2005
Think you're patched? Think you'll get the thumb's-up from the auditor
when she comes knocking on your door to make sure you're in compliance
with HIPAA (Health Insurance Portability and Accountability Act), or
GLBA, or Visa CISP and MasterCard PCI?
According to an upcoming paper from Next Generation Security Software
Ltd., a majority of users of Oracle Corp. database servers are in fact
mistaken in their perception of their patch levels and are actually
not compliant with such regulations.
David Litchfield, managing director of NGSS, said that out of a total
of more than 100 recently surveyed database servers, a staggering 76
percent have anomalies between expected and actual patch levels.
Surveyed database instances included a range of industries and company
sizes. Size and industry are irrelevant with regards to the potential
for database exposure, however, since Oracle software itself is
causing the exposure, not what customers are doing with their
databases, Litchfield said.
"The fact is that Opatch is failing, or [an Oracle] patch failed to
fix certain issues appropriately," he said. "Customers aren't doing
anything wrong. It's the tools themselves that are faulty."
The problems are manifold, according to NGSS. At times, Oracle's CPUs
(Critical Patch Updates) fail to install updated, fixed copies of
files. Both the April and July 2005 CPUs, for example, failed in
multiple areas.
In the April CPU, on all platforms, new Java classes supplied to fix
SQL injection vulnerabilities in DBMS_SUBSCRIBE and DBMS_ISUBSCRIBE
were not actually loaded, according to NGSS. In addition, on Windows
platforms, a SQL script file with a fixed version of the CTXSYS-owned
DRILOAD package was copied to the wrong directory and thus was never
executed.
Many other problems relate to Oracle's opatch utility. Opatch is a
utility through which patches are applied to Oracle database servers.
Information on patches and fixed bugs are stored in Oracle Inventory,
a flat XML file. Opatch is used to query the inventory to determine
whether a server is patched.
After running Opatch, users are typically given the message "Opatch
succeeded." However, necessary post-installation tasks include
updating components such as PL/SQL packages and Java Class files in
the database. If these post-installation steps aren't taken, the
server remains vulnerable in spite of the Opatch utility having
indicated that the server is in fact patched.
In addition, according to NGSS, Opatch often fails for various
reasons. "Permissions are wrong; files that are to be patched are
still in use; environment variables are wrong; whatever the reason
might be, and a quick search on Google reveals many more, Opatch can
often fail to update the inventory," according to a preliminary draft
of the search firm's paper, titled "Patch Verification of Oracle
Database Servers."
"If information in the inventory is wrong, then so too are any
observations made about patch status and levels," the paper said.
Does any of this matter? Oracle users tend to consider themselves
generally safe from risk, given that their databases are typically
locked down behind firewalls instead of being exposed to the Internet
- as is often the case with installations of Microsoft Corp.'s SQL
Server database.
Carl Olofson, an analyst with IDC, said it's hard to get concerned,
given that he's not hearing stories of SQL code injection or other
types of security exploits. "If we were getting stories about people
whose systems were brought to their knees or getting security
breaches, if this were coming up in multiple places, that would be an
area for concern," he said.
But, according to Litchfield, there are ample numbers of unprotected
Oracle database servers, particularly when it comes to universities,
which often expose their servers to the Internet. In addition,
back-end Oracle database servers are vulnerable to SQL injection via
Web applications.
"There is exposure, regardless of what Oracle would have you believe,"
he said. "Some people are running Web applications that are exposed to
the Web, and we [have demonstrated that] we can gain control of the
back end through SQL injection."
Oracle, maker of what it has marketed as the "unbreakable" database,
seldom addresses criticisms about its security. The move to quarterly
patch releases a la Microsoft came only after a protracted silence on
34 vulnerabilities for which it reportedly had fixes in 2004.
Recently, however, Oracle Chief Security Officer Mary Ann Davidson
broke the silence by writing an article in which she said that
self-interested security researchers who publish flaws before patches
are available endanger the industry with their thirst for fame.
In that article, Davidson said that getting fixes into customers'
hands takes far longer than security researchers imagine.
"Remediation may require the vendor to analyze whether the bug is
specific to a particular version/platform or all versions/all
platforms or analyze whether related code has a similar problem [to
fix the problem everywhere]," Davidson said.
"Vendors may also need to provide fixes on multiple versions/platforms
or bundle multiple security fixes together to minimize patching costs
to customers, not to mention peforming various testing on the products
shipped to ensure the fix does not break anything else," she said.
Litchfield dismisses this criticism by pointing to patches issued by
Oracle that in fact don't fix what they were intended to fix.
"You'd expect, if they take so long to write these patches, the
patches would be robust," he said. "I'm absolutely appalled. Why do
they take so long and still fail to patch? I'm gobsmacked. ? There are
still SQL injection issues in the things Oracle supposedly fixed. If
it took two years to fix these things, they should really have fixed
these things. And they're not [fixing them].
"They built the Empire State Building in 14 months," he said. "If we
can do that, surely Oracle can get out patches that work."
_________________________________________
Attend ToorCon
Sept 16-18th, 2005
Convention Center
San Diego, California
www.toorcon.org
