Re: cpujan2006 client issues

Sorry for wading back into this discussion so late.

Yes, Hemant is correct. There certainly is some risk in a situation like this -- an "application" server running an affected Oracle client may be problematic. Certainly, it is likely to be worth patching, even if the risk really is only "minor". When I commented on clients no being worth the trouble to patch, I was (only) thinking of "client" in the context of "those 10,000 Windoze desktops in the hands of end-users".

Of course, my earlier comments *were* based on a few assumptions. The main ones being that the bug in question does not involve "escalation of privilege" (already reported as a valid assumption) and that the affected client code/applications would have to be invoked with carefully crafted parameters to take advantage of the bug. (That last one was, I think, at least 50% pure assumption on my part.) Now, within the context of this assumption, an application server that is successfully attacked through the DBC02 vulnerability is probably sufficiently flawed (hey, it let me run a program and pass it any arguments I darned well felt like!) that it was probably bound to be hacked anyway, even if DBC02 did not exist.

Probably. On the other hand, it *may* be that the people managing this application server recognise that it is fatally flawed, and have miraculously managed to restrict access from the flawed application to all exploitable executables. At the same time, though, they may have opted to allow for "flexibility" by allowing the application server continued access to all non-threatening executables. (While they are miracle workers, it appears that these system managers are also insane!) Now, along comes a bug like DBC02, which makes a previously innocuous application like TSNPING (purely hypothetical!) exploitable.

Yes, in a scenario like this, DBC02 has indeed introduced a new and potentially serious security threat that did not exist before...

Now, I really do *not* mean to be minimizing a threat here. If there was no threat at all, Oracle would not have bothered to produce a patch. Oracle did produce a patch. So now, it is up to each of us to decide whether to apply it.

Bottom line: if one is concerned about this bug, then they should apply the patch. If one is unsure whether to be concerned, then they should probably apply the patch.

Personally, I hadn't been too concerned, but this thread has raised some doubts. I'm still pretty sure that I am *not* going to be patching 10,000 client desktops. (Although maybe I'll get the local Windows support crew to do it -- they don't have enough to do right now.) But I think I may reconsider the question of patching my application servers. I'm fairly sure that they're just *loaded* with bugs, but I don't want the one that *I* left unpatched to the one connected to a major incident. Ah, if only I were allowed to login to them...

Anyway, I'll butt out of this discussion now (to the extent that there still is one).

In the meantime, please everybody, don't let *my* comments dissuade you from applying security patches that you think you might need... (You should maybe rely on somebody else to do that. :-) )

Hemant K Chitale wrote:

>
> 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
>
>
>
>

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