Re: CVE-2012-1675 (Oracle 11gR2 RAC) - Actual Risk?

  • From: Martin Berger <martin.a.berger@xxxxxxxxx>
  • To: dbmangler@xxxxxxxxx
  • Date: Wed, 13 Jun 2012 23:01:07 +0200

Jeff,

recently I had the chance to watch a penetration test for some days.
The tester was quite skilled, but with no unknown tools, 'just' a set
of available tools and good knowledge how to use them.
There was not the one big hole he found; it was just like finding a
small permission escalation, this used for another attack and so on.
After some days several systems where totally compromised.
Their administrators where also allowed to watch what is going on and
learned a lot (and I can not blame them for being lazy!)

I try to show you the big learning in this penetration test: Do never
rely on some other security system. If you have a security problem,
just make sure you know if it can harm your systems.

Martin



On Wed, Jun 13, 2012 at 8:55 PM, Jeff Thomas <dbmangler@xxxxxxxxx> wrote:
> This may seem a naive exercise - but I'm trying to determine the actual
> risk of this exploit vs the implementation risks required for our 11gR2 RAC
> environments.
> My understanding is that this exploit has been 'known' since 2008 -
> although not publicized.    And Oracle rushed out the alert and fix
> in response to the publishing
> of the exploit.     The exploit seems to be somewhat complex man-in-the
> middle attack that requires access inside the firewall, or your cluster's
>  exposure to an
> insecure network.
>
> If this is not the case for our databases - if all clusters are
> contained within the internal network - and there is no exposure out - what
> is the real risk?
>
> We've tested in our lab - and were able to validate via the remote_listener
> from another cluster both prior to and after the fix.    The 11gR2 fix is a
> little bit of a tedious
> process - involving a number of pieces, the wallets, etc.     I hate to add
> complexity to our structure for the sake of appearances as opposed to a
> true necessity.
>
> Best,
> Jeff
>
>
> --
> //www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l


Other related posts: