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

Oracle today released the July 2008 Critical Patch Update (CPUJul2008). While this is Oracle’s fifteenth Critical Patch Update (CPU), and personally, my ninth CPU (I joined Oracle in time for CPUJul2006), I am still impressed with the dedication and great talent of everyone who is involved with the production of each CPU. Over the years, Oracle has introduced many enhancements to the CPU and successfully extended its scope to many products added via acquisition.

Today’s CPU is characterized by two significant developments: the adoption of the Common Vulnerabilities and Exposure (CVE) numbering scheme, and the inclusion of the BEA, TimesTen, and Hyperion product lines in the Critical Patch Update. But more on these topics later! Let’s first have a look at the content of this CPU.

Today’s CPU include fixes for 45 new security vulnerabilities across a wide range of products: Oracle Database Server, Oracle Application Server (including Hyperion Peformance Suite), Oracle TimesTen, Oracle Enteprise Manager, Oracle EBusiness Suite, Oracle PeopleSoft Enterprise, and Oracle WebLogic Server. Eleven of these vulnerabilies affect Oracle Database Server, and none of these Database Server vulnerabilities are remotely exploitable without authentication. The criticality for these 45 new vulnerabilities fixed in the CPU range between the CVSS base scores of 1.5 to 6.8 (on a scale of 10). See our previous blog entry series for more information about CVSS and an explanation of the CVSS base scoring formula. Finally note that none of these 45 fixes affect client-only installations.

As mentioned earlier in this blog, this CPU is also characterized by the adoption of the Common Vulnerabilities and Exposure (CVE) system. As explained on the CVE program web site, “CVE Identifiers (also called "CVE-IDs," "CVE names," "CVE numbers," and "CVEs") are unique, common identifiers for publicly known information security vulnerabilities.” Starting with the July 2008 Critical Patch Update, Oracle will use these CVE identifiers to identify the vulnerabilities fixed in each new CPU, and will no longer use the proprietary numbering convention that was previously used in the CPU risk matrices. As a result, each new vulnerability fixed in the CPU will be assigned a unique CVE Identifier. This change was made possible because Oracle became a “Candidate Naming Authority” under the CVE program. Note that while the CPU documentation is the only authoritative source of information about vulnerabilities in Oracle products, and as such should remain the primary source of information about such vulnerabilities, the use of unique CVE identifiers should result in simplifying how Oracle vulnerabilities are identified in external security reports such as those produced by security researchers and vulnerability management systems. The use in the CPU documentation of CVE identifiers, along with the publication of the Common Vulnerability Scoring System (CVSS) base scores, is further evidence of Oracle’s customer focus in its vulnerability disclosure practices.

Finally, this Critical Patch Update also marks the inclusion of the BEA, TimesTen, and Hyperion product lines in the CPU process.

The inclusion of BEA in the CPU was particularly rapid because of the similarities that existed between the current CPU process at Oracle and the patching procedures previously in use at BEA. Furthermore, all involved in the CPU process have grown skilled with dealing with newly acquired companies, products (and people). The skillset with which Oracle successfully integrates acquisitions extends to all involved with Oracle Software Security Assurance.

Today, the CPU process provides a cohesive program for the patching of hundreds of Oracle products across many various platforms. Developed with customers in mind, the Critical Patch Update provides a predictable patching schedule that is designed to fall outside of typical blackout dates experienced by most customers (such as end of fiscal year, end of calendar year, etc.) As a result of this predictability (CPUs are issued on the Tuesday closest to the 15th of the months of January, April, July, and October), Oracle customers can leverage normal maintenance windows for deploying security updates to Oracle products, thus reducing interruptions to their production environment.

For More Information:

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

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

The greatest external factor influencing Oracle Software Security Assurance is the feedback we receive from customers. While members of Oracle’s Global Product Security team have daily interactions with customers, security researchers, or industry analysts, the most exhaustive channel for customer feedback is the Security Customer Advisory Council that is being managed by the Program Management Office of the Global Product Security organization.

The Security Customer Advisory Council (SCAC for short) is comprised of customers from around the world and representing various industries. Moreover, SCAC members are collectively using most if not all Oracle products. The SCAC meets at least once a year to discuss emerging security topics, Oracle’s security strategy, and Oracle Software Security Assurance programs, including the Critical Patch Update and related activities. For example, the recommendations of the SCAC have previously led Oracle to adopt the Common Vulnerability Scoring System (CVSS) as a standard way to rate the severity of the vulnerabilities fixed in the CPU and to issue pre-release CPU announcements (these are issued on the Critical Patch Updates and Security Alerts page the Thursday before the CPU due date).

Most recently, the Independent Oracle User Group (IOUG) joined the Security Customer Advisory Council. This initiative was launched by the Enterprise Best Practices SIG under the leadership of Michelle Malcher, the SIG president. As a component to this initiative, Oracle and IOUG also produced a number of security training webcasts. These webcasts are available online on the Enterprise Best Practices SIG Download Page. The two most recent webcasts were particularly popular! In March, Daniel Wong (Director of Engineering the Database Security group) presented the security enhancements in Oracle Database Server 11g. Last month, Jenny Tsai-Smith (Senior Director in Curriculum Development) and Mark Fallon (Director of Software Development) recorded a webcast on how to best prevent SQL Injection attacks.

In preparation for the next Security Customer Advisory Council (to be held in October), the Enterprise Best Practices SIG of IOUG posted a security survey to try to gather information about the current security practices of its members, particularly around the application of the Critical Patch Updates and Patch Sets and to gather recommendations from members about possible process improvements that Oracle could bring to further enhance Oracle Software Security Assurance activities. Michelle and I recorded a webcast that discuss the objectives of the survey. We went through two iterations of the survey, further fine-tuning it, to come up with a shorter, simpler survey, that drill down to areas that are most likely to yield feedback from Oracle users (the current survey is titled “OSSA Security Survey II” on the IOUG web site).

We would like to encourage all Oracle users to take this survey!!! (Remember to select “OSSA Security Survey II”). A Free Associate Membership to IOUG may be required to take the survey, but completing this form should take no more than five minutes. Completing the survey itself should take no more that ten minutes (unless you decide to take advantage of the free form question at the end of the survey by writing an extensive set of recommendations for Oracle).

Information about the Security Survey:
The survey is located at http://survey.ioug.org . (Please select “OSSA Survey II”.)
The webcast explaining the objectives of the survey is located at: http://www.ioug.org/networking/SIGs/SurveyPodcastrev.mp3

Information about Oracle Software Security Assurance:
For more information about the Security Customer Advisory Council, you can e-mail: securityCAC_ww@ORACLE.COM

Information about IOUG:
IOUG web site is located at http://www.ioug.org.
For information about IOUG membership, see the IOUG membership page.
Recorded IOUG webcasts can be found at http://www.ioug.org/networking/SIGs/Archived_SIG_Webcasts.cfm

This is John Heimann, Sr. Director, Oracle Global Product Security (GPS), again.  In my role as manager of the GPS Security Program Management team, one of my primary concerns is ensuring that Oracle�s products effectively protect sensitive customer data.  More specifically, the Security Program Management team helps to ensure that Oracle product development groups consistently apply secure coding standards, tools and processes that help reduce the likelihood of exploitable security vulnerabilities in our products.  Oracle product development groups have designed and implemented many security features that customers can use to protect sensitive information.  My team works with product groups to help ensure that Oracle developers avoid security flaws that could allow attackers to bypass these security features and gain access to sensitive data.

In recent years, there have been a number of high profile breaches of information systems that process sensitive information associated with thousands or even millions of people. When Oracle GPS becomes aware of breaches of information systems processing sensitive data, we typically investigate the causes of the breaches.  Even if the breached information system did not include any Oracle technology, analyzing root causes of a breach can allow us to help improve the design of our products, avoid certain classes of vulnerabilities, or improve the security guidance we offer to customers. 

There are cases where understanding why a serious data breach was so serious require extending the breach analysis beyond the boundary of the information system. In those cases, the analysis includes how the people and systems outside the breached system use the information that was revealed.  Sometimes, the analysis indicates that certain categories of data considered �sensitive� or �private� when they were defined - often in a pre-internet, or even pre-computer, era - are now used in ways that are fundamentally insecure.  The fact that those types of data are now processed by internetworked computer systems simply highlights that insecurity, and makes exploitation of it easier. 

As a concrete example, suppose I told you that you are required to use a system that is responsible for managing your personal identity, tax history, past credit records, ability to get future credit, and other important functions in your daily life.  You will be issued a unique password to access that system, and you can NEVER change it.   Contrary to typical password best practices, the password has well-known internal structure that may make components of it predictable. Moreover, you are required to give that password to banks, credit companies, utilities, the US Internal Revenue Service and other government agencies, tax preparers and accountants, and every employer you have ever worked for.  Would you agree to use such a system?   You probably would not, but that's exactly what we in the US are required to do with our social security numbers (SSNs).  We pretend that SSNs are "private" information but given the number of people to whom we disclose SSNs, they should not be considered private.

A similar situation exists with credit card numbers. If I know your credit card number and date of card expiration, I can make purchases by phone or on the Internet that will be charged to your credit card account. You can change a credit card number on a time scale of months or years - by canceling the card and applying for a new one - but on a short term time scale a credit card number is effectively fixed and unchangeable, and you have to reveal it to hundreds of people and computer systems every month.  How would anyone possibly consider that information "secret?�  Note that credit cards now have three digit Card Security Codes (CSCs) printed on the back to protect against fraudulent use of credit card numbers.  Merchants often ask for a CSC when a customer does not present a physical card during a purchase (e.g., when ordering something by phone or on the internet).  Since the CSC number is fixed for the life of a card, can be obtained by any merchant who handles a customer�s physical card, and must be disclosed any time a customer makes an internet or phone purchase, it can�t be considered truly secret either.  We pretend that SSNs and or credit card numbers are �private� or �secret� and have to be protected by elaborate computer security mechanisms, but in fact they have never been truly secret.

The real problem is that our social systems associated with identity and credit allow an attacker with simple knowledge of Joe Blow's SSN or credit card number to masquerade as Joe Blow and perform some privileged function, like making a purchase on Joe's account.  Computers make attacks that were already in existence (like dumpster diving for credit card slips with card numbers, or paystubs with SSNs) much easier, and simply underscore the weakness in the greater system that handles the information, including people and processes as well as computers.

At one point in time, when credit card or SSN data were disclosed to a limited number of human users through manual processes, simply demonstrating knowledge of an SSN or credit card number may have been an acceptably secure means of authentication.  Unfortunately for those of us who still must use SSNs and credit cards, simple knowledge of SSN or credit card number cannot now be considered a secure means of user authentication.  In fact, such practice violates several basic, generally accepted principals for secure authentication.  Among these principals are

• 
  
  data used for authentication purposes must not be widely shared or stored in multiple places


• 
  
  authentication data should not be difficult or impossible to change


• 
  
  authentication is much more secure when it involves something you have, or something you are, in addition to something you know.

Note that the weaknesses associated with SSNs and credit card numbers have been recognized for many years, and in the case of payment card information were one of the reasons for the creation of the Secure Electronic Transcation (SET) protocol in 1996.  The SET protocol never became established because in the late 1990s, the rate of fraud associated with the existing process (simply giving your credit card number to a merchant) didn't justify the added expense and overhead of using SET.  I suspect that over time, as more fraud associated with phone or online credit card sales occurs, people will re-examine the basic problem associated with using static credit card information and consider more sophisticated mechanisms for user authentication in payment transactions.  Similarly, as identity theft becomes more common, I expect we will start to see a more complex mechanism than simple knowledge of a permanent SSN to evolve for authenticating users to potential payees.

Preventing exploitation of information by improving the security of computer systems in which that information is managed is not enough!  In many cases, the information itself, and/or how it is used in social processes that include but are not limited to computer systems, needs to change before that information can be used securely.  Properly planning and documenting business processes, including the definition of the information being maintained in the organization and defining what constitutes appropriate use of the information is required as a pre-requisite to defining a sound IT security strategy.

A number of publications recently reported about a new way to hack Oracle databases.  These articles were in fact referring to a recently published paper by David Litchfield, titled Lateral SQL Injection: A New Class of Vulnerability in Oracle. 

SQL Injections are a very well known class of attacks, which can affect virtually any relational databases when no or insufficient input validation has been implemented.

In simple terms, SQL Injection attacks are designed to leverage improper coding of database-powered applications that, in the absence of proper input validation, allow a malicious attacker to insert string input to an application. In such scenario, an attacker can "inject" or pass on harmful SQL commands, which will then be executed by the back-end database. The consequences of successful SQL Injections can be severe: an attacker could gain access to sensitive data, manipulate database information, and in some instances, change the structure of the database, deny legitimate access to it, or grant unauthorized privileges to himself or to others. Web applications are particularly at risk because -- exposed to the Internet -- they often allow an attacker to perpetrate SQL injection attacks without being authenticated to the targeted database or application.

An important aspect of Oracle Software Security Assurance is sharing security information and recommended practices with customers so that they can optimize their security posture. We recently posted a SQL Injection tutorial online that demonstrates how to properly implement input validation controls and prevent this kind of attacks.

In his paper, David explains that in certain circumstances, SQL Injections can also take place in procedures that are not intended to take user input. Note however, that in such a scenario, setting up the attack requires that the attacker had been previously granted a database account with necessary privileges. David concludes that it is doubtful that this kind of attacks becomes:exploitable in the normal sense.

While some may consider the topic of Lateral SQL Injections as mostly academic, and relevant only for the security researchers community, I think this paper has the merit of further raising the awareness of database administrators and programmers to SQL Injections. SANS and others have flagged this class of attacks as a primary threat for database-driven sites and applications. In my opinion, proper input validation constitutes a required security practice that needs to be extended to all functions and procedures, whether they are expected or not to take user input. Furthermore, as expressed in the SQL Injection training and in the Oracle documentation, bind variables should be used as much as possible.

As discussed above, SQL injection happens when a dynamic SQL statement is constructed from user input. In the case of the attack discussed in David's paper, the dynamic SQL statement is being constructed from data stored in the database. The values are then being converted into character strings based on a template provided by the system. It is this template, as opposed to the stored value, that controls what will be injected.

When bind variables are properly used, the bind variable name is physically part of the SQL statement, but this bind variable is used as a reference to the rendered value. As a result, the rendered value is never interpreted directly as part of the SQL statement; therefore no SQL Injection can take place.

In some instances, like DDL operations where a database object needs to be constructed, Oracle administrators do not have the option of using a bind variable. In this instance, the DBMS_ASSERT package should be used to correctly handle the rendered value, either ENQUOTE_LITERAL when it is going to be used as a literal or ENQUOTE_NAME when it is going to be used as the name of a SQL object.

For more information, see the online tutorial Defending Against SQL Injection Attacks.  Information on Oracle Software Security Assurance is available on Oracle.com. 

Hello, this is Eric Maurice! 

Oracle today released the April 2008 Critical Patch Update (CPUApr2008).  This Critical Patch Update (CPU) addresses a total of 41 vulnerabilities affecting Oracle Database Server, Oracle Application Express, Oracle Application Server, Oracle E-Business Suite, Oracle Enterprise Manager, Oracle PeopleSoft Enterprise, and Oracle Siebel CRM Applications.  Fifteen of these vulnerabilities are specific to Oracle Database Server (an additional two affects Application Express).  Note however that a number of these Database Server vulnerabilities affect optional Database Server components, and only one of these Database Server vulnerabilities can be remotely exploitable without authentication.

While none of the Oracle Database Server fixes requires patching the database client-only installations, this CPU includes one fix for Oracle Application Server client-only installations.  As with the previously released January 2008 CPU, this CPU includes an Application Server client fix to address a vulnerability affecting JInitiator, a web browser extension that enables end users to run Oracle Forms Services applications within their browser.  This vulnerability only affects version 1.3.1.14 and earlier versions of JInitiator.  Just like the previously fixed JInitiator vulnerabilities, this vulnerability has a CVSS score of 9.3 because it could allow an attacker to gain full control of the targeted client (e.g. workstation) at the Operating System level, but it cannot result in a compromise of the server component. 

This fourteenth CPU also marks another milestone!  For the first time, the CPU includes fixes for Oracle�s Siebel CRM Applications.  As a matter of policy, Oracle tries to synchronize the release of the security patches of acquired product lines with the CPUs, and ultimately ensure that new product lines join the CPU process (in the way that PeopleSoft, JD Edwards, and now Siebel have). 

The CPU fixes for Siebel CRM Applications will be cumulative for the product line in which they apply (There are currently four supported product lines).  This will allow customers who have previously skipped security patches to quickly catch up by applying the most current CPU. 

The inclusion of Siebel Enterprise products in the CPU process provides former Siebel customers with a number of benefits.  Under the Siebel model, security fixes were typically included, along with non-security fixes, in the �Fix Packs�.  The most significant vulnerabilities could also be fixed with dedicated ad hoc (unscheduled and non-cumulative) fixes.  The inclusion of Siebel Enterprise products in the CPU process therefore provides customers enhanced visibility to security fixes.  In addition, customers benefit from the predictability of the CPU schedule, thus potentially reducing the cost of security management in their environment.

The Critical Patch Updates and Security Alerts page on Oracle Technology Network provides detailed information about this CPU, as well as previous CPUs and Security Alerts.  Oracle Technology Network also hosts additional information about Oracle�s implementation of the CVSS 2.0 standard and a glossary of the terms used in the Risk Matrices in the CPU Advisory.  The Resource Library on the Oracle Software Security Assurance web site also provides a number of links to useful security resources.

Hi, this is Eric Maurice!  This very short blog to let you know about recently recorded podcasts and webcasts on Oracle Software Security Assurance topics.

We recently recorded a podcast interview with Oracle CSO, Mary Ann Davidson.  In this podcast, Mary Ann discusses the importance of Oracle Software Security Assurance, the role of Oracle�s Global Product Security Group, and some of the changes that were introduced with the Critical Patch Update. 

Oracle and the Enterprise Best Practices Special Interest Group (SIG) of the Independent Oracle User Group recently delivered a one hour webcast introducing Oracle�s secure configuration initiative and discussing the security enhancements in Oracle Database 11g.  In this webcast, Daniel Wong, Director of Engineering for Database Security at Oracle, discusses in technical detail the security changes introduced in the default configuration of Oracle Database Server with 11g.  Such changes affect the default audit settings, authentication and password management, and access control changes to certain UTL packages, etc.  Daniel then provides security recommendations for customers who are looking at upgrading (or have upgraded to) Oracle Database 11g.  A previously recorded webcast providing technical recommendations for securely configuring Oracle databases is also available on the IOUG website under the archived SIG webcasts section. 

Note that a registration to IOUG�s web site may be required to access some of this content (FREE membership to the Enterprise Best Practices SIG is also available here).

For more information:

Mary Ann Davidson�s interview is available here.

IOUG�s webcast on Oracle Database 11g security is available here.

IOUG�s webcast on securely configuring Oracle databases is available here.

Oracle Software Security Assurance Resource Library is available here.

The download page for IOUG�s Enterprise Best Practices SIG is available here.

Hello, I'm Petra Manche!  I work in the Security Evaluations team in Oracle's Security Assurance Group.  Security Evaluations are a critical part of Oracle Software Security Assurance, and my team is responsible for managing the independent security evaluations of all Oracle products

Oracle recently completed the evaluations of Oracle Database 10g Release 2 (10.2.0.3) and Oracle Label Security 10g Release 2 (10.2.0.3) against Common Criteria assurance level EAL4+ and against the U.S. Government Protection Profile for Database Management Systems in Basic Robustness Environments (Version 2.1).   As usual Oracle evaluated the Enterprise Edition of the Database, but for the first time we also evaluated Standard Edition and Standard Edition 1.  Real Application Clusters (RAC), Enterprise Users, and Partitioning were also included with these evaluations for the first time.

For those who don't know what Security Evaluations are: independent bodies (laboratories) examine Information Technology products and systems, and if the examination is passed, a certificate is awarded (usually by a government body).  This process provides confidence in the security of the Evaluated products to end users, including government and military institutions.

Oracle has a long history among IT vendors of having security evaluations performed on its products.  Since committing to the security evaluation process in 1990, Oracle has successfully completed 29 security evaluations.  Many of the early evaluations were on Oracle Database Server, but more recently we have extended our scope and evaluated other products including Oracle Enterprise Linux, Oracle Application Server and Oracle Internet Directory. 

Oracle is currently committed to evaluating its products under two industry standards:

-         FIPS 140 for cryptographic modules, and

-         Common Criteria for Information Technology Security Evaluation. 

FIPS stands for Federal Information Processing Standard.  The full title of FIPS 140 is �FIPS 140-2: Security Requirement for Cryptographic Modules.�  It is published by the U.S. National Institute of Standards and Technology (NIST).  Hardware, firmware or software cryptographic modules are all tested and validated against the standard.  The cryptographic algorithms are NIST approved.  FIPS 140-3 is currently being drafted and representatives from Oracle will attend the upcoming FIPS 140-3 Software Security Workshop.

