[ISN] Staying on top of Oracle's holes

From: InfoSec News (isnat_private)
Date: Fri Mar 01 2002 - 02:01:09 PST

  • Next message: InfoSec News: "[ISN] Microsoft Security Push Faces Skepticism"

    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
    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'.
    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 majordomoat_private with 'unsubscribe isn' in the BODY
    of the mail.

    This archive was generated by hypermail 2b30 : Fri Mar 01 2002 - 05:26:17 PST