Travis Emmert of CA Veracode is credited in the latest Oracle Critical Patch update for reporting nine Web application vulnerabilities in Oracle Fusion Middleware, Imaging and Process Management. After talking to Travis about how he found the vulnerabilities, what he found, and Oracle’s advisory release process I thought this material would make for a good blog post. I asked Travis to take a few moments to write about this experience. Travis: Oracle recently issued their October 2012 Critical Patch Update. This update contains details of nine vulnerabilities in Oracle Fusion Middleware, Imaging and Process Management I found while testing a web site for a CA Veracode customer. There are two things that struck me that I’d like to write about:
The flaws in question that I discovered are not that exciting to professional web app pen testers. These flaws could have been found by other pen testers I’ve worked with over the years. The vulnerability categories are XSS, script injection, authorization bypass, information disclosure. They are on the OWASP Top 10! These are categories of vulnerabilities that Static Application Security Testing (SAST) services like CA Veracode can find and had Oracle done proper security testing on this component prior to release these issues would have likely been found. What gives, Oracle? Why such basic issues in your product? C’mon – the OWASP Top 10 are the most common security flaws that exist today. Many of these flaws are easy to find – and easy to fix! Are you doing security testing at all?
It took Oracle six months from when I reported these issues to release a patch. In fairness to Oracle they do credit the reporters. However, the way it is handled by lumping everyone together as a group for all of the patched vulnerabilities, (109 in all for this patch), is senselessly vague. The advisory release process keeps security professionals from knowing the details to validate if issues exist for their customers or for testing that proper fixes were applied. Another item that irks me with Oracle’s CPU process is there is no way for people to know who in the credit list reported which vulnerabilities. I believe this is done to prevent people from contacting the correct reporter to learn more details and potentially purchase exploits. Additionally it prevents other organizations that track vulnerabilities from being able to list the researcher who discovered the flaw since no one knows conclusively who discovered what.
It’s disappointing that Oracle does not publicly publish CWE classifiers for each issue. That is something I thought we could add and would be valuable to readers of this blog. We took the CVEs that Oracle assigned to the issues we reported and looked up the CWE (Common Weakness Enumeration) ID for each. As you can see many of these vulnerability classes are quite common and easy to find. CA Veracode’s State of Software Security report shows that XSS (Cross-site Scripting) is the #1 vulnerability in both applications affected and prevalence. So it is really no surprise to find them in a web application such as those that make up Oracle Fusion Middleware. It is important to remember that even commercial software products from major vendors such as Oracle are likely to have vulnerabilities that are in the OWASP Top 10. If the vulnerability category is on the OWASP Top 10 list it is also noted.
Categorizing issues by CWE and using policies built from lists such as the OWASP Top 10 can have many advantages for an application security program. Oracle could track which issues are most prevalent and make sure their developers are trained in secure coding with those vulnerability categories in mind. Alternatively, frameworks, libraries, or shared code that helps mitigate those categories could be sought out and used. On the consumer side, customers can set policies that all the applications they are acquiring be independently tested for all of the vulnerability categories in the OWASP Top 10 and if any of these issues are present the vendor is required to fix them.