The Oracle Global Product Security Blog

Hello, this is Eric Maurice. Oracle released the October 2009 Critical Patch Update (CPUOct2009) today. In a previous blog entry, I explained why this Critical Patch Update had been moved.

Today's Critical Patch Update (CPU) provides 38 new security fixes across a number of product groups including: Oracle Database Server, Oracle Application Server, Oracle E-Business Suite, Oracle PeopleSoft Enterprise, Oracle JD Edwards Tools, Oracle WebLogic and Oracle JRockit (formerly from BEA), and Oracle Communications Order and Service Management. Of these 38 vulnerabilities, 19 are remotely exploitable without authentication.

Oracle Database Server receives 16 new fixes, 6 of which are for vulnerabilities that are remotely exploitable without authentication. Three of these vulnerabilities have received a CVSS Base Score of 10.0. These scores reflect the relative severity of the vulnerabilities as they can result in a full compromise of the targeted system down to the operating system (OS). The CVSS guide available on the FIRST web site provides a detailed explanation on how Base Scores are computed. Note however, that these scores are only applicable for the Windows platform. On other platforms, the score for these vulnerabilities is limited to 7.5 because a successful exploitation of these vulnerabilities will not result in a compromise down to the OS layer. Furthermore, note that these vulnerabilities affect various versions (9.2.0.8; 10.1.0.5; 10.2.0.4; and 11.1.0.6), however the most recent versions of Oracle Database Server (11.1.0.7 and 11.2.0.1) are not subject to these vulnerabilities. This is because of the order in which fixes are produced by Oracle (i.e., the main code line is fixed first, for more information see Oracle's policy for fixing security vulnerabilities).

Due to the severity of the new Database Server vulnerabilities, Oracle recommends that this Critical Patch Update be applied against the affected systems as soon as possible. However, until the application of the CPU, common network access control products, such as reverse proxies and firewalls, which are routinely deployed around sensitive systems, can greatly reduce the risks posed by these vulnerabilities. These network security tools can help prevent attempts to exploit these vulnerabilities remotely, and effectively hide the vulnerable systems from malicious Internet users. As a matter of good security practice, a database server should not be exposed to the Internet, and connections to databases should be limited to securely configured application servers and trusted staff.

Oracle WebLogic and JRockit receive 6 new security fixes. One of the fixes has a reported CVSS Base Score of 10.0. It affects Oracle JRockit, and this fix is in fact designed to address multiple vulnerabilities affecting the Sun Java Runtime Environment. These vulnerabilities were disclosed by Sun Microsystems in August 2009, and the CPU Advisory provides the complete list of Sun advisories addressed in JRockit.

For more information:
o The Security Technology Center on OTN is located at http://www.oracle.com/technology/deploy/security/index.html
o The October 2009 CPU advisory is located at http://www.oracle.com/technology/deploy/security/alerts.htm
o Information to subscribe to Oracle security e-mail notifications is located on http://www.oracle.com/technology/deploy/security/securityemail.html
o Note 360870.1 (My Oracle Support subscription required) explains the impact of Java security vulnerabilities on Oracle products.
o Note 394487.1 (My Oracle Support subscription required) provides a detailed explanation on how the CVSS ratings are applied in the CPU documentation.

Hi, this is Darius Wiles.

Software vendors aim to release defect-free products. Earlier posts have discussed Oracle Software Security Assurance (OSSA) program and its processes that aim to get us as close to this goal as possible. Automated testing is an important part of OSSA as it helps catch problems missed in earlier stages of the development lifecycle and gives us the opportunity of improving our processes to prevent similar problems in future.

When I joined Oracle a number of years ago, we relied almost exclusively on internally-developed testing tools and common freely available penetration testing tools. We had tried many of the commercial tools that were available at that time but concluded they were not useful to us due to their inability to cope with the volume and complexity of code we needed to test. In addition, these commercial tools did not always work correctly with our products (e.g. web application tools could not test web sites protected with Oracle Single Sign-On), and other tools were not able to statically analyze all the programming languages we use. However, the leading commercial scanners have improved significantly over the past few years, and we are now increasingly building them into our standard development and testing processes.

The increasing use of automated tools by Oracle is having an impact on the proportion of security defects that are discovered internally versus those reported by external sources. For reporting and tracking purposes, we categorize security defects into groups based on who found them, namely internal, customer and external. Andy Webber's recent blog post talked about an unexpected internal source of defect reports, but generally, internally-discovered security defects are found as a result of security testing performed by the development, quality assurance, and ethical hacking teams.

The increasing use of automated tools by Oracle is allowing us to find more security defects internally. Of all defects found in 2009 (so far), 87% have been found internally, 10% have been reported by customers, and 3% were found externally. Note that the external group consists of defects reported to us by security researchers, Oracle-specific defects posted directly to the Internet, and problems in third party products/code that we include with our products. One should be wary in drawing comparisons based on this data, especially to compare the effectiveness of these different groups in finding security bugs. The raw statistics provide a slightly unbalanced comparison as many of the internal defects are unlikely to be exploitable in practice: static source code analysis tools tend to err on the side of caution when reporting potential problems and we prefer to add validation checks to likewise be cautious unless we are absolutely sure a potential problem is a false positive. Conversely, most of the customer and external defects have been analyzed in enough detail to weed out the false positives. Additionally, an increasing number of potential defects are being found and fixed during product development, reducing the opportunity for defects to find their way into released products and for people outside Oracle to find them. However, we are using these figures as a guide in tracking our progress in finding an increasing percentage of problems internally.

In a blog posting earlier this year, Reshma Banerjee discussed the inclusion of BEA into OSSA. A lot of good ideas are exchanged between security teams in Oracle and newly-acquired companies. Although many companies have solved the same security challenges in surprisingly similar ways, the variations are always worth exploring as more effective techniques can be shared across the whole company. This includes the use of security testing techniques and commercial testing tools. I expect the continuous improvement in OSSA processes to continue to increase the percentage of internally found defects, relative to the other two categories, and get us closer to the goal of defect-free products.

For more information, a number of Oracle OpenWorld sessions will be dedicated to Oracle Software Security Assurance:

• On Sunday October 11 at 3:30PM: Oracle Software Security Assurance Town Hall with IOUG (panel discussion with Bruce Lowenthal, John Heimann, Mark Fallon, Robert Armstrong, and Hiran Patel)


• On Tuesday October 13 at 11:30AM: Governance and Security Assurance with John Heimann


• On Thursday October 15 at 9:00AM: Software Vulnerabilities: Preventing & Protection with Bruce Lowenthal


• Also on Thursday, at 3:00PM: Critical Patch Update: A Year in Review with Bruce Lowenthal & Eric Maurice

Hi, this is Eric Maurice!

The purpose of today's blog entry is to let you know about a change in the previously announced release date of the October 2009 Critical Patch Update.

Because many Oracle customers with responsibility for deploying the Critical Patch Update within their respective organizations will be attending Oracle OpenWorld on October 11-15, 2009; the October 2009 Critical Patch Update originally scheduled to be published on Tuesday, October 13th 2009, will be released on October 20th 2009.

Please note: this date change only impacts the October 2009 Critical Patch Update. As usual, Oracle will issue a pre-release announcement on the Thursday before the publication of the Critical Patch Update (Thursday, October 15th). All other aspects of the Critical Patch Update (where to find the documentation, how to download the patches, etc.) remain the same.

So, mark your calendar! The next four Critical Patch Update release dates are:

• October 20, 2009


• January 12, 2010


• April 13, 2010


• July 13, 2010

Hi, my name is Andy Webber, I am an ethical hacker in Oracle's Global Product Security group. In recent years, one area I've been focusing on has been the security of passwords.

Through Oracle Software Security Assurance, Oracle aims to continuously provide better security to its customers. This program involves various activities throughout development including, for example, educating developers, reviewing designs, running through security check-lists, having the code analysed by tools, running tests, ethical hacking and independent analysis. Despite these various security checks and the best intention of the developers, which result in many defects being found and fixed, some security defects unfortunately still evade detection before product release and may require the issuance of fixes.

In today's blog entry, I'm going to talk about one particular class of defect whose severity is relatively minor compared to buffer overflows, but still significant especially with regards to a customer's ability to achieve compliance with various regulations: The use of passwords on the command line. The use of passwords on the command line is a relatively hard to detect class of security defect. In addition, it can exist in product code, documentation, sample scripts and other locations.

It is tempting, and indeed a common practice, to accept a password as a parameter on the command line for programs and scripts. However, on UNIX systems for example, it is possible for any user on the same host to view the command line of any other user's running processes, and sometime the environment variables too. There is therefore the possibility that, where one user has entered a command with a password or other secret as a command parameter or environment variable, another user can obtain the password or secret by looking into the environment. Clearly, this can have dramatic consequences! As a result, a common security advice to developers has been to not accept passwords and other secrets as command-line parameters or via environment variables.

Although Global Product Security has for a very long time given unequivocal recommendations on the matter, it is still the case that developers routinely implement this feature. There are many reasons for this behaviour, including expected usage as part of a script rather than directly by a human. In addition, compared to the very simple approach of putting them on the command line, it is difficult to securely pass passwords around between programs in a truly platform independent way.

The use of passwords on the command line is an issue that is not likely to be caught by design reviews (since it is an implementation detail). In some cases, it can be caught by testing, for example by using specific passwords/secrets; using the Linux Auditing System to capture details about every command invoked; and looking through the logs to see if the known password appears. This approach, however, can only detect the problem for the commands actually used during the testing, and only the way they were actually invoked during that testing. If different installation options are chosen, then maybe different commands are run or they are run in different ways, however this can only be detected by trying every possible permutation and combination, which is not always practical if at all possible.

When working on the Oracle Database 11g Release 1, we discovered new allies while addressing the issue of the use of passwords on the command line: the technical writers that produce and update the documentation.

By working with the writers, we were able to produce some specific advice for documenting the handling of passwords. This involved, where practical, converting examples to use a more secure approach (in many cases, where a password is required but not supplied, it will be prompted for interactively). And where there was no secure alternative, the writers raised bugs against the developers requiring them to provide such secure alternative. As a result, for example, in the 11g Release 1 documentation, you are unlikely to see "sqlplus SCOTT/TIGER", and far more likely to see a "Password:" prompt.

As a result of the technical writers' commitment to Oracle Software Security Assurance, we are experiencing the following benefits:

• Enhanced documentation: in all examples where it is practical to do so the documentation indicates where there is more secure and a less secure method of passing a password or secret;


• Better recommendations to customers: by making the secure variant more prominent in the documentation, it encourages customers to adopt it where they can. In addition, the documentation now provides specific guidance about how to use the more secure methods in scripts;


• Increased number of programs and utilities that offer a more secure variant.

Of course, where a piece of code has been released as part of a product, customers may expect it to be able to take a password on the command line and may have custom scripts that require it. In order to maintain compatibility with these use cases, the old functionality will be retained until it eventually becomes deprecated, so there is no need to immediately modify scripts that use the 'old' method. For example, SQL*Plus is likely to accept a password for a long time to come. But, in addition to being a good security practice, the availability of a more secure variant makes it easier to be compliant where policy or regulatory requirements require that passwords are not given on the command line.

There is another major benefit resulting from the involvement of the technical writers in the security assurance effort: If the documentation, training and samples make less use of the use of passwords to SQL*Plus, then, in time, it will fade from memory as new users become accustomed to using only the more secure method.

While we understood that Oracle Software Security Assurance was never just about the code, few of us expected documentation writers to be raising security bugs. I think that the writers' involvement yields an interesting lesson: technical writers in any organizations, whether writing for blogs, documentation, examples and when teaching or training, can lead by example. They should flag insecure examples or behaviors in the documentation and if they can't find a secure alternative to these issues; then they should be empowered to raise a support request on the affected product.

Hi, this is Eric Maurice again.

For the last three years, as we have released each Critical Patch Update (CPU), we have been simultaneously posting a summary of the CPU on this blog (see for example, the last blog entry discussing CPUJul2009). I was recently reviewing past blog entries and realized that one topic -- “How CPUs are tested by Oracle before their release” -- continues to be of great interest to customers, so I thought I’d discuss it here.

The topic of CPU testing by Oracle is relevant to customers because of the potentially significant impact of faulty patches. The most obvious impact of faulty patches is that they may fail to properly resolve the vulnerabilities they were intended to close. More importantly, faulty patches may cause regression issues resulting in data corruption, system outages or other effects that cause applications to execute improperly. (Regression issues occur when a change in the code results in introducing unexpected consequences such “breaking” a functionality that was present in previous versions of the code.) Ultimately, faulty patches almost always result in re-issuance by their author, and costly reapplication by customers. But perhaps the least desirable impact of faulty patches is that customers may delay or defer applying future patches because of a fear that “the security patches may create more problems than they solve.”

For all of these reasons, Critical Patch Update quality has been the highest priority for Oracle. Under the leadership of Mary Ann Davidson and her team, all parties involved in the production of Critical Patch Updates are told in no uncertain terms that faulty patches will not be tolerated.

So, how does Oracle help make sure that CPUs don’t create issues in customers’ environment? Let’s look at the process Oracle follows with Database Server CPUs, keeping in mind that Oracle’s objectives with CPU testing are twofold: (1) prevent undue consequences resulting from the CPU patches (regression issues), and (2) ensure that the vulnerabilities are addressed effectively (preventing incorrect or incomplete fixes).

The first step in the remediation process for any vulnerability is the discovery or reporting of the vulnerability to Oracle. Security vulnerabilities can be reported to Oracle by external sources such as customers and security researchers. Vulnerabilities can also (and often will) be reported by internal sources including: Oracle’s own assessment team, developers themselves, and results of automated tests used throughout development.

Once a vulnerability has been discovered or reported to Oracle, it is analyzed to understand -- for example -- what components or interfaces are affected, which components of the code are vulnerable, how the vulnerability can be exploited, how it can be eliminated, what other mitigation measures are possible, etc. (This analysis phase is so important and complex that it could be, by itself, a topic for a future blog entry.)

At the end of the analysis phase, a fix for the vulnerability is produced, and regression tests are conducted to verify that the fix will not result in unintended consequences. Developers and security experts then review this fix before being included in the main code line (that is, if the vulnerability is not limited to previous versions of the affected component) where full regression tests are run. Once the inclusion in the main code line is complete, the fix is ported to future patchsets. In addition, the fix can be scheduled for inclusion in a future Critical Patch Update.

Let’s now look at the process Oracle follows for testing Database Server security fixes specifically included in Critical Patch Updates. To understand the level of effort required with each CPU release, one has first to go back to understanding the scope of the Critical Patch Update program:
- CPU patches are released for ALL Oracle products every quarter, on the Tuesday closest to the 15th of the months of January, April, July, and October;
- On these dates, CPU patches are published for all supported versions on all their respective platforms (with the exception of On-Request versions)
- CPUs for many Oracle products are cumulative (i.e. CPUs include new fixes as well as previously-released fixes).
In other words, on the release day of the CPU, Oracle releases a large number of patch sets for each platform-version combinations affected by the CPU. For example, the April 2009 Critical Patch Update included fixes for seven versions of Oracle Database Server (11.1.0.6; 11.1.0.7; 10.2.0.3; 10.2.0.4; 10.1.0.5; 9.2.0.8; 9.2.0.8DV) on over 20 different platforms!

In order to provide enough time for thoroughly testing the fixes included in CPUs, the initial selection of the new fixes to be included in each CPU takes place 15 weeks before the CPU release date. These fixes are then backported to all supported version-platform combinations with a few exceptions for things like On-Request versions. Next, Oracle runs a full set of regression tests against the aggregated patches for each of these version-platform combinations.

Six weeks before the CPU release date, CPUs are assembled in what we call “early combinations.” These “early combinations” are provided to other development organizations to verify that CPU’s don’t create problems across the Oracle stack. For example, throughout this six weeks period, the development organizations for the various product lines such as E-Business Suite, PeopleSoft, and Siebel, perform tests with the database CPU early combinations to ensure that database fixes will not result in problems with the applications and to catch regressions that might occur with customer applications. During this period, Oracle performs additional comprehensive vulnerability fix testing to ensure that all newly addressed vulnerabilities are effectively fixed in all version-platform combinations of the CPU.

In addition to the steps above, during the four final weeks before the release of each CPU, CPU early combinations are provided to the support and other organizations to perform installation testing. It is during that period that Oracle ensures that documentation is clear and accurate and that the CPU installs as expected. It is also during this period that the support organization grows familiar with the CPU in order to provide support to customers who may call for CPU-related issues once the CPU has been published.

Note that under Oracle Software Security Assurance disclosure policies, Oracle doesn’t share CPU early combinations or other information associated to the upcoming CPU with third party organizations. This is because Oracle is very concerned about treating each customer equally, and ensuring that the content of the upcoming CPU not be leaked out, possibly aiding in the development of exploit code. However, during the entire process leading to the release of the CPU, Oracle works with the individuals who have submitted the vulnerabilities fixed in the CPU, keeping them informed of progress, and sometimes discussing the nature of the fix implemented by the CPU with them. These individuals, many of them security researchers, are listed in the credit section of the CPU Release Note.

This commitment to CPU quality under Oracle Software Security Assurance has eliminated many issues that customers may have previously encountered with Critical Patch Updates, leading a prominent security researcher to recently declare: “The database patches are very easy to apply and have very few problems. You get a huge benefit without a lot of effort.” This type of endorsement by folks in the security researchers and analysts’ communities, as well as positive feedback from customers, are great rewards for the people involved in the production, testing, and support of the Critical Patch Updates.

Hi, this is Eric Maurice again. Today, Oracle released the July 2009 Critical Patch Update (CPUJul2009).

This Critical Patch Update (CPU) includes 30 new fixes across hundreds of products, including some newly acquired product lines (including BEA).

This Critical Patch Update includes 10 additional fixes for Oracle Database Server. Three of these 10 vulnerabilities are remotely exploitable without authentication. None of these vulnerabilities affect client-only deployments.

Three of the Database Server vulnerabilities addresses in this CPU are particularly critical with CVSS Base Scores of 7.5 or over (“high severity” according to the NVD guidelines):
- Vulnerability CVE-2009-1020 receives a CVSS Base Score of 9.0 for Windows, and 6.5 for Unix, Linux, and other platforms. This means that a successful exploitation of the vulnerability can lead to a full compromise of the targeted server at the OS level only on Windows platforms. On other platforms, the scope of the exploitation will be limited to the database layer (i.e. only the database application will be compromised). This vulnerability affects Oracle Database Server 9.2.0.8, 9.2.0.8DV, 10.1.0.5, 10.2.0.4, and 11.1.0.7. —This vulnerability is not remotely exploitable without authentication: The attacker needs to be authenticated to the Database (or use a previously authenticated session) in order to carry on the attack.
- CVE-2009-1019 receives a CVSS Base Score of 7.5 denoting that a successful exploit of this vulnerability can lead to a full compromise of the targeted database. This vulnerability affects Oracle Database Server 9.2.0.8, 9.2.0.8DV, 10.1.0.5, 10.2.0.4, and 11.1.0.7. It is remotely exploitable without authentication.
- Finally, CVE-2009-1963 also receives a CVSS Base Score of 7.5; however it is not remotely exploitable without authentication, and only affects Oracle Database Server 11.1.0.6.

Oracle recommends that this Critical Patch Update be applied against affected Database Server as soon as possible. However, customers should be aware of mitigation measures that may decrease the risks posed by these vulnerabilities in unpatched systems. For example, database servers protected from the Internet through the use of reverse proxy and firewalls, and whose connections are limited to connections to a securely configured application server, are less vulnerable to external attacks. In addition, proper auditing and monitoring can mitigate the risks associated with attempts to exploit these vulnerabilities from an inside source. The security guides and checklists available on the Security Technology Center on Oracle Technology Network provide a number of recommendations to securely deploy Oracle products. When properly implemented, many of these recommendations will greatly reduce the risks posed by vulnerabilities addressed in CPUs.

In addition to the 10 Oracle Database Server fixes, this CPU also provides:
 two additional fixes for Oracle Secure Backup 10.2.0.3,
 two additional fixes for various versions of Oracle Application Server,
 five new fixes for various components of Oracle E-Business Suite,
 two additional fixes for Oracle Enterprise Manager 10.2.0.4,
 three additional fixes for various PeopleSoft components,
 one additional fix for Siebel Enterprise, and
 five additional fixes for the BEA products suite.

The Oracle Secure Backup vulnerabilities fixed in this CPU have respective CVSS Base Scores of 10.0 (CVE-2009-1977) and 9.0 (CVE-2009-1978). The last patchset affected by these vulnerabilities is Oracle Secure Backup 10.2.0.3. Oracle strongly recommends that all previous versions of Oracle Secure Backup be upgraded to version 10.2.0.3 and that the fixes be applied, or that customers apply a newer version (10.3.0.1.0). Of course, customers already running Oracle Secure Backup 10.3.0.1.0 or who are not running Oracle Secure Backup should not be concerned about the vulnerabilities associated with older releases.

Note that vulnerability CVE-2009-1094 listed in the BEA Risk Matrix section of the CPU advisory, and affecting the JRockit component, received a CVSS Base Score of 10.0. This fix was in fact released to address a number of vulnerabilities previously reported by Sun MicroSystems in a Security Alert released in March 2009. These multiple vulnerabilities affect the Sun Java Runtime Environment. Oracle CVE-2009-1094 refers to all the Sun advisories that were applicable to JRockit. The CVSS score of 10.0 reported by Oracle in today’s CPU advisory is the highest score (received from NVD) of all the advisories fixed in JRockit. Note that the CPU advisory provides the complete list of all the Sun advisories affecting JRockit.

For more information:

The Security Technology Center on OTN is located at http://www.oracle.com/technology/deploy/security/index.html

The July 2009 CPU advisory is located at http://www.oracle.com/technology/deploy/security/alerts.htm

Information to subscribe to Oracle security e-mail notifications is located on http://www.oracle.com/technology/deploy/security/securityemail.html

MetaLink Note 360870.1 (subscription required) explains the impact of Java security vulnerabilities on Oracle products.

MetaLink Note 394487.1 (subscription required) provides a detailed explanation on how the CVSS ratings are applied in the CPU documentation.

Hi, this is Shaomin Wang. I am a security analyst in Oracle’s Security Alerts Group. My primary responsibility is to evaluate the security vulnerabilities reported externally by security researchers on Oracle Fusion Middleware and to ensure timely resolution through the Critical Patch Update. Today, I am going to talk about a serious type of attack: Cross-Site Request Forgery.

Cross-Site Request Forgery (CSRF), also known as Cross-Site Reference Forgery (XSRF), Session Riding and Confused Deputy Attack, is a type of malicious exploit where unauthorized requests are transmitted from a user to a trusted website (the target). CSRF exploits the trust that the targeted site has in a user’s browser and generally works by embedding a link or script in a malicious page (previously compromised by the attacker or belonging to a site specifically built for the purpose of carrying the attack) to access a site to which the user has already been authenticated. Ultimately, the trusted site is the target of the attacks, but the user is both the victim and an unknowing accomplice of the attack.

Here is how CSRF works. Let’s look a simple example where the server authentication is based solely on session cookies.

a) User Alice logs into her bank’s site by providing her username and password. The banking site identifies her and creates a unique session identifier (sid). The sid is saved in Alice’s cookie and passed from Alice’s browser to the banking site for each subsequent request. Each time, the banking site identifies Alice by matching the cookie value sid passed in the request header to the server stored session value. Once identified, Alice is allowed to perform authorized actions.
b) Without logging out her banking site, Alice visits a malicious site “hackme.com”. “hackme.com” contains a hidden form/JavaScript code or an image tag that causes Alice’s browser to send a malicious request to her banking site. On this request, Alice’s browser “happily” attaches the cookie containing the session id to “hackme.com”.
c) Once accepting the malicious request, Alice’s banking site identifies the request as coming from Alice. The malicious request operation is then performed on behalf of Alice, and Voila!!!

CSRFs are not a new class of attack. They can be both simple and devastating. With a little social engineering, the attacker can trick the user into authenticating onto the targeted site, thus ensuring that the CSRF attack will be successful. And because the user’s browser sends the request to the targeted site, CSRF attacks are typically executed with the same level of privileges as the user, meaning any action the user can perform on the targeted site can also be performed by the attacker through the CSRF attack. Consequently, the more privileges a site grants its user, the more impact CSRF attacks can have (thus making financial sites a prime target for malicious perpetrators). If the end user has administrative privileges on the targeted system, a CSRF attack can lead to compromising the entire web application on the targeted system.

Vulnerability to CSRF is extremely widespread. CSRF attacks often exploit the authentication mechanism of targeted sites. In general, whenever authentication happens implicitly, there is a danger of CSRF attacks. Unfortunately, today, most web applications rely solely on automatically submitted credentials such as session cookies, basic authentication credentials, source IP addresses, or SSL certificates.

The concept of CSRF was first introduced in a research paper titled “The confused Deputy: (or why capabilities might have been invented)” by Norman Hardy in 1988. In Feb 2000, CERT published an advisory titled “Malicious HTML Tags Embedded in Client Web Request.” The advisory stated that “At the heart of this vulnerability is the violation of trust that results from the “injected” script or HTML running within the security context established.” In May 2000, Jim Fulton wrote an article, “Client Side Trojan”, on zope.org touching upon the same topic, where he stated that “potentially any Web-accessible system is vulnerable to this type of attack.”

CSRF got its current name in 2001 after Peter Watkins posted a note to bugtraq, where he wrote: “The problem is what I call CSRF (Cross-Site Request Forgeries, pronounced ‘sea surf’). Any time you can get a user to open an HTML document, you can use things like IMG tags to forge requests, with that user's credentials, to any Web site you want -- the one the HTML document is on, or any other”.

However, until very recently, CSRF were rarely discussed in the security community. For example, MITRE Vulnerabilities Trends 2007 stated that the first CSRF was reported to CVE in 2002. Until 2006, CSRFs were rarely reported to CVE. However, there have been some high profile CSRF attacks in the last two years:

 In 2008, a CSRF vulnerability was found in New York Times’ website. Attackers could take advantage of NYTimes.com’s “Email This” feature to obtain user’s email addresses.
 The same year, a vulnerability in ING’s website (ingdirect.com) was detected. It allowed an attacker to create an additional account on behalf of an arbitrary user. As a result, it was possible for the attacker to move funds out of a customer’s account. This was the first reported time that a CSRF allowed the transfer of funds from a financial institution.
 Up to 2008, YouTube was vulnerable to CSRF attacks. Malicious attackers were able to add videos to a user’s “Favorites” list, add themselves as friends to a user, and even send messages on behalf of a user.

