Staying on top of Oracle's holes

In light of the fortnight-old SNMP pandemic, it's tempting to forget that the world's most popular database kit remains vulnerable to a host of potential exploits which were published about three weeks ago by NGSSoftware Insight researcher David Litchfield.

Because SNMP holes can affect virtually any networked device, admins struggling to secure their systems may well have been distracted from the quite serious vulnerabilities Litchfield discovered.

And on top of the SNMP distraction, we note that Oracle has been less than eager to disseminate useful information about these issues, most likely because they illustrate the essential fatuity of its 'unbreakable' ad campaign.

With this in mind, Counterpane Internet Security held a teleconference for its clients Wednesday to remind them of lingering obstacles to running Larry Ellison's unbreakable product with a modicum of security.

Unresolved

According to Counterpane, the worst unresolved issue is the fact that the Oracle server will respond to external procedure calls, say from a custom application, with access to OS-level libraries and functions. Users are supposed to be authenticated with the proper level of access before executing code, but unfortunately aren't. There is in fact no user authentication at this level, Litchfield discovered.

Anyone can run an application at the OS level on a Windows installation. On Solaris, this depends on the user's account privileges, though it's safe to assume that too many users have more privileges than they need on most systems out there.

"If you're running Oracle on a Windows system, the default installation is that Oracle runs in the system [root] environment, and that means that basically anyone who has access to the network functionality has the ability to run local applications and functions as an administrator," Counterpane's Tina Bird warned.

Worse, "the procedure calls look exactly the same as all the other authorized procedure calls in your database system," she added. "People exploiting those vulnerabilities are going to look just like the rest of the authorized traffic."

We'll note that a vulnerability in the PL/SQL DADs (Database Access Descriptors) can enable an attacker to escalate his privileges regardless of his initial status, so this is not an issue to be trifled with. Unfortunately Oracle has not yet released a patch. According to Bird, developing one will require considerable re-jiggering of the code which handles this interaction, so no one should hold his breath waiting for one.

For a bit of good news, Oracle has issued patches for buffer overflow vulnerabilities on Solaris and Winodws, but these need to be approached with caution. Data intergrity is of course crucial to all admins, but to database administrators it's a sacred mission. Thus it's necessary to test any Oracle patch thoroughly and meticulously before integrating it into a 'live' system. You may have custom apps or customized architecture, and you know how patches can be in these situations. Remember, a workaround may be nearly as effective, and a good deal safer, than a patch on some systems. Don't find out the hard way that your kit is 'a bit out of spec'.

Workarounds

Oracle recommends disabling db functionality which enables external processes. If that's impossible, then according to Counterpane, you can configure the Oracle listener to prevent all but a select few IP addresses from connecting. Additionally, you might block port tcp/1521 if you can get away with it.

To harden Oracle-9iAS against PL/SQL authentication bypassing it's possible to add the rule:
exclusion_list= account*, sys.*, dbms_*, owa*
to the file:
$ORACLE_HOME$\Apache\modplsql\cfg\wdbsvr.app

To work around the PL/SQL DAD vulnerability, change the AdminPath entry in:
$ORACLE_HOME$\Apache\modplsql\cfg\wdbsvr.app
to a path name that conceals the location of the admin pages.

A problem with OracleJSP which leaves potentially sensitive temporaty files and page source readable by the public is described in detail, along with its workarounds, here. This involves modifications to Apache, and is not difficult. It's also very unlikely to break anything else.

You may also be able to set up a less-privileged or non-privileged environment for your Oracle server to run in. Do it if you can.

The most readable and detailed document on workarounds doesn't come from Oracle, sadly, but is instead Litchfield's paper (linked below). No one administering an Oracle database can afford to ignore it. ®

Related Story

How to hack unbreakable Oracle servers

Related Links

Litchfield's paper
Oracle's recommendations
Counterpane's synopsis