Common Criteria (CC) is also known as ISO standard 15048.  The full title of the standard is �Common Criteria for Information Technology Security Evaluation".  The Common Criteria is a single framework of evaluation criteria for products or systems.  It is designed to look at the whole development lifecycle: from design, implementation, testing to delivery and installation of the product or system by a third party, in order to provide assurance that development practices have been documented, followed and enforced correctly.

A common misconception about the Common Criteria is that the entire product is always evaluated in this process.  In fact, it is the security-related functions and the parts of the product that interact with those security functions that are evaluated.  These make up the scope of the evaluation, a.k.a. �Target of Evaluation�.  The product is installed in an evaluated configuration, whereby some of the product functionality may be disabled but the product must be able to function normally.  Information on what exactly has been evaluated is found in a document called the �Security Target�.  This document is publicly available once a product has been certified.  Security Targets for Oracle software are available on the Security Evaluation page on Oracle Technology Network.

To date Oracle has completed four FIPS 140 validations and 15 Common Criteria evaluations.  A listing of the evaluations that have been obtained or are currently underway can be found on Oracle�s Security Evaluation status page. 

Note that Oracle not only performs evaluations, but it is also actively participating in the development of the Common Criteria.  Oracle is a member of the Common Criteria Vendors Forum (CCVF) that works with the Common Criteria International organisations to enhance the Common Criteria and address common issues within the criteria.  In a previous blog entry, Duncan Harris discussed some of the limitations with the current version of the Common Criteria. 

More information on Oracle Software Security Assurance is available on Oracle.com.  The Security Evaluation page on Oracle Technology Network provides detailed information about Oracle's involvement with Security Evaluations.

Hello, this is Shirley Ann Stern!  Recent security research indicates that SQL injection attacks constitute one of the most prevalent types of threats to IT environments.  For example, in its �Top 20�, SANS identifies SQL Injection as a major threat to Web applications.  

SQL injection is one of the most common forms of attacks carried out at the application layer.  In layman�s terms, SQL Injection attacks are designed to leverage improper coding of web applications that, in the absence of proper input validation, allow a malicious attacker insert string input to an application, and as a result, send potentially harmful SQL commands to the application�s back-end database.  Although any program or application (that is powered by a database) may be vulnerable to SQL injections, web applications are at a higher risk because they often allow an attacker to perpetrate SQL injection attacks without being authenticated to the targeted database or application.  The potential consequences of these attacks are serious.  A successful SQL Injection attack can allow the attacker to gather sensitive data, manipulate database information, and in some instances, to change the structure of the database, deny legitimate access to it, or grant unauthorized privileges to himself or others.

An important objective of Oracle Software Security Assurance is that we provide information to customers that helps enable them to use our products securely.  To this end, we have developed training materials titled  �Defending Against SQL Injection Attacks.�  Available now, this training content is available online and can also be downloaded so that offline studying (while in the train for your morning commute) is possible.  �Defending Against SQL Injection Attacks� highlights some of the coding practices required to eliminate SQL injection vulnerabilities when developing in an Oracle environment.  Oracle recommends that anyone who develops Internet applications that access an Oracle database review these materials.  Note that this tutorial will also be available through Oracle University as a lesson in the instructor-led course �Oracle Database 11g: Advanced PL/SQL�, which is scheduled to be available in April 2008.

More information on Oracle Software Security Assurance is available on Oracle.com.  Various trainings, including �Defending Against SQL Injection Attacks� are available on the Server Technologies Curriculum Web Site.  The Security Technology Center and Oracle Software Security Assurance Resource Library also include a number of useful links to security trainings and white papers. 

Hello, this is Eric Maurice!

A security vendor recently issued a press release that revealed the results of an informal survey it conducted of Database Administrators conducted at Oracle Users Group meetings throughout the United States.  The vendor allegedly found that two-thirds of the 305 respondents had never installed a Critical Patch Update.  A number of outlets including blogs and media publications commented on these findings.

It is difficult to draw firm conclusions from this survey because of the relatively small size of the sample, absence of information about representativity of the sample, and the formulation of the questions themselves.  However this survey is interesting to security professionals insofar as it reinforces the importance of patching and brings to light a new element: the psychology of patching. 

Commenting in a blog entry, Pete Finnigan made an interesting comment: �I am starting to get the impression from talking to a lot of people that the issue has become psychological, a lot of companies believe it�s difficult, that it will fail and that everything in the organization needs to be regression tested.�  Security professionals are periodically faced with the decision �to patch or not to patch.�  For some, this decision is very difficult because it comes down to weighing the known and immediate consequences of the patching procedure (significant effort for testing and deploying the patches, and the impact of temporarily affecting production environments) versus the unknown and hard-to-predict consequences of keeping known vulnerabilities unpatched (damages resulting from an incident that was enabled by the presence of the unpatched vulnerability).  It is generally in human nature to find known and immediate difficulties more daunting than those that are uncertain and more remote, though the uncertain ones might have much more critical and threatening impact.  Can the decision not to patch be likened to the decision by careless drivers to run yellow or red lights to avoid being delayed for three or four minutes, while consciously ignoring the potential price of such action (possible death or injury) if collisions were to occur? 

The only solutions for removing the psychological objections to patching are mandating the application of security patches as a part of the normal maintenance of production systems or providing objective measures to determine whether patching is required on certain systems at a certain point in time. 

Patching decisions can only become objective business decisions if they are made after computing the expected cost or benefit resulting from the application of the security patches on a given system.  The costs of the patching effort and its impact on production environments need to be measured against the probability that the unplugged vulnerability will result in a successful exploit, multiplied by the financial liability that this successful exploitation would create for the organization.  Unfortunately, there is no such thing as an actuarial table that would provide accurate statistical measures of the chance of occurrence of a specific incident or exploit; and furthermore, measuring the full financial impact (direct and indirect costs) of a potential incident is extremely difficult, therefore a lot of guesswork has to take place.  This is why most security-conscious organizations require mandatory patching, instead of attempting to develop a comprehensive quantitative risk model for all their systems in their environment.

Oracle recommends that customers apply the Critical Patch Updates when they become available to maintain a proper security posture.  However, immediate and systematic application of every security patch on an ongoing basis for all production systems may be difficult or impossible for some organizations because of the complexity of their environment or due to their production requirements.  This is why Oracle has intentionally designed the Oracle Database Server, Oracle Application Server, Oracle Enterprise Manager, and Oracle E-Business Suite R12 patches to be cumulative.  As a result, each Critical Patch Update for these products contains the security fixes from ALL previous Critical Patch Updates.  The benefit for customers is clear: applying the most recent Critical Patch Update will install all the fixes that were previously released for these products.

Note that customers, who are applying the most recent patch sets also get the benefit of previously released security fixes.  That is because security fixes are also included in patch sets and in new product releases (Oracle�s policy is to first fix security vulnerabilities in the current code, i.e., the code used for the next release of the product).  The inclusion of security fixes in patch sets and product releases provides customers more patching flexibility, effectively allowing those who are planning to deploy the most recent patch set to �skip� the application of a Critical Patch Update. 

When looking at the previously discussed survey, one is left to wonder if the inclusion of security fixes in patch sets had the undesirable consequence of causing some Oracle DBAs to mostly ignore Critical Patch Updates, opting instead to focus resources on applying patch sets.  However, Oracle recommends that the Critical Patch Updates remain the primary means of applying security fixes because Critical Patch Updates are released more frequently than patch sets and new product releases. 

You can find more information about Oracle�s security lifecycle policies on the Security Vulnerability Fixing Policy and Process page on Oracle Technology Network.  The Critical Patch Updates and Security Alerts page also on Oracle Technology Network provides detailed information about previously released Critical Patch Updates and Security Alerts.  Additionally, the Resource Library on the Oracle Software Security Assurance web site provides a number of links to useful security resources, including a white paper discussing how to develop a repeatable Critical Patch Update process

Hello, this is Eric Maurice again! 

Oracle today released the January 2008 Critical Patch Update (CPUJan2008).  This Critical Patch Update (CPU) addresses a total of 26 vulnerabilities affecting Oracle Database Server, Oracle Application Server, Oracle Collaboration Suite, Oracle E-Business Suite, and Oracle PeopleSoft Enterprise.  Eight of these vulnerabilities are specific to Oracle Database Server, including one vulnerability affecting Oracle Database Server 11g on Linux. 

While none of the Oracle Database Server fixes requires patching the database client-only installations, this Critical Patch Update includes fixes for six Oracle Application Server vulnerabilities, and two of these fixes are for client installations.  The two Application Server client fixes address severe vulnerabilities affecting JInitiator, a web browser extension that enables end users to run Oracle Forms Services applications within their browser.  These two vulnerabilities have received a CVSS score of 9.3 because they could allow an attacker to gain full control of the targeted client (e.g. a laptop or workstation) at the Operating System level.  Note however that these two vulnerabilities cannot be used to exploit a server. 

Hi, this is Chad Hughes again.  In order to maintain a proper security posture, an organization must commit to developing and maintaining secure configurations on all layers of its environment.  Such commitment may require the organization to reconsider commonly accepted assumptions, dispel security myths, or just �get back to the basics� of security.

For example, the �Chronology of Data Breaches� compiled by the Privacy Rights Clearinghouse includes a number of instances where the improper disclosure of sensitive information could have been prevented by common sense, or basic security policies and procedures.  It is therefore not surprising that a recent Ponemon Institute survey sponsored by Oracle found that �42 % of IT practitioners believe their organizations can do more to prevent loss or theft of confidential information� and �Only 55 % of IT respondents believe they would be able to notify users and customers impacted by a data breach.  Of course, these issues are not limited to businesses, but also impact government organizations as well.  For example, a recent article on CSO Online related how the U.S. Department of Agriculture managed to expose thousands of social security numbers.

Incorrect technical assumptions can also be very damaging.  For example, while many IT professionals may think that databases are usually sheltered within corporate firewalls, in his 2005 and most recent 2007 �Database Exposure Survey � research, David Litchfield found that many databases are directly exposed to the Internet.  Unfortunately, generally innocuous search sites such as Google can be used to search for specific systems and services exposed to the Internet, and known vulnerabilities on those systems.  See for example �Google Code Search peers into programs' flaws� on SecurityFocus or �Google Your Site For Security Vulnerabilities� on Security Devcenter.  Michael Sutton's blog entry, �How Prevalent Are SQL Injection Vulnerabilities,� includes an example of a simple Google query intended to find databases exposed directly or indirectly to the Internet.