Several CSRF server side countermeasures are available, e.g. checking the HTTP referrer header to see if the request is coming from an authorized domain; The more reliable way of counter CSRF attacks is to require a secret, user-specific token in all form submissions.

CSRF vulnerabilities are not as well known and understood by web programmers as Cross Site Scripting Vulnerabilities (XSS). It is my experience that too many web developers are under the wrong impression that XSS fixes can also prevent CSRF attacks. Furthermore, while CSRF attacks do not require exploiting XSS, any application with XSS flaws is susceptible to CSRF. CSRF attacks can exploit the XSS flaw to steal any automatically submitted credential. It is critical that web developers provide defenses against both classes of attacks. I believe that the lack of awareness around CSRF greatly contributes to the prevalence of the attacks.

For more information:
o For an excellent article explaining limitations and prevention measures of CSRF, see: http://www.owasp.org/index.php/Cross-Site_Request_Forgery
o A testing guide for CSRF from OWASP: http://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005)
o Confused deputy problem from Wikipedia: http://en.wikipedia.org/wiki/Confused_deputy_problem
o Peter Watkins’ note to bugtraq: http://www.tux.org/~peterw/csrf.txt

Hi, my name is Adam O’Brien. I help guide Oracle products through Common Criteria evaluations. Common Criteria is a worldwide, government-backed scheme for testing the security of a product or system. Essentially, you state what security functions your product should be able to perform, then an independent lab evaluates if the product implements these functions reliably and robustly.

