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

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.

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.

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

Product evaluations under the Common Criteria program involve examining the product, its supporting documentation, and its development environment to establish that product security functionality is acceptable and works as it should. Completion of a Common Criteria security evaluation is an indication of confidence in the security of the product and is recognised by the 26 countries that have signed the Common Criteria Recognition Agreement. At the moment Oracle has security evaluations performed in the UK, Germany and the USA. In a previous blog entry, Duncan Harris provided a good introduction to the Common Criteria. For more details on Common Criteria security evaluations see www.commoncriteriaportal.org.

There is an interesting challenge when a product new to Oracle (such as is the case after an acquisition) needs to be submitted for a Common Criteria evaluation. In such instances, we need to discover what has previously happened regarding the development, functional and test specifications of the submitted product, and gain access to the documentation related to the security functions of the product. Sometimes, this documentation has not been completely brought over to Oracle. In other instances, the documentation simply may not be available. At this point, it may be necessary to rely on the information within the source code to fill in the documentation gap. This adds to the time required for the evaluation and ultimately to its cost. Furthermore, even when the documentation exists, tracking it down can often be very time consuming!

Two other areas under scrutiny during a product evaluation are related to Lifecycle Support and Configuration Management. Lifecycle Support examines the Product Release Process as a collection of activities by which a product is developed from its inception to its release. Configuration Management describes in detail the configuration management software and procedures instituted at the company to manage changes to its products. These two areas are very important for Common Criteria because they are a good indication of the level of care given by a vendor in the development of its product.