A myopic concern with external threats and hackers may also lead organizations on the wrong path by focusing the security effort exclusively towards securing the perimeter of the organization.  For example, a quick glance at the web site of the Computer Crime & Intellectual Property Section of the United States Department of Justice shows that employees (both current and former) and contractors represent a significant portion of perpetrators.  When hardening exercises are performed in production environments, far too often only the Internet-facing edge of production environments get the hardening treatment, creating a hard, crunchy shell, but leaving a soft, gooey center.  The problem is that the hard crunchy shell often allows outside access to sensitive resources at the center to provide legitimate access to a set of services or applications.  When hardening the center is neglected, leaving it soft and gooey, it may be vulnerable to attack through these holes intentionally left open in the hard, crunchy shell.  As a result, it is not uncommon to witness situations where a compromised web applications server has resulted in the compromise of internal servers, sometimes even granting the attacker with privileged access on these machines.  An unprotected center also may unnecessarily expose valuable resources to internal threats such as human error, disgruntled employees, and malware propagation.

Even when an organization understands the need to work on all layers of its production environment, often enough, the secure configuration effort is hampered by the belief that such effort will require a tremendous amount of resources.  However, this is not necessarily true!

The effort of limiting the attack surface of the environment can yield significant security benefits.  This is because, in complex applications, no one-size-fits-all configuration can possibly accommodate the needs of every customer.  In most instances, customizing the installation to leave the proper balance of functionality is desirable to meet production and security objectives.  Production systems that are left in their default state are likely to contain unused functionality that varies from customer to customer.  Unused functionality in production environments needlessly increases the exposure surface, or total number of possible attack vectors.  To reduce the exposure risk, customers can limit production system functionality to that which is required.

The greatest advantage of reducing surface area of production environments is that it contributes to significantly increasing the security posture of the organization at a relatively small cost. This is particularly true when hardening can be automated so the incremental cost to harden is low. Hardening production environments by reducing the attack surface is relatively inexpensive compared to many other defense in depth safeguards: it typically doesn�t require expenses for acquiring additional licenses or hardware; hardening effort can be incremental so as to not dramatically impact production environment, etc.  Most importantly, the security return of a surface reduction effort is obvious -- if a defect is found in functionality you're not using, you're likely to be protected.  And you're likely to be protected before patching, before upgrading, before employing a work-around...nothing additional is required.  If a 0-day exploit happens to reside in unused functionality that was already disabled by a previous hardening exercise, you're protected.

For more information on Oracle�s Secure Configuration initiative, see my previous blog entry �Oracle�s Approach to Configuration Hardening.�    Finally, the Oracle Software Security Assurance Resource Library includes valuable links to technical white papers and security checklists providing guidelines for reducing surface areas, or engaging in a more comprehensive hardening effort.

NOTE: Opinions expressed by the authors of the white papers and articles cited in this blog entry do not reflect the position of Oracle. Any advice, conclusion, or recommendations discussed on these sites (or sites they link to) are not validated by Oracle.

Hi, this is Eric Maurice again! Last week, we discussed the objectives of CVSS and how it impacted the scoring philosophy of the standard.  Today, we are going to take a closer look at the formula vendors use to compute CVSS Base Scores.

The CVSS Base Score is computed from six criteria, known collectively as the �Base Metrics�, representing �the most fundamental, immutable qualities of a vulnerability�.  These criteria are:

1.      Access Vector.  This measures �how remote an attacker can be to attack a target�.  The possible Access Vector values are Local, Adjacent Network, and Network;

2.      Access Complexity.  This measures �the complexity of attack required to exploit the vulnerability once an attacker has gained access to the target system�.  The possible Access Complexity values are High, Medium and Low;

3.      Authentication.  This measures �the number of times an attacker must authenticate to the target system in order to exploit the vulnerability�.  The possible Authentication values are Multiple, Single, and None;

4.      Confidentiality Impact.  This measures �the impact on confidentiality of a successful exploit of the vulnerability on the target system�, that is to say, improper information disclosure.  The possible Confidentiality Impact values are None, Partial, and Complete;

5.      Integrity Impact. This measures �the impact on integrity of a successful exploit of the vulnerability on the target system�, that is to say, data corruption.  The possible Integrity Impact values are None, Partial, and Complete;

6.      Availability Impact.  This measures �the impact on availability of a successful exploit of the vulnerability on the target system�, that is to say, denial of service.  The possible Availability Impact values are None, Partial, and Complete.

A numerical value is assigned to each of the three possible answers for each of the six criteria.  Then a formula, known as the �Base Equation�, is used to assign weight to each of the criteria, combine the weighted values, and derive the Base Score.  The application of the Base Equation formula yields in a maximum score of 7.5 for vulnerabilities typically found in Oracle products (it would be extraordinary if an Oracle security bug would result in a complete compromise of the underlying operating system).  Note that the National Vulnerability Database considers CVSS scores between 7.0 and 10.0 to be �high�. 

The National Institute of Standards and Technology (NIST) hosts a CVSS 2.0 calculator online.  This neat utility provides the ability to compute the score without necessarily manually dealing with the Base, Temporal, or Environmental equations.  Let�s take one of the vulnerabilities addressed in the October 2007 CPU (CPUOct2007); the vulnerability DB01 had the following particularities:

-         Exploitability Metrics:

o       Related exploit range (AccessVector): Network

o       Attack complexity (AccessComplexity): Low

o       Level of authentication needed (Authentication): Single Instance

-         Impact Metrics:

o       Confidentiality impact (ConfImpact): Partial

o       Integrity impact (IntegImpact): Partial

o       Availability impact (AvailImpact): Partial

When entering these values, the calculator provides the score of 6.5 as reported in the CPU documentation.

