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
This archive was generated by hypermail 2.1.3 : Mon Aug 22 2005 - 01:24:05 PDT