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

  • From: Pete Finnigan <pete@xxxxxxxxxxxxxxxx>
  • To: david@xxxxxxxxxxxxxxxxxxxx
  • Date: Tue, 26 Jun 2012 19:28:39 +0100

I would add  to David's comments; also stop people you employ connecting
to the database or from having direct access to try and connect to the
database; the bigger threat is internal for a number of reasons. You
give lots of employees access to your systems including for some to
databases; In lots of companies i work in there is "open routing"
available to the databases therefore even without a username/password
remote non authenticated exploits doesnt mean remote as in a kid in his
bedroom but simply connecting to the database which could be inside your
org. The other problem with insiders is that often they also have more
knowledge than outsiders because you pay them to know your systems and
data and they know where to steal it.

removal of accounts, hardening of passwords, reduction of privilege and
above all preventing actual direct connections to the database and
potential connections will go a long way to make it harder to exploit
your databases. A skilled attacker will never be thwarted by all the
layers given enough time but patching/hardening and securing data access
. Of course as David says all comments are general as I have not seen
the environment and dont know what you have done already.

Risk reduction is about money; when there are lots of databases that
could be lots of money so its best to target your money wisely to reduce
the risk as much as possible for whats spent. Strategic solutions (maybe
a firewall in front of the DB not in front of the company) often can be
cheaper than technical targetted solutions on hundreds or thousands of
databases.

cheers

Pete

david@xxxxxxxxxxxxxxxxxxxx wrote:
> Hey all,
> 
>> The risk for an external threat is pretty much minimized through a set of 
>> security layers such as the Firewall, anti-virus, etc.
> 
> Without seeing a specific environment I'd tend to disagree; better to be 
> more cautious than not. If the database in question is connected to a web or 
> application server then there's the potential for SQL injection; there's 
> potential for exploitation of flaws in the app environment itself (struts, 
> anyone? OAS?); and host of other issues that can relegate the firewall to an 
> expensive box with pretty flashing lights. In this day and age, anyone that 
> thinks a firewall offers sufficient protection should open a newspaper and 
> read about all the database security breaches taking place. Do you really 
> think those orgs weren't using firewalls? As far as WAFs are concerned - 
> they can be bypassed by a moderate to skilled attacker. I know it's a pain 
> but the best strategy really is keeping your patches up to date and reducing 
> your attack surface.
> Cheers,
> David
> 
> --
> http://www.freelists.org/webpage/oracle-l
> 
> 
> 

-- 

Pete Finnigan
CEO and Founder
PeteFinnigan.com Limited

Specialists in database security.

Makers of PFCLScan the database security auditing tool.
Makers of PFCLObfuscate the tool to protect IPR in your PL/SQL

If you need help to audit or secure an Oracle database, please ask for
details of our training courses and consulting services

Phone: +44 (0)1904 791188
Fax  : +44 (0)1904 791188
Mob  : +44 (0)7759 277220
email: pete@xxxxxxxxxxxxxxxx
site : http://www.petefinnigan.com

Registered Office: 9 Beech Grove, Acomb, York, YO26 5LD, United Kingdom
Company No       : 4664901
VAT No.          : 940668114

Please note that this email communication is intended only for the
addressee and may contain confidential or privileged information. The
contents of this email may be circulated internally within your
organisation only and may not be communicated to third parties without
the prior written permission of PeteFinnigan.com Limited.  This email is
not intended nor should it be taken to create any legal relations,
contractual or otherwise.
--
http://www.freelists.org/webpage/oracle-l


Other related posts: