There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally.

Jetty is a Java based web server and servlet engine. An HTTP/2 SSL connection that is established and TCP congested will be leaked when it times out. An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients. The vulnerability is patched in 9.4.54, 10.0.20, 11.0.20, and 12.0.6.

https://github.com/jetty/jetty.project/issues/11256 https://github.com/jetty/jetty.project/security/advisories/GHSA-rggv-cv7r-mw98

There exists a security vulnerability in Jetty's ThreadLimitHandler.getRemote() which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory.

A flaw was found in the Jetty-server package. This flaw allows an attacker to send invalid requests, causing a denial of service in the Jetty Server.

Impact Jetty PushSessionCacheFilter can be exploited by unauthenticated users to launch remote DoS attacks by exhausting the server’s memory.

Patches https://github.com/jetty/jetty.project/pull/9715 https://github.com/jetty/jetty.project/pull/9716

Workarounds The session usage is intrinsic to the design of the PushCacheFilter. The issue can be avoided by: + not using the PushCacheFilter. Push has been deprecated by the various IETF specs and early hints responses should be used instead. + reducing the reducing the idle timeout on unauthenticated sessions will reduce the time such session stay in memory. + configuring a session cache to use session passivation, so that sessions are not stored in memory, but rather in a database or file system that may have significantly more capacity than memory.

References https://github.com/jetty/jetty.project/pull/10756 https://github.com/jetty/jetty.project/pull/10755

In Eclipse Jetty versions 12.0.0 to 12.0.16 included, an HTTP/2 client can specify a very large value for the HTTP/2 settings parameter SETTINGSMAXHEADERLISTSIZE. The Jetty HTTP/2 server does not perform validation on this setting, and tries to allocate a ByteBuffer of the specified capacity to encode HTTP responses, likely resulting in OutOfMemoryError being thrown, or even the JVM process exiting.

Eclipse Jetty could allow a remote attacker to hijack a user's session, caused by a flaw in the FileSessionDataStore. An attacker could exploit this vulnerability to gain access to another user's session.

Eclipse Jetty is vulnerable to a denial of service, caused by the additional CPU and memory allocations required to handle changed settings. By sending either large SETTINGs frames container containing many settings, or many small SETTINGs frames, a remote attacker could exploit this vulnerability to cause a denial of service.

Multiple cross-site scripting (XSS) vulnerabilities in Mort Bay Jetty 6.x and 7.0.0 allow remote attackers to inject arbitrary web script or HTML via (1) the query string to jsp/dump.jsp in the JSP Dump feature, or the (2) Name or (3) Value parameter to the default URI for the Session Dump Servlet under session/.

The Dump Servlet in Mort Bay Jetty 6.x and 7.0.0 allows remote attackers to obtain sensitive information about internal variables and other data via a request to a URI ending in /dump/, as demonstrated by discovering the value of the getPathTranslated variable.

Multiple cross-site scripting (XSS) vulnerabilities in the WebApp JSP Snoop page in Mort Bay Jetty 6.1.x through 6.1.21 allow remote attackers to inject arbitrary web script or HTML via the PATHINFO to the default URI under (1) jspsnoop/, (2) jspsnoop/ERROR/, and (3) jspsnoop/IOException/, and possibly the PATHINFO to (4) snoop.jsp.

jetty 6.0.x (jetty6) beta16 allows remote attackers to read arbitrary script source code via a capital P in the .jsp extension, and probably other mixed case manipulations.

Unspecified vulnerability in Jetty before 5.1.6 allows remote attackers to obtain source code of JSP pages, possibly involving requests for .jsp files with URL-encoded backslash ("%5C") characters. NOTE: this might be the same issue as CVE-2006-2758.

WebApp JSP Snoop page XSS in jetty though 6.1.21.

Dump Servlet information leak in jetty before 6.1.22.

Cookie Dump Servlet stored XSS vulnerability in jetty though 6.1.20.

JSP Dump and Session Dump Servlet XSS in jetty before 6.1.22.

Mort Bay Jetty 6.x through 6.1.22 and 7.0.0 writes backtrace data without sanitizing non-printable characters, which might allow remote attackers to modify a window's title, or possibly execute arbitrary commands or overwrite files, via an HTTP request containing an escape sequence for a terminal emulator, related to (1) a string value in the Age parameter to the default URI for the Cookie Dump Servlet in test-jetty-webapp/src/main/java/com/acme/CookieDump.java under cookie/, (2) an alphabetic value in the A parameter to jsp/expr.jsp, or (3) an alphabetic value in the Content-Length HTTP header to an arbitrary application.

Cross-site scripting (XSS) vulnerability in the CookieDump.java sample application in Mort Bay Jetty 6.1.19 and 6.1.20 allows remote attackers to inject arbitrary web script or HTML via the Value parameter in a GET request to cookie/.

Cross-site scripting (XSS) vulnerability in Mort Bay Jetty before 6.1.17 allows remote attackers to inject arbitrary web script or HTML via a directory listing request containing a ; (semicolon) character.

Common Vulnerabilities and Exposures assigned the identifiers CVE-2009-1523 and CVE-2009-1524 to the following vulnerabilities:

Name: CVE-2009-1523 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1523 Assigned: 20090505 Reference: CONFIRM: http://jira.codehaus.org/browse/JETTY-1004 Reference: CONFIRM: http://www.kb.cert.org/vuls/id/CRDY-7RKQCY Reference: CERT-VN:VU#402580 Reference: URL: http://www.kb.cert.org/vuls/id/402580 Reference: BID:34800 Reference: URL: http://www.securityfocus.com/bid/34800 Reference: SECUNIA:34975 Reference: URL: http://secunia.com/advisories/34975

