|
|
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<--
<%@ page import="java.util.Enumeration" %>
JSP Dump
--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=Request URI: <%= request.getRequestURI() %> ServletPath: <%= request.getServletPath() %> PathInfo: <%= request.getPathInfo() %>
<% } %>
getParameter("<%= name %>")
<%= request.getParameter(name) %>