News Vulnerability Management
3 Must-Fix Vulnerabilities Top Oracle CPU Patches
Two CVSS 10.0 and one 9.0 flaws top the charts on a Critical Patch Update list chock full of remotely exploitable vulnerabilities
Systems administrators on all IT fronts will have their hands busy patching Oracle vulnerabilities across the software giant's portfolio with the release this week of the company's quarterly Critical Patch Update. Security experts warn enterprises to pay particular attention to this last CPU of the year, which today took the wraps off over 100 fixes affecting 10 different product groups, with one or more vulnerabilities in each group open to remote exploitation without exploitation.
[Forgetting something? Don't get caught with your patch down. See 5 Systems Your Forgetting To Patch. ]
More Security Insights
- Remote Data Replication: Combat Disasters And Optimize Business Operations
- Taneja Group: Overview of Virtualization and Cloud Market Vendor Landscape for SMBs
- Strengthening Enterprise Defenses With Threat Intelligence
- Strategy: Advanced Persistent Threats: The New Reality
Of particular note among the fixed vulnerabilities named by Oracle were two flaws with a CVSS base score of 10.0, one for the Core RDBMS database product and one for Oracle Fusion Middleware's JRockit component, as well as another MySQL flaw with a CVSS score of 9.0. According to Oracle, the highly critical JRockit fix was actually part of a broader Java SE Critical Patch to address multiple vulnerabilities affecting the Java Runtime Environment, some of which security pundits expected to address zero-day vulnerabilities disclosed by Security Explorations last month.
"Many were anticipating Oracle would patch Java Runtime Environment (JRE), which they did with Java Runtime Environment Version 7 Update 9 and Version 6 Update 37," says Marcus Carey, security Researcher for Rapid7. "I advise everyone who needs Java to update as soon as possible."
According to Wolfgang Kandek, CTO of Qualys, Java is a frequently neglected piece of software within many enterprise patch processes, an opportunity many hackers have not failed to take advantage of.
"In our research into the vulnerability update cycle, we frequently see Java as being one of the slowest moving applications to be updated, frequently many update cycles behind in patching," Kandek says. "Attackers have adapted to this reality, and many modern exploits go first for a Java based attack, as they know that existing, well-known vulnerabilities can be exploited reliably."
Meanwhile, on the database front, the biggest vulnerability out of the five named within the Core RDBMS product group was a flaw disclosed by Application Security, Inc. researchers in 2010 around the way that Oracle 11 g handled its log-in protocol.
"We're calling it stealth password cracking and it's a vulnerability in the log-in protocol introduced when they released 11g," says Josh Shaul, CTO of Application Security, explaining the flaw allowed for attackers to guess passwords based on information sent to the client by the database.
According to Shaul, Oracle had previously intimated to Application Security that it wasn't going release a CPU update for the flaw, which led to the database security company planning a meticulous public disclosure of the flaw to its customer base and the public at large. Oracle changed course on its decision, which led to Application Security only partially disclosing vulnerability details at a conference in Argentina last month and delaying more detailed disclosure information until after the CPU was released.
"Oracle really struggled with this one because it is a protocol-level issue, which meant that it impacts not just the database but all the clients," he says. "What Oracle explained to us what they were going to do in the CPU was just turn off the Oracle log-in protocol--basically downgrading everyone."
While this reverts back to a lack of case sensitivity in Oracle authentication, that's better than a vulnerability in the environment, Shaul says.
While its CVSS rating was slightly lower, the other major database vulnerability in MySQL deserves equal scrutiny from users, warns Carey.
"That one frightens me more than any of them," he says.
The reason being that according to recent Rapid7 research, half of MySQL deployment instances don't use host based access control. And with so many content management systems like Wordpress using MySQL out on the internet, there is an opportunity for a huge malware outbreak if attackers leverage severe vulnerabilities with scores of 9 or 10 that have lots of potential for remote exploit.
"I fear there could be a major outbreak of MySQL being exploited on massive scale and since so many content management systems use it you could actually find attackers inserting malicious content into the database to have that render and exploit a lot of people," he says.
Beyond those extremely severe vulnerabilities pointed out by the experts, there are dozens more that hold plenty of potential for problems if they aren't addressed in a timely fashion. According to Chris Eng, vice president of research for Veracode, as organizations prioritize it will pay to specifically survey the risks to the install base within their environments and the data processed by those applications.
"If you have really severe issues in data document management server but you're only using that for not very important documents then it may not be that important that you patch that right away," he says. "Maybe you have some cross-site-scripting vulnerabilities in an Oracle product you have deployed that's public-facing. In that case that's going to be more important to patch sooner, even if the severity is lower, because it's public-facing."
Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.