Directory traversal vulnerability in the HTTP server in Mort Bay Jetty before 6.1.17, and 7.0.0.M2 and earlier 7.x versions, allows remote attackers to access arbitrary files via directory traversal sequences in the URI.

Name: CVE-2009-1524 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1524 Assigned: 20090505 Reference: CONFIRM: http://jira.codehaus.org/browse/JETTY-980 Reference: BID:34800 Reference: URL: http://www.securityfocus.com/bid/34800 Reference: SECUNIA:34975 Reference: URL: http://secunia.com/advisories/34975

Cross-site scripting (XSS) vulnerability in Mort Bay Jetty before 6.1.17 allows remote attackers to inject arbitrary web script or HTML via a directory listing request containing a ; (semicolon) character.

Note: it is unclear whether or not this affects jetty 5.x, which is the version that is included in Fedora.

Jetty 8.1.0.RC2 and earlier computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters.

The exception handling code in Eclipse Jetty before 9.2.9.v20150224 allows remote attackers to obtain sensitive information from process memory via illegal characters in an HTTP header, aka JetLeak.

The path normalization mechanism in PathResource class in Eclipse Jetty 9.3.x before 9.3.9 on Windows allows remote attackers to bypass protected resource restrictions and other security constraints via a URL with certain escaped characters, related to backslashes.

Eclipse Jetty is vulnerable to HTTP request smuggling, caused by a flaw in the HTTP/1.x Parser. By sending a specially-crafted request, an attacker could exploit this vulnerability to poison the web cache, bypass web application firewall protection, and conduct XSS attacks.

Eclipse Jetty could allow a remote attacker to obtain sensitive information. An attacker could send a specially-crafted URL request to the java.nio.file.InvalidPathException function using an invalid parameter to cause an error message to be returned containing the full installation path. An attacker could use this information to launch further attacks against the affected system.

Eclipse Jetty is vulnerable to cross-site scripting, caused by improper validation of user-supplied input. A remote attacker could exploit this vulnerability using the error messages to inject malicious script into a Web page which would be executed in a victim's Web browser within the security context of the hosting Web site, once the page is viewed. An attacker could use this vulnerability to steal the victim's cookie-based authentication credentials.

Eclipse Jetty could allow a remote attacker to obtain sensitive information, caused by a flaw when configured for showing a listing of directory contents. By sending a specially-crafted request, a remote attacker could exploit this vulnerability to obtain sensitive information.

[I've seen multiple news articles & blogs in the wake of the coordinated disclosure today, but no postings here yet, so lets start fixing that.]

Google, Cloudflare, AWS, and others released details today of a protocol-level issue in HTTP/2 being exploited in recent months for denial-of-service attacks:

https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ https://aws.amazon.com/blogs/security/how-aws-protects-customers-from-ddos-events/

This attack works via the multiplexed streams feature of HTTP/2, in which the client repeatedly makes a request for a new stream, and then immediately sends a RSTSTREAM frame to cancel them, resulting in the server doing lots of extra work to set up and tear down the streams, while not hitting any server-side limit on a maximum number of active streams per connection.

CVE-2023-44487 was issued to track this issue across implementations: https://www.cve.org/CVERecord?id=CVE-2023-44487

A script to check for affected implemenations has been posted at: https://github.com/bcdannyboy/CVE-2023-44487

Information I've found so far on open source implementations (most via the current listings in the CVE) include:

- Apache httpd: https://chaos.social/@icing/111210915918780532

- caddy: https://github.com/caddyserver/caddy/issues/5877

- envoy: https://github.com/envoyproxy/envoy/pull/30055

- golang: https://github.com/golang/go/issues/63417 https://groups.google.com/g/golang-announce/c/iNNxDTCjZvo

- h2o: https://github.com/h2o/h2o/security/advisories/GHSA-2m7v-gc89-fjqf https://github.com/h2o/h2o/pull/3291

- haproxy: https://github.com/haproxy/haproxy/issues/2312

- hyper: https://seanmonstar.com/post/730794151136935936/hyper-http2-rapid-reset-unaffected

- jetty: https://github.com/eclipse/jetty.project/issues/10679 https://github.com/eclipse/jetty.project/releases/tag/jetty-12.0.2 https://github.com/eclipse/jetty.project/releases/tag/jetty-11.0.17 https://github.com/eclipse/jetty.project/releases/tag/jetty-10.0.17 https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.53.v20231009

- netty: https://github.com/netty/netty/commit/58f75f665aa81a8cbcf6ffa74820042a285c5e61

- nghttp2: https://github.com/nghttp2/nghttp2/pull/1961 https://github.com/nghttp2/nghttp2/releases/tag/v1.57.0

- nginx: https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/ https://mailman.nginx.org/pipermail/nginx-devel/2023-October/S36Q5HBXR7CAIMPLLPRSSSYR4PCMWILK.html

- nodejs: https://github.com/nodejs/node/pull/50121

- proxygen: https://github.com/facebook/proxygen/pull/466

- swift-nio-http2: https://forums.swift.org/t/swift-nio-http2-security-update-cve-2023-44487-http-2-dos/67764

- tomcat: https://tomcat.apache.org/security-11.html#FixedinApacheTomcat11.0.0-M12 https://tomcat.apache.org/security-10.html#FixedinApacheTomcat10.1.14 https://tomcat.apache.org/security-9.html#FixedinApacheTomcat9.0.81 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.94

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

A vulnerability was found in keycloak, where on using lower case HTTP headers (via cURL) we can bypass our Gatekeeper. Lower case headers are also accepted by some webservers (e.g. Jetty). This means there is no protection when we put a Gatekeeper in front of a Jetty server and use lowercase headers.

References: https://issues.jboss.org/browse/KEYCLOAK-14090