Admins grapple with latest Oracle patch puzzle

By Bill Brenner, News Writer
24 Oct 2005 | SearchSecurity.com

Following Oracle Corp.'s release of several dozen software patches, security experts quickly began warning of holes left unfixed and the emergence of at least one exploit. But Nirnay Patil wasn't losing any sleep over it.

Sure, the latest patches cover "a lengthy laundry list" of security holes, said Patil, database administrator for Boston-based wireless communications provider American Tower Corp. But while users almost always complain of too few details and malfunctioning patches after an Oracle security update, Patil said his job is much easier since the Redwood Shores, Calif.-based database giant instituted a quarterly patching process last November.

"There's a lot of effort to pick through the advisory and see exactly what I need. You have to review the document very carefully," Patil said. "But at least with a quarterly process, you know when the next release is coming and you can schedule the deployment work well ahead of time. You can work out the manpower issues and all that. And when the patches come out, there's time to test things more carefully."

When Oracle Chief Security Officer Mary Ann Davidson announced the quarterly system last year, she said database administrators overwhelmingly asked for a schedule they could plan around, but not something as frequent as the monthly process the company originally conceived last year. To Patil, it was a relief.

"You're dealing with systems that are so interconnected," he said, "you don't want to go in there too often. It's much better to have a spread out process you can plan for."

But security experts say administrators shouldn't wait long to deploy these latest patches because they cover extensive security holes that could easily be attacked. They also warn that some known flaws went unfixed this time around and that at least one piece of exploit code is circulating.

Gaping glitches, words of advice

Caleb Sima, CTO of Atlanta-based Web application security firm SPI Dynamics Inc., said his company discovered one of the flaws, in Oracle Application Server 10g (10.1.2). "What we found was a buffer overflow in the server's management console," he said. "You could connect to the console and send a buffer overflow to an application, which could then allow you to take over the system."

If the data input string is longer than 2,000 characters, he said, the application server "can't handle it and spits up, allowing someone to take over the machine." Sima added that no authentication is required.

His advice to administrators: don't make management consoles open and available on the Internet. "Make it internally available only," Sima suggested. "Those who have their management consoles available online are really increasing their risk of attack."

Another application security firm, Chicago-based Integrigy Corp., issued a similar warning regarding the Oracle E-Business Suite.

"Customers with Internet-facing implementations of the Oracle E-Business Suite are at most risk and should consider applying these patches quickly," it said in an advisory. "The Oracle E-Business Suite patches involved with this Critical Patch Update (CPU) are much more complex as compared to the previous CPUs, and will require additional functional testing in our opinion. In addition, the [patches] are not cumulative. Therefore, all the patches specified in this CPU and previous CPUs must be applied."

A new exploit and unfixed bugs

Amid the plethora of patches, experts warn that exploit code is in the wild. Pete Finnigan, an Oracle expert and author of Oracle Security Step By Step, warned in his blog Thursday:

"Someone has published an exploit for one of the bugs fixed in the… Oct 18 2005 security patch… It is not good that exploits are now in the public domain as anyone who has not patched is now vulnerable. All customers of Oracle should patch promptly."

Meanwhile, David Litchfield, managing director at U.K.-based Next Generation Security Software Ltd., said in a message posted to the BugTraq forum that he gave the latest CPU a "cursory examination" and found that it doesn't fix some of the vulnerabilities Oracle had told him would be fixed.

"Once again the patch is not sufficient," said Litchfield, who has offered similar criticisms of past Oracle patches. He said he would "conduct a full investigation of the patch over the coming few days and post some recommendations once complete."

Can speed kill?

While Oracle and others have recommended that users apply patches quickly, for a customer company with a large and complex network, is it reasonable to expect database managers to move quickly, or to even deploy the entire patch load?

"There are two philosophies about applying patches," Don Burleson, Oracle expert and CEO of Kittrell, N.C.-based BC Remote DBA, said in an e-mail exchange. "One school says that all patches should be applied because it may prevent a future problem. The other school is more conservative and adopts the philosophy of 'If it's not broken, don't fix it.'"

He said each Oracle shop must assess its individual risk. For instance, patch urgency is greatly diminished for databases that are detached from the Internet or where internal security is not a concern. Speedy deployments can also be risky because a patch could introduce new problems, Burleson said. "All Oracle shops that apply any patch sets should conduct thorough testing… to ensure against any unintended side effects."

Your patching time may vary

At American Tower, which runs Oracle's E-Business Suite, Patil said the Oracle patch process can take a couple days or a couple weeks to complete, depending on how big the patch load is. As far as he's concerned, careful testing is paramount, even if it slows down the deployments.

"We go through the [patch detail] document very, very carefully and figure out which pieces we use," he said. "We check those pieces, get the patch numbers and download those that apply to our platform, which is HP Unix."

The next, and perhaps most important step is careful testing, Patil said. "In a production environment, even if the patch is only breaking something small, you have to be careful and make adjustments," he said.

A patch is tested at the technical level, then the business level, then at the management level, he said, adding, "Then I put my stamp on it." How has this quarter's cycle gone so far? When asked Thursday, Patil said, "We should at least have everything set at the tech level by tomorrow [last Friday]."