Staying on top of Oracle's holes

[InfoSec News <isn () c4i org>]

http://www.theregister.co.uk/content/53/24244.html

Staying on top of Oracle's holes
By Thomas C Greene in Washington
Posted: 02/28/2002 at 07:35 EST

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 procedute call 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. 



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn' in the BODY
of the mail.