Re: So whats up with the 11.2 java security hole?

From: Vladimir M. Zakharychev <vladimir.zakharychev_at_gmail.com>
Date: Sun, 7 Feb 2010 11:06:32 -0800 (PST)
Message-ID: <bd3f8f00-11e5-40ed-8cbc-d668c59f94f8_at_19g2000yql.googlegroups.com>



On Feb 7, 3:24 pm, Maxim Demenko <mdeme..._at_gmail.com> wrote:
> On 07.02.2010 12:19, Vladimir M. Zakharychev wrote:
>
> > On Feb 7, 2:47 am, John Hurley<johnbhur..._at_sbcglobal.net>  wrote:
> >> Based on David Litchfield ...
>
> >>http://www.computerworld.com/s/article/9151318/Black_Hat_Zero_day_hac...
>
> > He also suggests the workaround (revoking EXECUTE from PUBLIC
> > on certain Java-related packages.) Actually, I'd check the privileges
> > on these packages and revoke EXECUTE from everyone else, too. SYS is
> > just enough.
>
> > Regards,
> >     Vladimir M. Zakharychev
> >     N-Networks, makers of Dynamic PSP(tm)
> >    http://www.dynamicpsp.com
>
> Taking in account the complexity of underlying code, it seems to be
> *not* a straightforward action - i would rather share the Gary Myers
> thoughts on this subject -http://blog.sydoracle.com/2010/02/exploits-and-revoking-risks-of-revo...
> For sure only Oracle can confirm (or deny), such revoke won't break
> anything in provided functionality. Even Oracle would have probably
> difficulties to test against all usual scenarios in context of such
> revoke - much easier will be probably to remove vulnerability in the
> underlying packages. On the other side, the vulnerability is so
> dangerous, that i hope, Oracle's fix should follow rather sooner ( at
> least for those, who get lucky to login into MOS).
>
> Best regards
>
> Maxim

Well, that's a quick and dirty workaround, not a proven remedy. You gotta decide between the real chance of your databases being compromised any time now and some remote possibility that some obscure Java-related stuff in the database will not work as expected. Finding out where the package is used is not too complex - check the dependencies, scan strings from Oracle executables for references to the package and context in which it is being called. Then decide if it's important to have it executable by anyone or by some select group of accounts where it's really needed, or only by SYS. But leaving this particular door open is a clear invitation to local and remote burglars and it better be closed one way or another. For now, the only way is to seal it completely. When Oracle releases a more gentle fix, we'll use that.

Regards,

   Vladimir M. Zakharychev
   N-Networks, makers of Dynamic PSP(tm)    http://www.dynamicpsp.com Received on Sun Feb 07 2010 - 13:06:32 CST

Original text of this message