Merge branch 'jetty-10.0.x' into jetty-11.0.x

This commit is contained in:
Olivier Lamy 2022-06-07 10:59:26 +10:00
commit e39d24f5b1
6 changed files with 17 additions and 139 deletions

View File

@ -26,6 +26,8 @@ updates:
versions: [ ">=12" ]
- dependency-name: "org.jboss.weld.servlet:*"
versions: [ ">=4.0.0" ]
- dependency-name: "org.glassfish.jaxb:*"
versions: [ ">=2.0.0"]
- package-ecosystem: "maven"
directory: "/"
@ -65,6 +67,8 @@ updates:
versions: [ ">=12" ]
- dependency-name: "jakarta.xml.bind:*"
versions: [ ">=3.0.0" ]
- dependency-name: "org.glassfish.jaxb:*"
versions: [ ">=3.0.0"]
- package-ecosystem: "maven"
directory: "/"
@ -106,6 +110,8 @@ updates:
versions: [ ">=4.0.0" ]
- dependency-name: "jakarta.xml.bind:*"
versions: [ ">=4.0.0" ]
- dependency-name: "org.glassfish.jaxb:*"
versions: [ ">=4.0.0"]
- dependency-name: "jakarta.xml.ws:*"
versions: [ ">=4.0.0" ]
- dependency-name: "com.sun.xml.ws:jaxws*"

View File

