[Full-disclosure] Jetty 6.x and 7.x Multiple Vulnerabilities

[ascii <ascii@xxxxxxxxxxxx>]

Jetty 6.x and 7.x Multiple Vulnerabilities

 Name              Multiple Vulnerabilities in Jetty
 Systems Affected  Jetty 7.0.0 and earlier versions
 Severity          Medium
 Impact (CVSSv2)   Medium 5/10, vector: (AV:N/AC:L/Au:N/C:P/I:N/A:N)
 Vendor            http://www.mortbay.org/jetty/
 Advisory          http://www.ush.it/team/ush/hack-jetty6x7x/jetty-adv.txt
 Authors           Francesco "ascii" Ongaro (ascii AT ush DOT it)
                   Giovanni "evilaliv3" Pellerano (evilaliv3 AT ush DOT it)
                   Antonio "s4tan" Parata (s4tan AT ush DOT it)
 Date              20091024

I. BACKGROUND

Jetty is an open-source project providing a HTTP server, HTTP client and
javax.servlet container. These 100% java components are full-featured,
standards based, small foot print, embeddable, asynchronous and
enterprise scalable. Jetty is dual licensed under the Apache Licence
2.0 and/or the Eclipse Public License 1.0. Jetty is free for commercial
use and distribution under the terms of either of those licenses.

Jetty is used in a wide variety of projects and products: embedded in
phones, in tools like the the eclipse IDE, in frameworks like GWT, in
application servers like Apache Geronimo and in huge clusters like
Yahoo's Hadoop cluster.

The latest version at the time of writing can be obtained from:
http://dist.codehaus.org/jetty/jetty-7.0.0/jetty-hightide-7.0.0.v2009100
5.tar.gz

Running Jetty 7.0.x is very easy, from the documentation page at:
http://docs.codehaus.org/display/JETTY/Running+Jetty-7.0.x

- From an unpacked release directory of jetty-7,
  the server can be started with the command: java -jar start.jar

- This will start a HTTP server on port 8080 and
  deploy the test web application at: http://localhost:8080/test

II. DESCRIPTION

Multiple Vulnerabilities exist in Jetty software.

III. ANALYSIS

Summary:

 A) "Dump Servlet" information leak
    (Affected versions: Any)

 B) "FORM Authentication demo" information leak
    (Affected versions: Any)

 C) "JSP Dump" reflected XSS
    (Affected versions: Any)

 D) "Session Dump Servlet" stored XSS
    (Affected versions: Any)

 E) "Cookie Dump Servlet" escape sequence injection
    (Affected versions: Any)

 F) Http Content-Length header escape sequence injection
    (Affected versions: Any)

 G) "Cookie Dump Servlet" stored XSS
    (Affected versions: =<6.1.20)

 H) WebApp JSP Snoop page XSS
    (Affected versions: =<6.1.21)


A) "Dump Servlet" information leak
   (Affected versions: Any)

By requesting the demo "Dump Servlet" at an URL like "/test/dump/"
it's possible to obtain a number of details about the remote Jetty
instance.

Variables: getMethod, getContentLength, getContentType, getRequestURI,
getRequestURL, getContextPath, getServletPath, getPathInfo,
getPathTranslated, getQueryString, getProtocol, getScheme,
getServerName, getServerPort, getLocalName, getLocalAddr,
getLocalPort, getRemoteUser, getRemoteAddr, getRemoteHost,
getRemotePort, getRequestedSessionId, isSecure(), isUserInRole(admin),
getLocale, getLocales, getLocales

Plus a dump of all the HTTP request headers, the request parameters
and much more.

Five forms can be used to perform a series of functionality tests
including:

  - Form to generate GET content
  - Form to generate POST content
  - Form to generate UPLOAD content
  - Form to set Cookie
  - Form to get Resource

While this is a feature we think that demo utilities should be
disabled by default. Many live deployments of Jetty exhibit demo
pages that leak important information and expose several vulnerabilites.

B) "FORM Authentication demo" information leak
   (Affected versions: Any)

An example application often erroneously deployed is the "FORM
Authentication demo" (logon.html and logonError.html pages) that uses
the standard "j_security_check" component.

By requesting the "/test/logon.html" page it's possible to detect the
presence of a Jetty installation.

As noted before we think that demo utilities should be disabled by
default.

C) "JSP Dump" reflected XSS
   (Affected versions: Any)

It has been found that the demo "JSP Dump" feature is vulnerable to
reflected Cross Site Scripting attacks. This can be replicated by
issuing a GET request to the "/test/jsp/dump.jsp" page:
"/test/jsp/dump.jsp?%3Cscript%3Ealert(%22hello%20world%22)%3C/script%3E"

Any GET key and value that reach the remote is reflected unencoded.

The problem resides in the "jsp/dump.jsp" file from the
"webapps/test.war" archive.

--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

<html><head>
<%@ page import="java.util.Enumeration" %>
</head><body>
<h1>JSP Dump</h1>

<table border="1">
<tr><th>Request URI:</th><td><%= request.getRequestURI() %></td></tr>
<tr><th>ServletPath:</th><td><%= request.getServletPath() %></td></tr>
<tr><th>PathInfo:</th><td><%= request.getPathInfo() %></td></tr>

<%
   Enumeration e =request.getParameterNames();
   while(e.hasMoreElements())
   {
       String name = (String)e.nextElement();
%>
<tr>
  <th>getParameter("<%= name %>")</th>
  <td><%= request.getParameter(name) %></td></tr>
<% } %>

</table>
</body></html>

--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

As shown no encoding is applied to user inputs.

D) "Session Dump Servlet" stored XSS
   (Affected versions: Any)

It has been found that the "Session Dump Servlet" feature is affected
by a stored Cross Site Scripting vulnerability.

The servlet, mapped in "/session/", normally uses HTTP POST parameters
but also accepts values by HTTP GET granting easier exploitation.

The issue can be verified by requesting an URL like the following:
"/test/session/?R=0&Name=%3Cscript%3Ealert(%27name%27)%3C/script%3E&Valu
e=%3Cscript%3Ealert(%27value%27)%3C/script%3E&Action=Set"

Any consecutive request to "/test/session/" without parameters will
include the previously inserted payloads.

Session keys and values are reflected unencoded both on the first and
successive requests.

E) "Cookie Dump Servlet" escape sequence injection
   (Affected versions: Any)

Making a POST request to the form at "/test/cookie/" with the "Age"
parameter set to a string throws a "java.lang.NumberFormatException"
exception.

The backtrace output is not sanitized from escape sequences, this
vulnerability is similiar to CVE-2003-0020 [1] and CVE-2003-0083 [2].

While the backtrace is protected from Cross Site Scripting attacks it
still reflects as-is many binary characters including ESC. These special
characters are used in control sequences to instruct the terminal to
perform special operations like executing commands [3, 4] or dumping
the buffer to a file [5, 6].

This issue can be demonstrated with the following Proof of Concept using
a non-dangerous escape sequence that will change the Xterm title.

In the first terminal:
$ echo -en "\x1b]2;safe?\x07\x0a"; java -jar start.jar etc/jetty.xml;

In the second terminal:
$ curl -kis "http://localhost:8080/cookie/"; -d "Action=Set&Name=aa&Value
=bb&Age=%1b%5d%32%3b%6f%77%6e%65%64%07%0a"

Logs can be found in logs/[date].stderrout.log or are printed directly
to the terminal. A user that views (cat, tail -f) these logs or runs
Jetty in his tty/pty may get influenced in a negative way by a malicious
control sequence.

The code involved in this vulnerability is in the Java class found at
"test-jetty-webapp/src/main/java/com/acme/CookieDump.java".

--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

    protected void handleForm(HttpServletRequest request,
                          HttpServletResponse response)
    {
        String action = request.getParameter("Action");
        String name =  request.getParameter("Name");
        String value =  request.getParameter("Value");
        String age =  request.getParameter("Age");

        if (name!=null && name.length()>0)
        {
            Cookie cookie = new Cookie(name,value);
            if (age!=null && age.length()>0)
                cookie.setMaxAge(Integer.parseInt(age));
            response.addCookie(cookie);
        }
    }

--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The problem also exists for other demo pages, see for example the
"/test/jsp/expr.jsp" page (eg: "/test/jsp/expr.jsp?A=LetteralString").

This issue is generic to all the Java applications that use the standard
error handling mechanism. Consider this an advisory also for Java JVM.

F) HTTP Content-Length header escape sequence injection
   (Affected versions: Any)

The same attack vector presented in point "E" can be exploited by
requesting a page using an HTTP request "Content-Length" header set to
a letteral string. This raises a type mismatch exception as previously
shown. See the following PoC:

$ curl 127.0.0.1:8080 -H "Content-Length: abcde"

The difference between this possibility and the one exposed in "E" is
that this works not only on Jetty default demo applications but on every
application that Jetty will serve.

G) "Cookie Dump Servlet" stored XSS
   (Affected versions: =<6.1.20)

On Tue, 06 Oct 2009 the CORE-2009-0922 advisory killed part of our
research. The advisory titled "Jetty Persistent XSS in Sample Cookies
Application" is about this specific point.

Out initial writing is presented anyway:

The "Cookie Dump Servlet" works in a similar way as the previous "Session
Dump Servlet", accepting GET parameters. The difference is that two
requests are needed (as it was a stored POST XSS) since the first will
trigger the Set-Cookie and the second request will echo it. This issue
can be replicated with the following request:

"/cookie?R=1&Name=<token1>&Value=<token2>&Age=60&Action=Set"

Input values are stored and presented unescaped.

H) WebApp JSP Snoop page XSS
   (Affected versions: =<6.1.21)

All the Jetty 6.1.X versions are affected by a reflected XSS in the JSP
Snoop page. This does not work on the 7.X branch.

