eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
After releasing a patch earlier this month for a faulty April Cumulative Patch Update, Oracle Corp. now says its patched patch also needs to be fixed. In addition, its July patch set is flawed, according to an e-mail that its Global Product Support division sent out last week.
Oracle had initially attempted to fix the faulty April patch set after David Litchfield, managing director at U.K.-based Next Generation Security Software Ltd., brought the faulty patch to the companys attention. As it turned out, the underlying vulnerability had never been fixed.
The April Critical Patch Update addressed 70 security flaws in Oracle database and application server products, but during routine testing, Litchfield discovered that the patch was sending scripts to the wrong directory and that the source of the actual flaw was not addressed.
In early July, Oracle customers received an e-mail that said a step was missing in the installation script of the April CPU that caused a jar file not to be uploaded to the database. Oracle, it turns out, misstated one of the affected products: Database 9.2.0.6 was unaffected, and no fix is required.
But Oracle for a second time didnt get it right. The fix for the faulty patch set didnt work, according to an e-mail sent to customers from Oracle Global Product Support on Thursday night. “It was discovered that the steps provided earlier did not rectify the problem completely,” the company said in the e-mail.
Those who have applied the July CPU should be all set—with regard to the faulty April patch set, that is.
But the July patch itself, according to Oracle, is flawed. Oracle Global Product Support last week sent out an e-mail telling customers that those who have already applied the Critical Patch Update for July must now re-download it for Oracle Database 10.1.0.3 and 10.1.0.4.
The reason for the second download is that Oracle discovered a flaw that would cause a manually created database to be shown in a pending state when it is discovered by Oracle Enterprise Manager. The flaw affects all platforms, but it is only relevant for those customers who use EM to monitor Oracle installations.
Alexander Kornbrust, founder and CEO of Red-Database-Security GmbH, a company that specializes in Oracle security audits, said that Oracles patching process is clearly “a complete mess.”
“This is an indication that the quality of the patches is not so good,” he said. Kornbrust this week went public with details of six unpatched vulnerabilities, some critical, in Oracle products after waiting more than 700 days for Oracle to address the issues.
Oracle reportedly has also failed to mention the patch flaws on the Oracle Technology Network. Kornbrust said that this approach to communicating vulnerabilities and patch reissues is in itself problematic, given that Oracles e-mail could inadvertently get waylaid by spam filters. Also, without mention on OTN, customers have no way of verifying that e-mail is from Oracle and is not spam, he said.
“If the e-mail is accidentally deleted, then this information is never on the [OTN],” he said. “And theres no chance to verify if this e-mail is correct.”
Oracle did not respond to requests for comment. But Kornbrust said that he and Pete Finnigan, founder of PeteFinnigan.com Ltd., a British company that specializes in Oracle and security, dont view the e-mails as phishing attempts, since its not necessary to enter e-mail addresses or to hand over other identifying information.
Oracle is notoriously tight-lipped about its security patches. In this case, it may be niggardly in distributing the information because few customers are affected, Kornbrust suggested, given that the July CPU has only been out for a short while, and few people would have downloaded it already.
“Most DBAs [database administrators] I know are very busy, and they wait,” he said. “They know from experience that its better to wait a few days before applying these patches and downloading these patches. Its typical for Oracle to change patches afterwards.”
While it might seem risky to leave a database server unpatched when there are known critical flaws in circulation, most Oracle servers are tucked into intranets as opposed to being exposed on the Internet, where theyre most vulnerable, Kornbrust said.
Check out eWEEK.coms for the latest database news, reviews and analysis.