[Please note that terms “Lifecycle Support” and “Configuration Management” are used somewhat differently in the Common Criteria context than in the offering and provisioning of Oracle’s own Support Services, where those terms refer to the provision of specific types of support services to our customers. For more information, see http://www.oracle.com/support/index.html]

Both of these areas of the development process are very well established for all Oracle-developed products and based around Oracle’s development and integration management systems. My group has developed standard product evaluation documents covering both Lifecycle and Configuration for Oracle.

With newly acquired product lines, these standard documents will not apply and their equivalent for the acquired product lines usually do not exist. In my experience, few acquired companies previously had development practices and procedures as sophisticated as Oracle’s as they relate to the documentation required for a Common Criteria evaluation. Therefore it is necessary to establish what Lifecycle and Configuration methods have been used with the product prior to its acquisition by Oracle, and then document this afresh. In addition, in the case of the Lifecycle document, the degree to which the product has been assimilated into the Oracle bug fix lifecycle since its acquisition is one feature that has to be assessed.

A further product evaluation requirement is the Test Plan and Procedures document. This is needed to demonstrate that the security functions of the product have been thoroughly tested. Again, Oracle’s development system would provide the core of the testing for an Oracle developed product, but with an acquired product this will not be the case. In the case of many newly acquired companies, testing was manual or semi-automated and these activities needs now be individually documented, once again at extra time and cost for Oracle.

Regardless of the procedural and documentational gaps that may exist between the newly acquired company and Oracle, the knowledge and experience of the staff that join Oracle with the acquisition is essential to successfully understanding the product process, integrating that product process with Oracle conventions, and completing the product evaluation on time and budget.

With all these challenges, one may ask why Oracle goes to the trouble of submitting newly acquired product lines to security evaluations, and more importantly, how customers benefit from this extensive effort. Perhaps the greatest benefits of the Common Criteria evaluation for customers of products that were recently acquired by Oracle and submitted for evaluation is the increased scrutiny that Oracle brings to the source code and development practices of newly acquired products. A Common Criteria certification requires that extensive documentation about many aspects of product design and development be independently reviewed so that users can be assured of the inherent security quality of the software. For customers, these security certifications should be evidence of demonstrable security functions and attributes in the product.

Oracle now has over 30 security evaluations successfully completed and the Security Evaluations Team has more products currently undergoing Common Criteria evaluation. This demonstrates the focus that Oracle has given to security in its products.

More information on Oracle security evaluations can be found at http://www.oracle.com/technology/deploy/security/seceval/index.html

Today, the Independent Oracle User Group (IOUG) released a report detailing the results of a survey designed in collaboration with Oracle Global Product Security. The purpose of the survey was to collect information about some of the security practices of Oracle customers, particularly around the Critical Patch Update (CPU).

In a previous blog entry, I discussed why the IOUG and Oracle conducted the survey. Our intent was to develop a better understanding of customers’ security patching behavior, and collect feedback and recommendations for the Security Customer Advisory Council, an advisory committee that provides recommendations to Oracle about its roadmap for security products and processes (such as the CPU).

The survey yielded more than 150 responses from as many different organizations. We
wanted to hear from the people whose business function was related to security patching in their Oracle environment, so information was collected from DBAs, systems administrators, and managers who are intimately involved with the deployment of CPUs or patch sets.

In my opinion, the two most interesting areas of the survey were related to the relatively low number of organizations that mandate systematic patching of their Oracle systems and the influences reported by respondents that would cause their organization to be more consistent in its patching practices.

The survey found that a relatively low number of organizations require systematic application of security patches when they are released by Oracle. Only about one quarter of respondents stated that their organizations required that Critical Patch Updates be applied systematically across the entire applicable environment when CPUs are released by Oracle.

On the other hand of the spectrum, almost one fifth of all respondents reported that their organizations actually did not have specific requirements for the application of any vendor’s security patches. And another eleven percent of the respondents reported that, when they had patching policies, they did not extend to Oracle patches.

However, over one third of all respondents (36%) indicated that their organizations had patching policies in place and that these policies required that the application of the Oracle security patches be justified. In such instances, not surprisingly, respondents reported that their organizations seemed to favor a risk analysis as opposed to a cost/benefit analysis in order to justify the patching effort.

Another interesting aspect of the survey was related to the factors reported by the respondents that would cause their organization to be more proactive in their application of security patches.

Respondents were asked to select up to three things that could cause them to apply Critical Patch Updates more quickly and consistently. The survey found that the existence of organizational policies is as important to consistent CPU application as the availability of tools or documentation to test CPUs before their deployment. Requirements expressed by the security staff, mandates from security audits or born from an executive decision accounted for over one third (36%) of the total number of answers. Availability of enhanced tools and documentation accounted for another one third (34%). Finally, “massive malware outbreak” was cited in sixteen percent of the responses.

In my opinion, this survey highlights the importance of security policies for patching business-critical systems. Many respondents indicated that systematic patching policies typically extended only to desktop environments. They also reported reticence to patching servers that otherwise perform in a predictable manner. Organizations are reluctant to mandate the application of patches onto business-critical servers because of the cost and time associated with such an effort. Furthermore, many administrators have reported fear of “breaking” something and thus causing downtime. In addition, the feeling that security controls provided outside of the affected systems (NAC systems, DMZ configuration, etc.) provided enough mitigation are significant factors influencing organizations’ patching behavior on Oracle systems.

The findings of the survey were reported to the Security Customer Advisory Council (SCAC). SCAC members themselves took the survey before the findings were presented, and their feedback was consistent with the feedback from the IOUG members. As a result of this survey, Oracle and IOUG are planning to explore two areas to help customers with their security patches effort. In the next few months, Oracle and IOUG plan to develop activities to promote the adoption of documented patching policies, and educate customers about the availability of tools, such as the new My Oracle Support Portal, which can help customers with their patching and secure configuration efforts. In addition, Oracle plans to explore ways to enhance the Critical patch Update documentation to help customers develop time-effective testing procedures for the CPUs before their deployment. All these activities are likely to be topics for future blog entries.

For more information about this IOUG Security Assurance survey:
* The survey report is located at http://enterprisesig.oracle.ioug.org/
* A previous blog entry discussing the objectives of the survey is located at http://blogs.oracle.com/security/2008/07/ioug_security_survey_.html
* Michelle Malcher comments on this survey at http://michelledbaunleashed.blogspot.com/

Various BEA operations and processes are now integrated with those at Oracle. Soon after the acquisition, in July of 2008, the BEA products transitioned to the Oracle Critical Patch Update (CPU) program. In the past, BEA security advisories were released about every 3-6 months and sometimes on an as-needed basis without a pre-published schedule as opposed to the CPU schedule, which is published one year in advance. I believe the predictability provided by the CPU will benefit BEA customers. Customers can now plan ahead to incorporate these updates in their release and upgrade schedules, helping to minimizing impact on their production schedule.

In addition, the profiles of customers who subscribed to receiving targeted communications as part of the BEA security outreach program have been transitioned to Oracle.com. These customers will continue to receive the communications they were subscribed to. Most of the subscribers have been sent an email informing them of this change and received instructions on how to login to their new Oracle.com account. However, profile migration is still pending for the countries where the legal entity change has not completed from BEA into Oracle.

Finally, the transition from the BEA systems to the My Oracle Support portal, formerly known as MetaLink, was completed on February 2nd 2009. As a result, support for the BEA products is now available through the Oracle Global Customer Support (GCS) systems. Customers attempting to navigate to the BEA eSupport (i.e. support.bea.com) will be redirected to the site dedicated to information about the BEA acquisition. As a result of this transition BEA customers will be able to use self-service functionality, such as ARU/Metalink, to download patches for all BEA products. Finally, BEA security advisories that were hosted on support.bea.com have been migrated to http://www.oracle.com/technology/deploy/security/beaarchive.html and BEA security advisory fixes are available through the My Oracle Support portal.

My experience with this transition has been positive. I feel that the integrated Oracle and BEA teams have quickly made a significant effort to align many of the BEA processes and tools. Of course, this is an ongoing effort!

In a Future Blog, I will provide more information regarding the updates in the security advisory policies for the BEA products resulting from the integration with Oracle.

On January 12th, SANS issued a report detailing the Top 25 Most Dangerous Programming Errors. I, as the Oracle representative, was one of many contributors to this paper. In this BLOG I wanted to discuss some of the reasons why a top 25 list of most dangerous programming errors is important to the software development industry.

First, a summary of the paper. The SANS paper contains a list of top 25 programming errors, or really categories of errors, that have resulted in security vulnerabilities where security vulnerabilities are program defects that could allow attackers to read, create, delete or modify data without proper authorization, or to cause a denial of service to resources that provide computing services. These categories were determined by a long list of collaborators including private consultants, members of governmental and security organizations and members of industry like me.

Each of the SANS programing errors is described, its consequences noted and methods to prevent and mitigate each error are provided.

An illustrative example from the SANS list is "Improper Input Validation," which is the class of errors resulting from a lack of validation of input parameter to functions, procedure and applications. A good example from this class is the "buffer overflow" error, where the size of an input parameter exceeds the size of the buffer that was allocated to contain it. Buffer overflows can often be exploited to allow takeover of the application or even the host system. I believe that Improper Input Validation is the leading cause of security vulnerabilities in software.

Why is this list important?

One reason is that it alerts programmers to common programming errors that lead to security vulnerabilities. Just by knowing about such problems, a programmer is more likely to avoid them. The list also includes both "tactical" and architectural advices regarding how to prevent or mitigate such problems. For example, the use of input validation frameworks, such as Struts, is an architectural recommendation to avoid "Improper Input Validation" errors. For tactical advice, the SANS document recommends that programmers avoid using "blacklist" validation of input since common mistakes in defining blacklists can lead to not detecting malicious input. In addition, the SANS list provides mitigation advice. For example, it is recommended that "least privileges" be used so that if a compromise occurs, the potential damage is limited. Of course this advice should be heeded when developing software for any type of application.

Thus, the list of the top 25 programming errors can be used to directly improve the security of programs by providing programmers with an understanding of common vulnerabilities, by setting forth both architectural and tactical recommendations for avoiding vulnerabilities due to these errors, and by recommending methods of mitigating successful exploits of such vulnerabilities. The SANS List may have other effects as well. For example, new publicly available tools for finding, mitigating and avoiding such errors may be developed for general use as a result of this list. Also, people who audit or review programs may use the top 25 list to help them assess software products.

I expect that the SANS top 25 list of programming errors will have a significant effect on the software industry. Software development organizations that review this list and quickly take appropriate action to reduce and eliminate the errors described in the list should have a considerable advantage over competitors that do not.

For More Information:
The SANS Top 25 Most Dangerous Coding Errors is available at http://www.sans.org/top25errors/

Today Oracle released the January 2009 Critical Patch Update (CPUJan2009).

The Critical Patch Update (CPU) includes fixes for 41 new security vulnerabilities across several product families, including: Oracle Database Server, Oracle Times Ten, Oracle Secure Backup, Oracle Enterprise Manager, Oracle Application Server, Oracle Collaboration Suite, Oracle E-Business Suite, Oracle PeopleSoft Enterprise, Oracle JDEdwards Enterprise One, and Oracle WebLogic.

Ten of the 41 vulnerabilies affect Oracle Database Server, and none of the ten are remotely exploitable without authentication. Two of the Oracle Database Server fixes are for the SQL*Plus Windows GUI; as such they impact client-only installations.

This Critical Patch Update also addresses nine vulnerabilities in Oracle Secure Backup, a stand-alone solution for centrally managing backup tapes. Four of the Oracle Secure Backup vulnerabilities were reported on the CPU documentation with a CVSS Base Score of 10.0. Note however that this CVSS Base Score of 10.0 only affects the Windows platform. For Linux, Unix, and other platforms, these vulnerabilities would yield a relatively lower severity score of 7.5. This differentiation in CVSS Base Scores is due to operating system differences, which allow a successful exploitation of one of the vulnerabilities to result in a take over of the operating system in a Windows environment, but not on other platforms (Linux, Unix, etc.). A 10.0 CVSS Base Score denotes instances where a complete takeover of the underlying platform where a compromised application executes is possible (causing an attacker to “own” the targeted machine). A 7.5 CVSS Base Score denotes instances where the compromise is somewhat limited to the compromised application. Finally, note that none of the vulnerabilities fixed in this Critical Patch Update affect the most recent release of Oracle Secure Backup (10.2.0.3).

This Critical Patch Update also addresses five new vulnerabilities in the Oracle Weblogic suite of products. One of these five vulnerabilities also received a CVSS Base Score of 10.0, and it affects the WebLogic Server Plugins for Apache, Sun and IIS web servers. The WebLogic plugin component has already been the subject of a couple of serious vulnerabilities. Two CVSS 10.0 vulnerabilities were recently fixed in this component: one with the most recent October 2008 Critical Patch Update and the other with an out of cycle Security Alert in August 2008. The discovery of these vulnerabilities has resulted in bringing a lot of attention on the WebLogic Server Plugin, and as a result, this component has been going through significant review, including an in-depth review by our ethical hacking team (a.k.a. “White Hat Hackers”), and of course various communications with Security Researchers who brought some of these issues to light. Finally, note that the fixes for the WebLogic plugins are cumulative, in other words, the most recent fix includes all previously released fixes.

In many ways, the remediation of severe vulnerabilities in the context of today’s Critical Patch Update with Oracle Secure Backup and the Oracle Weblogic Server plugins highlight the effectiveness of an ongoing Security Assurance effort, which involves the entire development organization, as well as internal security teams, and trusted Security Researchers. When looking back at the Critical Patch Updates, since January 2005, we can see that the most mature product lines (in term of their inclusion in Oracle Software Security Assurance programs, including the Critical Patch Update) are experiencing less critical vulnerabilities, and even, in some instances, a decrease in the number of vulnerabilities typically fixed in each Critical Patch Update. (Note that the size of the Critical Patch Update remains somewhat constant despite the continuously growing number of products that have joined the CPU process as a result of newly acquired product lines.) Of course, security professionals can never fully rest on their laurels because such progress can always be negated by the discovery of new attack methods, which would result in a “spike” in the number of fixes issued to address them.

As usual, I try to highlight the most notable content of the current Critical Patch Update in this blog. However, as indicated at the beginning of this blog, the current Critical Patch Update also includes new fixes for other product lines (Oracle EBusiness Suite, Oracle TimesTen, Oracle Enterprise Manager, Oracle Application Server, Oracle Collaboration Suite, Oracle E-Business Suite, Oracle PeopleSoft Enterprise, and Oracle JDEdwards Enterprise One). Customers should therefore refer to the CPU Release Documentation to find more information about these patches. Oracle strongly encourages all customers to apply this CPU as soon as possible.

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

Oracle recently launched its new Web support portal My Oracle Support (previously known as MetaLink). More than just providing a slick interface, the new site also delivers additional benefits to customers, including a personalized support experience, resulting in faster time–to-resolution of technical issues.

Some of the most significant benefits of the new My Oracle Support portal are the integrated configuration management capabilities – formerly known as Software Configuration Manager – which are provided through the use of Oracle Configuration Manager. Now bundled with most new Oracle product releases and utilities like OPatch, Oracle Configuration Manager can automatically gather the configuration information of Oracle product installs, and upload this information onto Oracle’s support systems. The configuration information being collected by Oracle Configuration Manager includes:
• Installed patches
• Deployment platforms, dates, versions, and type
• Deployed components and applications
• Content of configuration files
• Information about network configurations

Note that the information collected by Oracle Configuration Manager is limited to configuration information. The utility does not collect sensitive data such as actual customer data (that is any data other than configuration information, including actual applications or database transactions), password hash values, log on events, etc. My Oracle Support note 728985.1 provides a list of all the data collected by Oracle Configuration Manager.

Once collected, this configuration data can be used to populate the customer’s private My Oracle Support dashboard. The dashboard will then display a detailed list of systems in the enterprise, not only allowing the customer to view their configuration settings, but also enabling change history tracking that will identify any changes made to system configurations over time. Furthermore, the uploaded data allows Oracle Support to provide customized information about the overall health of the customer’s systems (including information about release and patch levels currently installed in the environment) and recommendations to ensure that each system operates in peak condition.

Note that customers need to specifically enable Oracle Configuration Manager in order for it to start collecting configuration information and securely sending this information to Oracle Support. Furthermore, if a customer’s security policies prohibit the automatic sending of configuration information outside of the organization, Oracle Configuration Manager can be configured to work in a “disconnected mode”, allowing the customer’s systems and security administrators the ability to review the information prior to it being sent out to Oracle Support.

A great feature provided by Oracle Configuration Manager to My Oracle Support users is the ability to quickly create Service Requests with accurate and complete system configuration information attached. In other words, customers can use My Oracle Support to see recent changes that could have been made to their environment to troubleshoot technical issues, and if unable to solve the problem themselves, customers can then open a Service Request with Oracle that will come pre-populated with the configuration information that is typically required by Oracle support in order to initiate a service ticket.

The combination of Oracle Configuration Manager with the My Oracle Support portal provides Oracle customers with tremendous benefits. Oracle Configuration Manager is available at no additional charge to current Oracle Support customers. My Oracle Support access is included with the annual paid Oracle Premier Support subscription. This combination can provide customers with a complete view of the configuration of their Oracle environment and with environment-specific recommendations in order to yield maximum benefits from their Oracle systems while maintaining a positive security posture. The various reports available in the My Oracle Support portal can help customers prevent outages, troubleshoot systems, and identify trends across their systems.

A short video explaining the benefits of Oracle Configuration Manager is available online. In addition, the Collector tab on My Oracle Support is dedicated to explaining how to use Oracle Configuration Manager and gaining the most value out of My Oracle Support. In order to get started, just make sure that the Oracle Configuration Manager which was installed with your Oracle product has been configured and is running. You can also download the software from My Oracle Support if your recent product installs didn’t come bundled with Oracle Configuration Manager.

I am often asked what it takes to write secure code. In my experience, developers generally cannot prevent introducing security flaws in their code if they don’t know what to watch out for. It is also my experience that people generally, and developers in particular, want to do the right thing - but they need to know what the right thing is.

For the purpose of this blog, we will not go into why software security is important. That is pretty much common knowledge by now. However, there is a significant paradox in that writing secure code is not commonly taught at the Universities as part of Computer Science curriculum. In a previous blog entry, Mary Ann Davidson expressed the difficulties faced by software vendors such as Oracle to find developers with secure development expertise. Universities typically do not teach secure coding to their IT grads.

Even if secure coding skills were taught in schools, there is already a large pool of software professionals who have been writing code for some time and would not be security aware unless their company rolled out secure coding practices training. Thus, until the need for security training has been met externally by the education system for some time, it falls on software vendors to train their staff. The cold, hard fact is that coding responsibly means knowing how.

At Oracle, mandatory security training has been in place for several years and is fully supported by executive management. The majority of development staff across Oracle has completed the training. New hires, or staff joining Oracle via acquisitions, are automatically notified of the mandatory security training requirement, as applicable.

In my experience, I have noticed that some developers expect their product to be used in the way in which it was intended; thinking “Why would anyone do anything different?” Well, for one, software users (customers) are typically not involved in the design and development phases of the product, and as such, the use cases anticipated by development may be somewhat different from how the software is used in “real life”. Security researchers and malicious hackers will not feel bound to use the product in the way intended by developers: they will explore avenues to break in, in ways that the developer did not foresee. For example, a malicious attacker may attempt to inject SQL commands hoping to demonstrate that the developers didn’t provide for sufficient input validation (best case scenario), or, in a worst case scenario, the attacker may try to gain access to the data or gain additional database privileges. In addition, QA testers are inherently focused on ensuring that the product works as it is supposed to whereby in many instances, security researchers and malicious hackers will do exactly the opposite with “negative” or “destructive” testing. Actually, in many ways, the job of the security researcher is to explore the boundaries outside of the normal use of software. An important aspect of security training is to help developers become security aware by teaching them to “think like a hacker”.

With appropriate training in secure coding principles development staff will be better prepared to guard against software vulnerabilities and understand that users will not always adhere to use cases and recommended “best practices”. In many ways, security trained developers become aware of the unintended consequences that may result from choosing the easy way to solve a particular coding problem and leaving their code exposed to exploits. Secure development training helps prepare developers and QA staff to recognize potential security risks in code they encounter in the larger stack. A desired result of security training is seeing development teams log security bugs against their own code because they are now aware of the existence of such bugs. With appropriate training every team member becomes a security advocate in his/her own right, an additional gatekeeper who helps contribute to the increased quality of the code produced by his/her own team.

An additional benefit to secure coding training is helping to increase the overall quality of the code produced: most often security bugs are really common coding errors, but with far more serious consequences than “regular” bugs. We can generally see that secure coding training results in helping developers not only avoid potential security flaws, but also prevent other kinds of bugs as well.

Just as security training is essential for developers, it is equally essential that senior development managers are trained to help ensure that they make the right decision when allocating resources and especially to resist “shortcuts” when facing time pressure: a secure coding solution may take longer than an easier, yet insecure, one and it is not uncommon that fixing a security bug can results in introducing delays in the release schedule.

I am often asked at conferences what was the key success factor in successfully rolling out secure coding training to an organization as large and diverse as Oracle. In my mind, and without a doubt, I think that executive management buy-in is the most critical success factor. The benefits of secure coding training must be understood and endorsed from the top down. Executive management must fully support and mandate the application of the secure coding standards. Senior development managers must be trained to be security aware and be willing to sponsor the adoption of the secure coding practices in their teams. The development staff must become aware of these standards, be security trained, and ultimately embrace secure coding principles as a value-add to their work product.

Oracle sees much value in security training. The cost of resource time spent on training is small when compared to the cost of testing and installing just one security fix. Security training does change developer behavior: quality of code improves along with the security posture provided by the software. The most rewarding aspect of my job is seeing feedback from developers such as: “The course is invaluable. Now that our group has completed the training we think more about security when coding.”

Oracle today released the October 2008 Critical Patch Update (CPUOct2008).

The Critical Patch Update (CPU) includes fixes for 36 new security vulnerabilities across a large number of products: Oracle Database Server, Oracle Application Server, Oracle E-Business Suite, Oracle PeopleSoft Enterprise, Oracle JDEdwards Enterprise One, and Oracle WebLogic. Fifteen of these 36 vulnerabilies affect Oracle Database Server. One of the Database Server vulnerabilities is remotely exploitable without authentication. Note also that three of the Application Server vulnerabilities affect client-only installations. Finally, the CVSS Base Scores for the vulnerabilities fixed in this CPU (an indication of their relative severity) range between 1.0 and 10.00 (on a scale of 10.0). See our previous blog entry series for more information about CVSS and an explanation of the CVSS base scoring formula.

The most severe vulnerability fixed in this CPU (CVE-2008-4008 with a CVSS Base Score of 10.0) affects the Apache plugin for Oracle WebLogic Server (formerly BEA WebLogic). This is not vulnerability CVE-2008-3257, which was fixed in a previously issued Security Alert, though a fix for this vulnerability is also included in this CPU (fixes for BEA WebLogic plugins are cumulative). Vulnerability CVE-2008-4008 is a new vulnerability which was reported to Oracle shortly before the creation of this CPU. A fix for this vulnerability was therefore included in this CPU in order to provide a prompt resolution and to help ensure that the security posture of WebLogic customers is maintained.

Oracle strongly encourages all customers to apply this CPU as soon as possible.

For More Information:

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

Security Advisories and Notifications for the Oracle BEA products is located at https://support.bea.com/application_content/product_portlets/securityadvisories/index.html

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

The CVE web site is located at: http://cve.mitre.org/

I recently attended WikiSym2008. This conference was a great place to meet up with people interested in collaborative working and related technologies. I gave a presentation to share a recent experience my team and I had while reviewing Wiki extensions and plugins for security vulnerabilities.

In addition to providing a tool for collaboratively creating web content, Wikis are increasingly being used as a framework on which to build small applications. Many Wiki engines already provide limited support for this capability through extensions or plug-ins. These extensions will typically let developers use the Wiki engine in ways that were never envisaged by the original developers. Writing extensions is usually quite straightforward and generally gives a lot of freedom and access to the Wiki engine’s internal state and hence access to everything the Wiki engine has access to.

No matter how much care and attention the Wiki engine developers have put into making the wiki software as robust as they reasonably can, all these efforts may be undermined by any extension that has not been developed with the same level of care. The ease with which Wiki extensions can be developed means that anyone can develop and publish such extensions. Unfortunately, a large proportion of software developers are not properly educated about secure coding practices (See Mary Ann Davidson’s blog entry on this topic).

When we wanted to make more extensive use of extensions on one of our internal wikis, we performed some security reviews. It shouldn’t have been much of a surprise that we found quite a high proportion of the Wiki extensions we examined included potential security vulnerabilities. In most cases, these vulnerabilities were straightforward cross-site scripting or HTML injections. But, we also saw some other interesting possibilities like log injection attacks and inappropriate trust in 3rd party data.

[The work of the Ethical Hacking Team is not just about finding security bugs. The more interesting aspect of my job is to learn from these bugs, characterize them, understand why they happened, and establish methods for rapidly finding similar bugs. The most gratifying aspect of my job is helping development and testing organizations understand the security bugs, how to find them and fix them (and help ensure they don’t come back).]

After we found three or four vulnerabilities in a small set of extensions, we had a good characterization of what generally made these extensions vulnerable and what to look for in the code. We were then able to promptly review a large number (around 100) of extensions and quickly found that more than 20 of them were vulnerable. We reported these issues back to their respective developers (or Wiki engine maintainers) and, as a result, most of them have been fixed or withdrawn.

Even when educational institutions start to pay more attention to the security aspect of software development in their courses, it will be a long time before we can expect developers to consistently produce reasonably secure code. By analogy, I fasten my seat belt whenever I get in a car. Each time I get in a car I don't do a threat assessment and decide that a second to fasten the seatbelt is worth the effort compared to the risk of diving through the windscreen, or of being stopped and fined. I do it as a habit: a habit formed before it was a legal requirement and before I was able to appreciate the damage that flying through the windscreen might do to my future. Reviewing Wiki extensions for security vulnerabilities further highlighted that developers needed to form the habit of using bind variables in SQL queries, HTML/XML encoding output, etc.

Now, after this brief excursion into finding vulnerabilities in community-developed code, it's back to Oracle products for me.

For more information, see http://www.wikisym.org/ws2008/index.php/Security_of_Community_Developed_and_3rd_party_Wiki_Plug-ins

Oracle today issued an updated Security Alert related to the previously reported vulnerability CVE-2008-3257. The purpose of this updated Security Alert is to let WebLogic customers know about the immediate availability of the fixes on all supported platform and version combinations.

As we reported a week ago, Oracle felt that the nature of this vulnerability, which affected the Apache plugin for Oracle WebLogic, along with its publication in various public forums, and the availability of exploit code, warranted the issuance of an out-of-cycle patch. While this patch will also be included in the upcoming Critical Patch Update (scheduled for October 14, 2008), we recommend that customers apply the current patch as soon as possible, even if they have implemented the recommended workarounds.

For More Information:

The Security Alert for this vulnerability is posted on http://www.oracle.com/technology/deploy/security/alerts/alert_cve2008-3257.html

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

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

Oracle today issued a Security Alert for a vulnerability affecting the Apache plugin for Oracle WebLogic (formerly BEA WebLogic). It is the first Security Alert since the introduction of the Critical Patch Update process in January 2005. Issuing this alert was required because the vulnerability and associated exploit codes have been posted in various public forums. This vulnerability has received the CVE identifier CVE-2008-3257. The CVSS score for this vulnerability is 10.0. It is remotely exploitable without authentication (i.e. it may be exploited over the network without the need for a username and password), and it can result in compromising the confidentiality, integrity, and availability of the targeted system.

When Oracle became aware of this issue, our security and development teams worked diligently to develop an effective workaround to prevent a successful exploitation of the vulnerability. Detailed instructions for this workaround have been posted on the eSupport site, and Oracle has already issued a Security Alert to all WebLogic customers to let them know about this workaround. In addition, Oracle will also issue an out-of-cycle security patch for this vulnerability as soon as the fix has been produced for all supported version-platform combinations. We expect this fix to be ready very soon, and we will issue an updated Security Alert to let customers know about its availability. In the meanwhile, we recommend that all customers implement the recommended workaround.

Unfortunately, the person(s) who published this vulnerability and associated exploit codes did not contact Oracle before publicly disclosing this issue. This means that the vulnerability was made public before providing Oracle an opportunity to develop an appropriate fix for this issue and notify its customers. In addition, the vulnerability was made public shortly after the publication of the July 15th Critical Patch Update, therefore prompting Oracle to issue an out of cycle security update.

For More Information:

Workaround instructions are posted on https://support.bea.com/application_content/product_portlets/securityadvisories/2793.html

The Security Alert for this vulnerability is posted on http://www.oracle.com/technology/deploy/security/alerts/alert_cve2008-3257.html

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

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