Re: cpujan2006 client issues

  • From: Hemant K Chitale <hkchital@xxxxxxxxxxxxxx>
  • To: mark.brinsmead@xxxxxxx, stellr@xxxxxxxxxx
  • Date: Thu, 02 Feb 2006 20:52:16 +0800


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


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


Other related posts: