Indeed, Oracle released an emergency update to deal with the issue. Dubbed CVD-2012-3132, you can read Oracle’s security alert on the issue at the link. It’s a nasty privilege escalation bug, which means that an attacker can gain complete control of the affected server.
Fortunately, there are certain limits as to who can take advantage of this flaw. The hacker needs to be an authenticated user of the database, because of the way the attack must be carried out to exploit the flaw. The attacker gains database administrator privileges on the server by executing arbitrary SQL commands – which means whoever is making the attack must have the right to perform SQL commands on the database in the first place.
Oracle noted in its advisory that products including the Oracle Database Server component are affected. That’s a rather lengthy list; it includes Oracle Fusion Middleware, Oracle Enterprise Manager, and Oracle E-Business Suite. Affected versions of Oracle Database Server include 10.2.0.3, 10.2.0.4, 10.2.0.5, 22.214.171.124, 126.96.36.199, and 188.8.131.52. If you employ any of these versions, they need to be patched at once.
There is some good news, however. The July 17 patch update from Oracle took care of some versions. "Oracle Database Server versions 184.108.40.206 and 220.127.116.11 do not require patching if the July 2012 Critical Patch Update has been applied," according to the software company.
So where exactly did this bug come from? How does it activate? The problem comes in when the database is presented with single quotes in a column name. Apparently, something in the way the system handles this lets attackers create indexes and triggers to certain system tables.
One mildly comforting thought to keep in mind is that any attacker must first log in as a database user – and they can’t be just any user. If they have read-only access to the database, they can’t exploit this privilege escalation flaw. They need actual privileges to the database – specifically, they must be allowed to create tables and procedures – for this SQL-injection attack to work. Otherwise, they can’t even start.
So how can you guard against this attack, at least until you get the patch in place? Make sure your application’s roles and privileges are correctly segregated. Check your software package; it might default to giving users more access or privileges than they actually need. Also, make sure you’ve turned off super user accounts.
You can get more information on this story here.