Oracle quickly realized some limitations of the CVSS base scoring system.  One is that CVSS does not distinguish between, for example, the disclosure of only a single database record and the disclosure of all data in a database.  Oracle therefore introduced the �Partial+� rating to denote such rare situations where the impact of the vulnerability can result in widespread impacts while partial means only limited impact.  Note that Oracle uses the Partial numeric value assigned by CVSS for both Partial and Partial+, so that Oracle does not deviate from the standard.

For more information, see:

-         Oracle MetaLink Note 394487.1 (subscription to MetaLink required) explains Oracle's implementation of the CVSS standard.

-         Oracle MetaLink Note 394486.1 (subscription to MetaLink required) provides a detailed explanation of Oracle�s risk matrices.

-         The Critical Patch Updates and Security Alerts page on Oracle Technology Network provides detailed information about previously released CPUs and Security Alerts.

-         The Guide to the Common Vulnerability Scoring System version 2.0 is available online, and it includes the scoring formulas set forth by the standard. 

Hi, this is Eric Maurice again!

Following the release of the October CPU (CPUOCT2007), it became clear that there was still a certain level of confusion and misunderstanding about CVSS and how it was implemented by Oracle.  Given this situation, I thought it might be helpful to further talk about CVSS, and specifically, the vulnerability scoring metholodgy implemented in the standard. 

The Common Vulnerability Scoring System (CVSS), initially announced in February 2005 on the U.S. Department of Homeland Security�s web site, is designed to �provide open and universally standard severity ratings of software vulnerabilities�.  Oracle was one of the first software vendors to adopt CVSS to provide a standard-based indication of the severity of the vulnerabilities fixed in its products.  Oracle has provided CVSS Base Scores in the risk matrices of the CPU documentation since the October 2006 Critical Patch Update (CPUOct2006).  In June 2007, FIRST (Forum of Incident Response and Security Teams) published the second version of the standards: CVSS 2.0, which was implemented by Oracle with the October 2007 Critical Patch Update (CPUOct2007).  Note that in this discussion, we will address the new CVSS 2.0 Scoring System if not otherwise noted

Since Oracle implemented CVSS, we periodically receive questions about how the CVSS base metrics scores are calculated.  Specifically, some people find it surprising that vulnerabilities deemed to be particularly critical receive a CVSS base score between 6.5 and 7.5 out of an absolute scale of 10.0.  Understanding the CVSS scoring system requires going back to the objectives of CVSS, and understanding the formulas behind the scores themselves.  In the first part of this blog series, we will be discussing the objectives of CVSS and how it affected the scoring of vulnerabilities

The CVSS web site states that the objective of CVSS is to provide a severity rating for all software vulnerabilities. 

This means that CVSS is designed to provide a numeric value (the score) indicative of the relative criticality of a given vulnerability regardless of the type of software it affects, whether it is an Operating System, antivirus, database, mail server, desktop or business application, etc.  As a result of this wide scope of applicability, the standard is intentionally designed to require a complete compromise at the Operating System layer for a given vulnerability to be given a base score of 10.0.  In other words, a vulnerability with a CVSS Base Score of 10.0 typically signifies a complete compromise of the system, that typically results in allowing the attacker full control, including administrative or �root� privileges at the OS layer.  An example of the impact of such a vulnerability in a third party product is reported on the National Vulnerability Database as �The attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.� 

Due to the nature of the Oracle bugs, vulnerabilities that could result in a complete compromise of the underlying server are rather rare.  In fact, since the CVSS scoring was implemented by Oracle, the highest-ever CVSS Base Score assigned by Oracle to a vulnerability addressed in the CPU would have been 7.5 if it had been scored under the CVSS 1.0 scoring system.  Note however that CVSS deals with single vulnerabilities, and does not completely account for �blended threats�, that is the combination of attack methods/vectors that could ultimately result in such a very extensive compromise.  It is therefore very important for organizations to patch all vulnerabilities as soon as possible, as leveraging various vulnerabilities across IT layers may result in a more complete compromise of the targeted system.

The CVSS system includes three types of score � Base, Temporal and Environmental.  Each is designed to measure different attributes of the vulnerability.  Oracle provides the �Base Score� in the CPU documentation.  It is characterized by the following aspects:

-         The Base Score is specific to a given vulnerability.

-         It does not change over time.  This is where the �Temporal Metrics� come into play to measure, for example, additional exposure resulting from the availability of exploit code. 

-         It is not specific to a customer�s technical IT environment.  This is where the �Environmental Metrics� come into play, to measure, for example, the likelihood of collateral damages to other systems and applications.

The CVSS documentation states that computing the Temporal and Environmental Metrics scores is optional.  While computing all three scores can provide a granular risk rating (specific to a given vulnerability in a specific environment at one point in time), most customers find this process to be too cumbersome, and they rely exclusively on the Base Score to assess the criticality of vulnerabilities and the priority given to patching them. 

Next week, we will be looking into more details on how the Base Score is computed using the �Base Equation� of CVSS.

For more information, see:

-         Oracle MetaLink Note 394487.1 (subscription to MetaLink required) explains Oracle's implementation of the CVSS standard

-         Oracle MetaLink Note 394486.1 (subscription to MetaLink required) provides a detailed explanation of Oracle�s risk matrices

-         The Critical Patch Updates and Security Alerts page on Oracle Technology Network provides detailed information about previously released CPUs and Security Alerts

-         The Guide to the Common Vulnerability Scoring System version 2.0 is available online, and it includes the scoring formulas set forth by the standard.