When called by it's deploy the "WebApp JSP Snoop page" (/jspsnoop) is
vulnerable to XSS:

"/jspsnoop/ERROR/%3Cscript%3Ealert(123)%3C/script%3E"
"/jspsnoop/IOException/%3Cscript%3Ealert(123)%3C/script%3E"
"/jspsnoop/%3Cscript%3Ealert(123)%3C/script%3E"

"Path translated" and "Path info" are not encoded.

This in not exploitable when the page is implicitly called, for example
to handle a 404 page as the "Path translated" is always "/ERROR/404".
The same happens when requiring the page by its filesystem location
(/snoop.jsp).

IV. DETECTION

Jetty 7.0.0 and possibly earlier versions are vulnerable.

Jetty can be identified using the following examples or by directly
requesting files and locations marked as "information leak" in this
advisory.

Some examples:

  - intitle:"Powered By Jetty"
  - intitle:"JSP snoop page" "WebApp JSP Snoop page"
  - inurl:"snoop.jsp
  - "Welcome to Jetty 7"

V. WORKAROUND

The vendor decided not to modify the release schedule in order to
publish a version to address the presented issues. We have been sayd
that the next release (available in 1 to 3 weeks) will resolve all the
issues in the demo applications and the command sequence injection
vulnerability.

The ESC insertion problems will be resolved by:

- Handling the particular exceptions you found (NumberFormateException).
- Updating the stderrlogger so that all user supplied output is stripped
  of non whitespace ISO control characters.
- Stripping ISO control characters from generated error pages.

In the meantime the vendor provides the following workaround
recommendations:

- The test webappplications must not be deployed on production sites.
  An administrator can remove the "webapps/test.war" file and/or the
  "webapps/test directory", plus the contexts/test.xml file.
  To be clear again: DON'T DEPLOY THE TEST WEBAPP ON PRODUCTION.

- Do not run Jetty as the root user. Instead run as a limited
  user and redirect port 80 to the port that jetty is using.
  See http://docs.codehaus.org/display/JETTY/port80.

- Do not run production jetty instances from a console. Instead
  start in the background using an /etc/init.rc/jetty.sh script
  or similar.

- Redirect stderr to a file. This can be done with the jetty-logging.xml
  file as follows:
  java -jar start.jar etc/jetty.xml etc/jetty-logging.xml

- Process log files with cat -v if you wish to display them on a
  console without using an editor.

VI. VENDOR RESPONSE

Vendor will not release a new version to address these issues but is
working on them in the SNAPSHOT versions.

http://svn.codehaus.org/jetty/jetty/branches/jetty-6.1/VERSION.txt

We had no precise response about remediation status and plans but we
were told that it was okay to release this advisory. It elapsed about
a week from the last email sent to the vendor, since we got no reply
we assume that it's okay to release.

VII. CVE INFORMATION

No CVE at this time.

VIII. DISCLOSURE TIMELINE

20090616 Bug discovered
20091006 CORE-2009-0922 reveals an XSS issue (point G)
20091006 Jetty branch 7 kills the "jspsnoop" issue (point H)
20091011 Internal version of this advisory finalized
20091013 First vendor contact
20091014 Vendor Response, "We are working on XSS on demo apps"
20091015 Asking for release timeline
20091015 Vendor Response, Suggests a remediation, "Okay to release"
20091015 Remediation doesn't fix the Escape Sequence issue
20091015 Vendor Response, ACK, "Wait until next week"
20091016 Vendor Response, "We are not going to rush out a release to
fix the escape injection problem"
20091024 Advisory release

IX. REFERENCES

[1] Apache does not filter terminal escape sequences from error logs
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0020
[2] Apache does not filter terminal escape sequences from access logs
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0083
[3] Debian GNU/Linux XTERM (DECRQSS/comments) Weakness Vulnerability
    http://www.milw0rm.com/exploits/7681
[4] Terminal Emulator Security Issues
    http://marc.info/?l=bugtraq&m=104612710031920&w=2
[5] Eterm Screen Dump Escape Sequence Local File Corruption Vulnerability
    http://www.securityfocus.com/bid/6936/discuss
[6] RXVT Screen Dump Escape Sequence Local File Corruption Vulnerability
    http://www.securityfocus.com/bid/6938/discuss

X. CREDIT

Francesco "ascii" Ongaro, Giovanni "evilaliv3" Pellerano and
Antonio "s4tan" Parata are credited with the discovery of this
vulnerability.

Francesco "ascii" Ongaro
web site: http://www.ush.it/
mail: ascii AT ush DOT it

Giovanni "evilaliv3" Pellerano
web site: http://www.ush.it/, http://www.evilaliv3.org/
mail: evilaliv3 AT ush DOT it

Antonio "s4tan" Parata
web site: http://www.ush.it/
mail: s4tan AT ush DOT it

X. LEGAL NOTICES

Copyright (c) 2009 Francesco "ascii" Ongaro

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without mine express
written consent. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please email me for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/