Historically, Oracle has been very proactive in evaluating its products through Common Criteria. To date, the company has obtained 26 evaluations, and 13 evaluations are currently pending. This commitment to Common Criteria makes a lot of sense: we perform a rigorous security assessment of our products and gain a certificate that helps federal and government sales. In addition, these evaluations are beneficial to non-government customers in that they constitute a third-party validation of the effectiveness of the security controls provided by the evaluated product.

A Common Criteria evaluation is often mandated for a government sale and it has a (near) global acceptance. These two aspects also lead to the main inconvenience of Common Criteria – it is bureaucratic and very slow to change.

Common Criteria has been used for 10 years, and version 3 was only recently introduced. The Common Criteria working groups are already in place looking at prospective changes for version 4 of the standard (Common Criteria is also known as ISO/IEC 15408 international standard). Previously, vendors were excluded from these working groups, and participation was limited to government agencies, such as the US National Security Agency (NSA). These government agencies alone decided how the standard should change. The vendors were presented with a revised version and expected to use it.

Recently a number of vendors, including Oracle, have been allowed to provide input to the working groups, in part through lobbying activities from an umbrella group of companies called the Common Criteria Vendors Forum. Note however that none of these companies were given a seat in the working groups. We are hoping that vendors’ participation will help assure that the changes in version 4 will make the process more effective at finding vulnerabilities and giving assurance of security. Even more importantly, vendors can use their (minor) influence to try to force these working groups to keep to their schedules.

There are six working groups, some with rather odd sounding names:
Evidence-based approach – looking at ways of making more use of the design documentation produced as part of product development, rather than (wastefully, in my opinion) producing evidence specifically for the Common Criteria process.
Predictive assurance – looking at ways to examine vendor development processes to determine some level of predictability for future assurance. For example, if version 5.0 of a product is evaluated as being secure and the product lifecycle process and bug fixing systems are reliable, can we have some level of assurance that version 5.2 will be secure?
Skills and interaction – ensuring the independent testers have a staff development process to stay up to date with attack methodologies and tools.
Meaningful reports – trying to reform the reports produced at the conclusion of a Common Criteria evaluation so that they offer meaningful information to vendors without publicly disclosing confidential information.
Lower assurance evaluations – finding ways to perform quicker and cheaper Common Criteria evaluations that still give some assurance of security.
Tools – looking at ways to integrate the use of tools that check source code for vulnerabilities into Common Criteria.

I’m the liaison between the vendors and the Common Criteria working group on tools. I suspect this could be a very lively topic. Automated detection of vulnerabilities can find lots of vulnerabilities, but in my experience, many of the flaws detected are false positives or are unexploitable and can therefore be considered low priority issues. Configuring the tools is also a critical and difficult process. Oracle, in the last few years, has developed tremendous experience with automated tools. It is my hope that, through this working group, we can share the very steep learning curve we experienced with such technology; we have many insights to share.

