Re: cpujan2006 client issues

Theoretically, this *could* be a risk worth considering. I don't have enough details about DBC02 to really say one way or another.

I *assume* that this threat requires you to be able to invoke some particular client application (I have no idea which one) with arbitrary parameters, or to pass it arbitrary text to process.

If your webservices allow either of these things, you *likely* already have a much more serious security problem anyway. (At the very least, something akin to SQL-injection and/or CGI-based attacks are likely to be available.)

For myself, I don't (personally) operate web servers, and lately I have taken to *removing* the Oracle HTTP server and iSQLplus from all of my database servers. (Just too darned many security bugs, and nobody here needs them anyway.) As a result, I don't think about such issues (much) in the context of webservers.

Yes, I think you should *definitely* apply the CPU updates to your Web/Application servers.

Here, the pain (updating maybe a dozen servers) is almost certainly outweighed by the risk you avoid.

Of course, that's just *my* opinion. Others may vary.

• Original Message ----- From: Hemant K Chitale <hkchital_at_singnet.com.sg> Date: Thursday, February 2, 2006 5:52 am Subject: Re: cpujan2006 client issues

>
> I look at it differently.
>
> Say I have one or two large clustered database servers hosting 8 to
> 10
> databases.
> I also have say 25 to 30 application servers (WebMethods, Portals, etc
> various applications). [some or dual-installations for "HA" with
> Load
> Balancers etc]
>
> Sometime in the past I had done those 25 to 30 Oracle Client
> installs [Custom Installs so as to not include OEM etc but only
> client libraries, sqlplus , exp/imp if needed, proc*c etc]. Then,
> [ie 2 years ago or 6 months ago], I had patched those clients
> to 8.1.7.4 or 9.2.0.5 plus Vul#68 or the Jan05 CPU or whatever.
>
> Those application servers do not have Oracle Databases and only
> do SQLNet (OCI) or JDBC connections. So I do not bother about
> them anymore. It so happens that those clients run applications
> on Port 80 or whatever. The 10 or 30 different Application
> Administrators
> [not me !]
> have root or superuser privileges --- "hey these are not the
> database server"
> on some of these machines.
>
> Is DBC02 now open ? Is it a risk now ?
>
> ""One vulnerability (DBC02) is in a utility that can
> be forced to terminate if given long arguments, potentially allowing
> code of an attacker's choice to be executed. However, this utility is
> not installed with setuid (elevated) privileges, so the risk that it
> can be effectively exploited is very low.""
>
> YES it is .
>
>
> Hemant K Chitale
>
>
>
> At 09:27 AM Thursday, Mark Brinsmead wrote:
> >Please see comments inline below:
> >
> >
> >Ray Stell wrote:
> >
> >>1. 343382.1 says, "One vulnerability (DBC02) is in a utility
> that can
> >>be forced to terminate if given long arguments, potentially allowing
> >>code of an attacker's choice to be executed. However, this
> utility is
> >>not installed with setuid (elevated) privileges, so the risk that it
> >>can be effectively exploited is very low."
> >>
> >
> >This sounds like a pretty fair assessment. So long as the program
> does
> >not run with
> >setuid privileges, the risk is only modest. In order to exploit
> the bug,
> >one would have
> >to "trick" a user (or program) with "elevated" privileges to
> invoke the
> >affected executable
> >on their behalf, supplying very carefully crafted arguments.
> >
> >Is this a risk? Sure. But not a big one. If I can fool somebody
> with
> >"root" or "oracle"
> >privileges to run /bin/sh (or vi, or emacs, or find, or ...) with
> >arbitrary parameters that
> >I supply, I will pretty much "own" that system. Given that there
> are
> >hundreds (or
> >thousands) of programs whose "normal" (and bug-free) operation
> provides
> >this kind
> >of "exposure", I don't think I'll lose much sleep over some "bug"
> that
> >provides a
> >similar exposure.
>
>
> Hemant K Chitale
> http://web.singnet.com.sg/~hkchital
>
>
>

--
http://www.freelists.org/webpage/oracle-l