@ -22,11 +22,9 @@ The [following checklist](https://www.eclipse.org/jetty/security_processes.php)
- [ ] Identify a CWE Definition and add it to the advisory description.
- [ ] Identify vulnerable version(s), including current and past versions that are affected (e.g. 9.4.0 through 9.4.35, and 10.0.0.alpha1 through 10.0.0.beta3…etc.)
- [ ] Identify and document workaround(s), if applicable, in the comments of the security advisory.
- [ ] Open an Eclipse Bugzilla issue to have a CVE allocated. The issue should be opened under the Community "Product" category with a "Component" of Vulnerability Reports. The CVE should include the following:
1. Version(s) affected
2. CVE Score
3. CWE Identifier(s)
4. Brief description of the issue
- [ ] Open an [Gitlab@Eclipse EMO CVE issue](https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/new?issuable_template=cve) to have a CVE allocated.
The issue should be opened under the "Eclipse Foundation" > "EMO Team" > "EMO" section as a "cve" description, with the "This issue is confidential" checkbox checked.
Follow the template for what details are necessary to file for a CVE.
- [ ] Once the CVE is allocated update the Security Advisory with the number
- [ ] Build and test fix(es) locally and in CI environment.
- [ ] Merge tests and fix - ensure description does not mention vulnerability directly. Do not merge directly from the security advisory as it can be traced back before publication.

View File

@ -1,125 +0,0 @@
HttpParser Error Buffer Bleed Vulnerability
===========================================
Published Date:
---------------
2015, Feb 24
CVE:
----
CVE-2015-2080
Discovered and Reported By:
---------------------------
[Gotham Digital Science](http://www.gdssecurity.com/) and Stephen Komal.
[JetLeak Vulnerability Remote Leakage of Shared Buffers in Jetty / blogs.gdsecurity.com](http://blog.gdssecurity.com/labs/2015/2/25/jetleak-vulnerability-remote-leakage-of-shared-buffers-in-je.html)
Affected Versions of Jetty:
---------------------------
* 9.2.3.v20140905
* 9.2.4.v20141103
* 9.2.5.v20141112
* 9.2.6.v20141205
* 9.2.7.v20150116
* 9.2.8.v20150217
* 9.3.0.M0
* 9.3.0.M1
Versions of Jetty Containing Fix:
--------------------------------
* 9.2.9.v20150224
Patched version of jetty-http.jar:
----------------------------------
Patched version of the affected jetty-http jars are available as attachments on https://bugs.eclipse.org/460642
Statement:
----------
Jetty versions 9.2.3.v20140905 through 9.2.8.v20150217 have a ByteBuffer reuse and information bleed vulnerability surrounding bad HTTP request header parsing error responses.
History:
--------
Back in Jetty 9.2.3, a feature requesting more detailed logging messages surrounding problems parsing bad HTTP request headers ( https://bugs.eclipse.org/443049 ) was implemented.
The feature request was to include better debug information in the Jetty logs (at WARN level) to help diagnose and resolve HTTP parsing errors.
However, the implementation incorrectly exposes this debug information back on the HTTP 400 response reason phrase, potentially exposing parts of server side buffers used from prior request processing on the same server.
The following bash shell script demonstrates the problem using netcat on linux against the Jetty Distribution's demo-base.
```
#!/bin/bash
RESOURCEPATH="/test/dump/info"
BAD=$'\a'
function normalRequest {
echo "-- Normal Request --"
nc localhost 8080 << NORMREQ
POST $RESOURCEPATH HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded;charset=utf-8
Connection: close
Content-Length: 16
Username=Joakim
NORMREQ
}
function badCookie {
echo "-- Bad Cookie --"
nc localhost 8080 << BADCOOKIE
GET $RESOURCEPATH HTTP/1.1
Host: localhost
Coo${BAD}kie: ${BAD}
BADCOOKIE
}
normalRequest
echo ""
echo ""
badCookie
```
The results are often seen in the HTTP response such as ...
```
HTTP/1.1 400 Illegal character 0x7 in state=HEADER_IN_NAME in 'GET /dummy/ HTTP/... localhost\nCoo\x07<<<kie: \x07\n\n>>>e: application/x-...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
Content-Length: 0
Connection: close
Server: Jetty(9.2.8.v20150217)
```
What you are seeing is a http response phrase that includes raw ByteBuffer details on what happened during the parsing failure.
The parts of the output are in the general form
`{what_has_been_parsed}<<<{left_to_parse}>>>{old_buffer_seen_past_limit}`
The part at `{old_buffer_seen_past_limit}` is where this exposure of past buffers comes from. It is this information where an exploit could be made to present random prior buffers from the server buffer pool. This information can contain anything seen in a past handled request.
We have this problem already patched in Jetty 9.2.9.v20150224, and the same test as above results in ...
```
HTTP/1.1 400 Illegal character 0x7
Content-Length: 0
Connection: close
Server: Jetty(9.2.9.v20150224)
```
Everyone is strongly encouraged to upgrade to Jetty 9.2.9.v20150224 immediately.

View File

@ -13,7 +13,7 @@
<name>Jetty :: GCloud</name>
<properties>
<gcloud.version>2.6.0</gcloud.version>
<gcloud.version>2.7.0</gcloud.version>
</properties>
<modules>

View File

@ -322,7 +322,7 @@ public class DoSFilter implements Filter
tracker = getRateTracker(request);
// Calculate the rate and check if it is over the allowed limit
final OverLimit overLimit = tracker.isRateExceeded(System.currentTimeMillis());
final OverLimit overLimit = tracker.isRateExceeded(System.nanoTime());
// Pass it through if we are not currently over the rate limit.
if (overLimit == null)
@ -1182,8 +1182,8 @@ public class DoSFilter implements Filter
}
/**
* @param now the time now (in milliseconds)
* @return the current calculated request rate over the last second
* @param now the time now (in nanoseconds) used to calculate elapsed time since previous requests.
* @return the current calculated request rate over the last second if rate exceeded, else null.
*/
public OverLimit isRateExceeded(long now)
{
@ -1201,9 +1201,9 @@ public class DoSFilter implements Filter
}
long rate = (now - last);
if (rate < 1000L)
if (TimeUnit.NANOSECONDS.toSeconds(rate) < 1L)
{
return new Overage(Duration.ofMillis(rate), _maxRequestsPerSecond);
return new Overage(Duration.ofNanos(rate), _maxRequestsPerSecond);
}
return null;
}
@ -1292,7 +1292,7 @@ public class DoSFilter implements Filter
int latestIndex = _next == 0 ? (_timestamps.length - 1) : (_next - 1);
long last = _timestamps[latestIndex];
boolean hasRecentRequest = last != 0 && (System.currentTimeMillis() - last) < 1000L;
boolean hasRecentRequest = last != 0 && TimeUnit.NANOSECONDS.toSeconds(System.nanoTime() - last) < 1L;
DoSFilter filter = (DoSFilter)_context.getAttribute(_filterName);

View File

@ -16,7 +16,6 @@ package org.eclipse.jetty.servlets;
import java.net.InetSocketAddress;
import java.util.Collections;
import java.util.Enumeration;
import java.util.concurrent.TimeUnit;
import jakarta.servlet.FilterConfig;
import jakarta.servlet.ServletContext;
@ -174,7 +173,7 @@ public class DoSFilterTest extends AbstractDoSFilterTest
for (int i = 0; i < 5; i++)
{
Thread.sleep(sleep);
if (rateTracker.isRateExceeded(TimeUnit.NANOSECONDS.toMillis(System.nanoTime())) != null)
if (rateTracker.isRateExceeded(System.nanoTime()) != null)
exceeded = true;
}
return exceeded;