At the moment, the “tools” working group seems to be making slow progress and it isn’t yet in a position to accept any suggestions or feedback. However, I am still gathering views within Oracle and the rest of the vendor community on what we want to see in this area, hoping that the working group will soon be able to accept feedback. Hopefully, such feedback will happen soon. This might help set the working group on a reasonable course from the start, because I suspect that significant changes might be hard to produce once the working group has engaged into its process.

This is Reshma Banerjee again. In my last blog entry, I wrote about some of the things that are happening as a result of BEA’s transition into the various Oracle Software Security Assurance programs. Today, I will discuss the changes that affect the security advisories previously published by BEA.

Previously, BEA had a security advisory and patch release program similar to Oracle’s Critical Patch Update. However, as a result of the acquisition, the BEA process has been superseded by the Critical Patch Update process in order to maintain a consistent security patching and advisory experience for all Oracle customers regardless of the products they use. Some of the key changes are highlighted below.

The Critical Patch Updates are released on a quarterly basis, on dates provided a year in advance, thus providing customers a predictable security patching schedule. This predictability was not provided by BEA’s security advisory and patch release program, and it will be of great interest to BEA customers who will now be able to include security patching in their normal maintenance cycles.

Adding further to this predictability, Oracle publishes a summary of the Critical Patch Update Documentation on the Thursday prior to the release of each Critical Patch Update. The BEA advisories were included for the first time in the July 2008 Pre-Release Announcement. As for all other Oracle products, the Critical Patch Update Pre-Release Announcements for BEA products will provide advanced information about the upcoming Critical Patch Updates, including:
- Name and version numbers of the products affected by new vulnerabilities that are fixed in the Critical Patch Update
- Number of security fixes for each product suite
- Highest CVSS base score for each product suite
- And, potentially, any other information that may be relevant to help organizations plan for the application of the Critical Patch Update in their environment

The Critical Patch Update Pre-Release Announcements are posted on the Critical Patch Updates and Security Alerts page on Oracle’s web site, and are replaced on the day of the release of the Critical Patch Update with the actual Critical Patch Update Advisory document.

Obviously, the use of a common process for advising customers of security updates across all Oracle products results in bringing consistency to customers, who often have to deal with managing multiple Oracle products in an otherwise heterogeneous technical environment. The advance notification makes customers aware of the key security issues addressed in the CPU and whether they are affected by them. This advance notification also provides customers with the ability to assess the criticality of the vulnerabilities fixed in the CPU and allows them to prioritize their patching effort.

Another area of change will be with the content of the security advisories for BEA products. The Critical Patch Update documentation includes risk matrices for each product suite that receives new fixes in the CPU. These risk matrices are designed to help customers assess the risk posed by each newly-fixed security vulnerability in their specific environment. The risk matrices provide the following information:
- affected versions of the product,
- affected component and protocol,
- required packages/privileges and
- CVSS Base Score rating of the vulnerability
These risk matrices are designed to provide enough information to allow customers to assess the exploitability and impact of the vulnerability and to determine which components/product versions are affected for testing purposes. Vulnerabilities are listed in order of severity in the risk matrices, and as a result, customers can easily identify the vulnerabilities most critical to them. The risk matrices can also be used to single out the systems most at risk in a customer’s environment so that these systems can be patched first.

In the past, BEA advisories used an alternate form of risk assessment, which would be at times redundant to the type of information disclosed in the Oracle CPUs. In order to maintain consistency in the CPU documentation, this alternate form of risk assessment will no longer be provided. In addition, BEA used to provide specific information about the types of vulnerabilities fixed in the advisory. Under Oracle’s policies, this information is deemed too specific and potentially harmful as it could result in empowering malicious attackers. This kind of detailed information will therefore no longer be provided.

