Encoding and Canonicalization Vulnerabilities
Encoding flaws have arisen in many kinds of web server software and present an inherent threat in situations where the same user-supplied data is processed by several layers using different technologies. A typical web request might be handled by the web server, the application platform, various man-aged and unmanaged APIs, other software components, and the underlying operating system. If different components handle an encoding scheme in different ways, or perform additional decoding or interpretation of data that has already been partially processed, then this can often be exploited to bypass filters or cause other anomalous behavior.
Allaire JRun Directory Listing Vulnerability
In 2001, a vulnerability was found in Allaire JRun that enabled an attacker to retrieve directory listings even in directories containing a default file such as index.html . A listing could be retrieved using URLs with the following form:
https://wahh-app.com/dir/%3f.jsp
%3f is a URL-encoded question mark, which is normally used to denote the start of the query string. The problem arose because the initial URL parser did not interpret the %3f as being the query string indicator. Treating the URL as ending with .jsp , the server passed the request to the component that handles requests for JSP files. This component then decoded the %3f , interpreted this as the start of the query string, found that the resulting base URL was not a JSP file, and so returned the directory listing. Further details can be found at www.securityfocus.com/bid/3592 .
Microsoft IIS Unicode Path Traversal Vulnerabilities
Two related vulnerabilities were identified in the Microsoft IIS server in 2000 and 2001. To prevent path traversal attacks, IIS checked for requests containing the dot-dot-slash sequence in both its literal and URL-encoded forms. If a request did not contain these expressions, then it was accepted for further processing. However, the server then performed some additional canonicalization
on the requested URL, enabling an attacker to bypass the filter and cause the server to process traversal sequences.
In the first vulnerability, an attacker could supply various illegal Unicode-encoded forms of the dot-dot-slash sequence, such as ..%c0%af . This expression did not match IIS’s upfront filters, but the later processing tolerated the illegal encoding, and converted it back to a literal traversal sequence. This enabled an attacker to step out of the web root and execute arbitrary commands with URLs like the following:
https://wahh-app.com/scripts/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\
In the second vulnerability, an attacker could supply double-encoded forms of the dot-dot-slash sequence, such as ..%255c . Again, this expression did not match IIS’s filters, but the later processing performed a superfluous decode of the input, thereby converting it back to a literal traversal sequence. This enabled an alternative attack with URLs like the following:
https://wahh-app.com/scripts/..%255c..%255c..%255c..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
Further details of these vulnerabilities can be found here:
■ www.microsoft.com/technet/security/bulletin/MS00-078.mspx
■ www.microsoft.com/technet/security/bulletin/MS01-026.mspx
Oracle PL/SQL Exclusion List Bypasses
Recall the dangerous default functionality that was accessible via Oracle’s PL/SQL gateway. To address this issue, Oracle created the PL/SQL Exclusion List, which blocks access to packages whose names begin with certain expressions, such as OWA and SYS
A series of bypasses to the PL/SQL Exclusion List have been discovered since 2001 by David Litchfield. In the first vulnerability, the filter can be bypassed by placing whitespace (such as a newline, space, or tab) before the package name. For example:
https://wahh-app.com/pls/dad/%0ASYS.package.procedure
This bypasses the filter, and the back-end database ignores whitespace, causing the dangerous package to be executed. In the second vulnerability, the filter can be bypassed by replacing the letter Y with %FF , which represents the ÿ character:
https://wahh-app.com/pls/dad/S%FFS.package.procedure
This bypasses the filter, and the back-end database canonicalizes the character back to a standard Y, thereby invoking the dangerous package. In the third vulnerability, the filter can be bypassed by enclosing a blocked expression in double quotation marks:
https://wahh-app.com/pls/dad/”SYS”.package.procedure
This bypasses the filter, and the back-end database tolerates quoted package names, meaning that the dangerous package is invoked. In the fourth vulner-ability, the filter can be bypassed by using angle brackets to place a programming goto label before the blocked expression:
https://wahh-app.com/pls/dad/<<FOO>>SYS.package.procedure
This bypasses the filter, and the back-end database ignores the goto label, and so executes the dangerous package.
Each of these different vulnerabilities arises because the front-end filtering is performed by one component, on the basis of simple text-based pattern matching, while the subsequent processing is performed by a different component, which follows its own rules to interpret the syntactic and semantic significance of the input. Any differences between the two sets of rules may present an opportunity for an attacker to supply input that does not match the patterns used in the filter but that the database interprets in such a way that the attacker’s desired package is invoked. Because the Oracle database is so extremely functional, there is ample scope for differences of this kind to arise.
More information about these vulnerabilities can be found here:
■ www.securityfocus.com/archive/1/423819/100/0/threaded
■ The Oracle Hacker’s Handbook by David Litchfield (Wiley, 2007)
