Reporting E-Business Suite Security Issues to Oracle Support

Oracle Support recently made some organization changes to handle customer-reported security related issues more efficiently. As I am involved in analyzing security-related Service Requests (SR), I've assembled some notes about Oracle's processes, which may help should you need to report a security issue.

It goes without saying (but I'll say it anyway) that Oracle takes security extremely seriously and strives to be very proactive in this area. Our policy and procedures are designed to protect your data and ensure that issues are dealt with promptly.

Essential Reading


These two pages explain in detail Oracle's policy and procedures for reporting security issues and provide details of the latest security patches and the quarterly Critical Patch Updates (CPU) .

Oracle Security Policy

Before going into the Support related aspects, here's something important from Oracle's Critical Patch Updates and Security Alerts page:-

As a matter of policy, Oracle will not provide additional information about the specifics of vulnerabilities beyond what is provided in the CPU or Security Alert notification, the pre-installation notes, the readme files, and FAQs. Oracle provides all customers with the same information in order to protect all customers equally. Oracle will not provide advance notification or "insider information" on CPU or Security Alerts to individual customers.

When to Report a Security Issue to Oracle Support

If you have any concerns about eBusiness Suite security issues, log a Service Request with Oracle Support to discuss those concerns. Customers often engage external or internal resources to perform security auditing and testing (e.g. in penetration testing projects).  These kinds of activities often raise questions about security.

Unfortunately there can be "false positives" reported for security issues so in general, any suspected vulnerability should be validated against a eBusiness Suite environment which has the latest CPU patch and has been configured according to Oracle's recommendations. The vulnerability should be demonstrable by a test case supplied by the person or organization reporting the vulnerability.

However to be clear, the general rule is to err on the side of caution and raise a SR with Oracle Support for any issues you have any concerns.

Reporting a E-Business Suite Security Issue

  1. Apps customers can log a Service Request through Metalink. Generic security issues would go to Applications Technology Group (ATG) but issues specific to a particular page or function should be logged against the relevant Functional Support team. You can specify that you believe the issue to be a security issue if you wish. All SRs are evaluated by the assigned Support Engineer.

    Be sure to provide a brief description of the issue, the basic version and architecture of your environment, specific confirmation of which CPU patch level you are on, and confirm that the Security Best Practice note for your E-Business Suite release has been implemented.

    NOTE - Oracle has a "Need to Know" policy for security issues.  If you have sensitive information to upload (such as details of a potential exploit or a PEN test report) do NOT upload it with the SR. Instead update the SR indicating that you have such sensitive information.  The assigned Support Engineer will provide details of how to get that information to the right person.
  2. If it's deemed to be a potential security risk, your SR will be passed to a separate Support Engineer in the "Security Certified Group" (SCG) The main criteria used for this are :-
    a) Does it contain a suspected software bug related to a security vulnerability?
    b) Does it contain a suspected software issue related to disclosure of personal data?
  3. The SR may be sanitised as a precautionary measure, so you may see some of the SR text change or just "disappear". This is normal procedure; don't be alarmed, we still have your details.
  4. The issue will be analysed by the SCG Engineer to verify the issue and circumstances around it.
  5. Once validated as a potential issue with no existing fix, it will be handed to Oracle's Corporate Security team. The issue is reevaluated at this stage. Any fixes produced from this stage will be delivered in a future CPU patch.

Frequently Asked Questions

Q1. How should I prepare for a Penetration Test and/or Security Audit?

If you are planning such a test you should ensure your environment is suitably prepared:

Q2. Our penetration test has identified multiple potential issues. Do I need to log a separate SR for each one?

No, not normally. Generally issues can be roughly grouped into a few small areas of concern, so initially raise one SR for the initial assessment and we can split it into separate SRs if required.

Q3. I found a security vulnerability reported on a (non-Oracle) web site. Is there a patch available for it?

Oracle Support Policy does not allow Support Engineers to confirm or deny specific vulnerabilities exist in specific product versions.

As described in Security Alerts and Critical Patch Updates- Frequently Asked Questions (Metalink Note 360470.1):

The information available on non-Oracle sites is not approved by Oracle. Some sites offer misleading information by providing only a small part of the vulnerabilities covered by the Oracle Critical Patch Update or Security Alert. Third-party sites may suggest workarounds that are incorrect, incomplete or untested and following such advice can lead to system damage.

Oracle strongly recommends that customers rely only on information provided by Oracle, specifically the Critical Patch Update documentation.

Q4. My Security Team tell me I must upgrade to Apache 2.x to avoid a whole bunch of known vulnerabilities. Is this supported with eBusiness Suite ?

No, Apache v2.x is not certified for Apps 11i or R12 at the time of writing.

The reason behind this recommendation from the Security tester is normally related to Apps 11i which reports that it uses Apache version 1.3.19. Some security teams simply take this version and compare it to known vulnerabilities. Unfortunately (or fortunately) the version of Apache used in eBiz is not relevant from a security fix perspective, as Oracle adds Apache security fixes to the Apache code maintained for eBiz as needed. Your security team should test to see if they can exploit a specific vulnerability to determine its relevance to your environment.

Q5. I raised a Security SR ages ago but nothing seems to be happening with it. What should I do?

You should certainly update your SR to request an update on the situation. There may be some restriction on what information Oracle Support are able to tell you but this should not prevent us from keeping you in the loop. As with any potential issue, it can sometimes be complex to identify the root cause and there may not always be a quick fix. The Support Engineer who is dealing with your issue will monitor the issue and should be able to escalate if appropriate.

Additional Tips

  1. It has been occasionally found that customers have set some security related profile options incorrectly, which may expose certain vulnerabilities. Check that these profile options are all set to the value of ERROR:
  • FND Function Validation Level
  • FND Validation Level
  • Framework Validation Level
  1. Don't use VISION install for testing potential vulnerabilities

    There can be subtle differences between a VISION installation and a PROD installation, so if you spot what could be a security issue in your VISION demo install, retest in a PROD instance to be sure it reproduces there.

Related Articles


It's interesting that you bundle things into a single SR for items found on database security reviews/penetration tests. Out of interest, how do you confirm implementation versus individual issues?

Posted by Anonymous Coward on August 06, 2008 at 04:20 AM PDT #

Hello Anon,

Support will certainly split issues into seperate SRs for you, if it is required for us to engage seperate teams in the investigations, however much of the time the majority of issues reported in a Pen test will fall into the ATG area. If you prefer to raise individual SRs for your own tracking purposes, then thats fine too.

For non-security related issues, you should always raise one SR for each different problem as normal.



Posted by Mike Shaw on August 06, 2008 at 03:49 PM PDT #

I opened SR 4354726.994 for a security issue, even after working on this SR for years, its still not properly secured (lots of loop-holes).

If you need more info please feel free to contact me.



Posted by Zia Hameed on August 18, 2008 at 01:42 AM PDT #

Hello Zia,

Sorry to hear you don't feel your issue was resolved.

According to the SR the issue is fixed in ATG RUP6, but if you want to raise a new SR and email me the number, we can go through the intricacies of your situation in detail



Posted by Mike Shaw on August 18, 2008 at 03:53 PM PDT #


I opened 7043310.994



Posted by Zia Hameed on August 21, 2008 at 01:16 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed


« June 2016