In addition, starting with the April CPU, patch availability information for the security advisories for former BEA products will be made available exclusively through Metalink. This is also consistent with the practices for most other Oracle products.

The adoption of Oracle Software Security Assurance also results in changes in how we communicate with security researchers. Prior to the acquisition, BEA used secalert@bea.com for any email communication with security researchers. This address will now be replaced by secalert_us@oracle.com which is the address used for all other Oracle products. Note that BEA did not use encrypted emails for communicating with security researchers, however Oracle encourages the use of encryption for such communication (Oracle’s encryption key can be found at http://www.oracle.com/technology/deploy/security/encryptionkey.html).

Finally, like the now obsolete BEA security site, the Oracle Critical Patch Updates and Security Alerts site supports RSS feeds. Anyone can subscribe to these feeds and be notified on changes made to the page (including when the Pre-Release Announcements are published). Note that BEA customers, who were previously subscribed to the BEA RSS feeds, will need to re-subscribe to the Oracle RSS feed on http://www.oracle.com/technology/deploy/security/alerts.htm.

I feel that the adoption of the various Oracle Software Security Assurance programs have contributed to make the security advisory program for BEA products more predictable and useful to customers. In my opinion, Oracle and BEA teams put in a tremendous effort to align the processes to provide a consistent and positive experience to ALL Oracle customers.

Hello, this is Eric Maurice again!

Today Oracle released the April 2009 Critical Patch Update (CPUApr2009).

This Critical Patch Update (CPU) includes fixes for 43 new security vulnerabilities across the following product families: Oracle Database Server, Oracle Application Server, Oracle E-Business Suite, Oracle PeopleSoft Enterprise, and Oracle WebLogic.

16 of the 43 vulnerabilities affect Oracle Database Server, and two of these 16 vulnerabilities are remotely exploitable without authentication. In addition, two of these sixteen vulnerabilities yield a CVSS Base Score exceeding 7.0 (NVD characterizes the severity of vulnerabilities with score between 7.0 and 10.0 as “High”).

The most severe Database Server vulnerability rates a CVSS Base Score of 9.0. It can potentially allow an attacker to gain full control of a vulnerable server. None of the Oracle Database Server 10g and 11g releases are affected by this vulnerability, however, this vulnerability does affect Oracle Database Server 9.2.0.8 and 9.2.0.8DV. Because of the severity of this vulnerability, organizations running vulnerable versions (Database Server 9.2.0.8 and 9.2.0.8DV) should plan to apply the Critical Patch Update as soon as possible. Furthermore, until these systems are patched, organizations should ensure that additional mitigation measures be implemented. Such measures may include additional monitoring of these systems and ensuring that appropriate network access control measures are implemented around them.

The second most severe Database Server vulnerability yields a CVSS score of 7.1. This is a severe CVSS Base Score however an attacker would need IMP_FULL_DATABASE privilege to exploit this vulnerability. IMP_FULL_DATABASE allows importing of databases and thus is a very high privilege, typically limited to trusted DBAs. Again, organizations are advised to apply the Critical Patch Update as soon as possible. In addition, until these systems are patched, organizations should ensure that the IMP_FULL_DATABASE privilege is limited to trusted administrators, and use of this privilege should be fully audited.

The Critical Patch Update also addresses eight new vulnerabilities with the Oracle WebLogic and AquaLogic product families. Two of these eight vulnerabilities have a CVSS Base Score of 10.0.

The first of these vulnerabilities affect JRockit, and encompasses a number of issues affecting the Sun Java Runtime Environment that were previously disclosed by Sun Microsystems. The Critical Patch Update includes all the applicable fixes that were previously released by Sun to solve these issues in JRockit.

The second of these vulnerabilities affects the WebLogic Server Plugins for Apache and IIS web servers. The CVSS Base Score is reported as 10.0 by Oracle, even though organizational security policies typically call for not running Web servers as root. In deployments when the Web server doesn’t run as root, the CVSS score for this vulnerability is 7.5 because a successful exploit of this vulnerability will not lead to a complete take over of the machine at the OS layer. Note that Oracle has addressed a series of issues in the WebLogic Server Plug-ins since the BEA acquisition, and the fixes for this plugin are cumulative. This means that this CPU patch includes all previously released fixes as well. Organizations are encouraged to apply this CPU as soon as possible in order to take advantage of these fixes.

The Critical Patch Update is in its fifth year of existence (the program was introduced in January 2005 and the current CPU is the 18th). Over the years, the program has proven to be flexible enough to accommodate additional product families (with the inclusion of PeopleSoft, Siebel, and BEA, among others), and continues to provide customers with a consistent process and predictable schedule to deal with security patches across their entire Oracle environment.

For More Information:

Critical Patch Updates & Security Alerts web site is located at: http://www.oracle.com/technology/deploy/security/alerts.htm

Oracle Software Security Assurance web site is located at: http://www.oracle.com/security/software-security-assurance.html

For more information about Oracle’s use of the CVSS standard, see: http://www.oracle.com/technology/deploy/security/cpu/cvssscoringsystem.htm