| 2019-10-01 00:22:16 |
Jesse Williamson |
bug |
|
|
added bug |
| 2019-10-01 00:22:16 |
Jesse Williamson |
attachment added |
|
apache2_jesse.debdiff https://bugs.launchpad.net/bugs/1846138/+attachment/5292976/+files/apache2_jesse.debdiff |
|
| 2019-10-01 04:22:24 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2019-10-01 04:22:29 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2019-10-01 18:10:07 |
Billy Olsen |
tags |
patch |
patch sts |
|
| 2019-10-03 18:30:05 |
Jesse Williamson |
affects |
ceph (Ubuntu) |
apache2 (Ubuntu) |
|
| 2019-10-08 02:18:41 |
Eric Desrochers |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-10-08 02:18:41 |
Eric Desrochers |
bug task added |
|
apache2 (Ubuntu Xenial) |
|
| 2019-10-08 02:19:01 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2019-10-08 12:03:19 |
Eric Desrochers |
apache2 (Ubuntu): status |
New |
Fix Released |
|
| 2019-10-08 12:03:26 |
Eric Desrochers |
apache2 (Ubuntu): assignee |
Jesse Williamson (chardan) |
|
|
| 2019-10-08 12:03:45 |
Eric Desrochers |
apache2 (Ubuntu Xenial): assignee |
|
Jesse Williamson (chardan) |
|
| 2019-10-08 12:03:47 |
Eric Desrochers |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2019-10-08 12:03:58 |
Eric Desrochers |
bug |
|
|
added subscriber STS Sponsors |
| 2019-10-08 12:04:57 |
Eric Desrochers |
description |
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
## DRAFT ##
[Impact]
[Test Case]
[Regression Potential]
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
|
| 2019-10-08 12:05:07 |
Eric Desrochers |
apache2 (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2019-10-08 12:05:10 |
Eric Desrochers |
apache2 (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2019-10-08 12:07:32 |
Eric Desrochers |
nominated for series |
|
Ubuntu Disco |
|
| 2019-10-08 12:07:32 |
Eric Desrochers |
bug task added |
|
apache2 (Ubuntu Disco) |
|
| 2019-10-08 12:07:46 |
Eric Desrochers |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-10-08 12:07:46 |
Eric Desrochers |
bug task added |
|
apache2 (Ubuntu Bionic) |
|
| 2019-10-08 12:12:50 |
Eric Desrochers |
apache2 (Ubuntu Disco): status |
New |
Fix Released |
|
| 2019-10-08 12:14:55 |
Eric Desrochers |
apache2 (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2019-10-08 12:14:59 |
Eric Desrochers |
apache2 (Ubuntu Bionic): status |
Confirmed |
Fix Released |
|
| 2019-10-08 12:23:23 |
Eric Desrochers |
description |
## DRAFT ##
[Impact]
[Test Case]
[Regression Potential]
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
## DRAFT ##
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
[Regression Potential]
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
|
| 2019-10-08 12:58:28 |
Eric Desrochers |
apache2 (Ubuntu Xenial): status |
Confirmed |
In Progress |
|
| 2019-10-08 13:16:49 |
Eric Desrochers |
description |
## DRAFT ##
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
[Regression Potential]
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
## DRAFT ##
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
|
| 2019-10-08 14:43:45 |
Eric Desrochers |
description |
## DRAFT ##
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
## DRAFT ##
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
This test case has been brought to my attention by an impacted user:
"
You must have an apache2 server, with an haproxy in front of it, and you initiate SSL connections with "nc" between 50 and 8000 connections and because the SSL connection process is never finished all those connections get stucked and never timeout.
"
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
|
| 2019-10-08 14:48:05 |
Eric Desrochers |
description |
## DRAFT ##
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
This test case has been brought to my attention by an impacted user:
"
You must have an apache2 server, with an haproxy in front of it, and you initiate SSL connections with "nc" between 50 and 8000 connections and because the SSL connection process is never finished all those connections get stucked and never timeout.
"
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
This test case has been brought to my attention by an impacted user:
"
You must have an apache2 server, with an haproxy in front of it, and you initiate SSL connections with "nc" between 50 and 8000 connections and because the SSL connection process is never finished all those connections get stucked and never timeout.
"
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
|
| 2019-10-08 14:49:22 |
Eric Desrochers |
description |
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
This test case has been brought to my attention by an impacted user:
"
You must have an apache2 server, with an haproxy in front of it, and you initiate SSL connections with "nc" between 50 and 8000 connections and because the SSL connection process is never finished all those connections get stucked and never timeout.
"
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
This test case has been brought to my attention by an impacted user:
"
You must have an apache2 server, with an haproxy in front of it, and you initiate SSL connections with "nc" between 50 and 8000 connections and because the SSL connection process is never finished all those connections get stucked and never timeout.
"
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
* It was tested pre-release by an impacted user, and the outcome was positive:
"I have tested the below packages for enabling handshake parameter(mod_reqtimeout) in apache. Looks the package is working fine. "
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
|
| 2019-10-08 16:10:56 |
Eric Desrochers |
description |
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
This test case has been brought to my attention by an impacted user:
"
You must have an apache2 server, with an haproxy in front of it, and you initiate SSL connections with "nc" between 50 and 8000 connections and because the SSL connection process is never finished all those connections get stucked and never timeout.
"
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
* It was tested pre-release by an impacted user, and the outcome was positive:
"I have tested the below packages for enabling handshake parameter(mod_reqtimeout) in apache. Looks the package is working fine. "
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
This test case has been brought to my attention by an impacted user:
"
You must have an apache2 server, with an haproxy in front of it, and you initiate SSL connections with "nc" between 50 and 8000 connections and because the SSL connection process is never finished all those connections get stucked and never timeout.
"
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
* It was tested pre-release by an impacted user, and the outcome was positive:
"I have tested the below packages for enabling handshake parameter(mod_reqtimeout) in apache. Looks the package is working fine. "
* Local autopkgtest inside qemu, revealed no issues:
autopkgtest [12:09:48]: @@@@@@@@@@@@@@@@@@@@ summary
duplicate-module-load PASS
htcacheclean PASS
ssl-passphrase PASS
chroot PASS
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
|
| 2019-10-08 17:47:45 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2019-10-08 21:53:36 |
Łukasz Zemczak |
apache2 (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-10-08 21:53:38 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-10-08 21:53:40 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2019-10-08 21:53:45 |
Łukasz Zemczak |
tags |
patch sts |
patch sts verification-needed verification-needed-xenial |
|
| 2019-10-10 23:10:43 |
Eric Desrochers |
description |
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
This test case has been brought to my attention by an impacted user:
"
You must have an apache2 server, with an haproxy in front of it, and you initiate SSL connections with "nc" between 50 and 8000 connections and because the SSL connection process is never finished all those connections get stucked and never timeout.
"
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
* It was tested pre-release by an impacted user, and the outcome was positive:
"I have tested the below packages for enabling handshake parameter(mod_reqtimeout) in apache. Looks the package is working fine. "
* Local autopkgtest inside qemu, revealed no issues:
autopkgtest [12:09:48]: @@@@@@@@@@@@@@@@@@@@ summary
duplicate-module-load PASS
htcacheclean PASS
ssl-passphrase PASS
chroot PASS
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
[Impact]
When running TCP Defensics suite which sends corrupt packages towards vip__public port 443, the suite is hanging after the half suite because there are no free connections. The connections will be in state "established" ~ 2 hours.
1.2. Detailed trouble description
# ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i establish | grep 443
tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 29817/haproxy
tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 29817/haproxy
This issue can be resolved by enabling the parameter(mod_reqtimeout). This parameter is available in apache 2.4.39 (released on 2019-04-01).
[Test Case]
This test case has been brought to my attention by an impacted user:
"
You must have an apache2 server, with an haproxy in front of it, and you initiate SSL connections with "nc" between 50 and 8000 connections and because the SSL connection process is never finished all those connections get stucked and never timeout.
"
Reproducer (Thanks to Szilard): https://pastebin.ubuntu.com/p/6Hk64CDc7H/
[Regression Potential]
* The backport already exist in Bionic/Disco (done by security team via the security channel)
* It is also backported upstream into 2.4 (branch : 2.4.x)
* It was tested pre-release by an impacted user, and the outcome was positive:
"I have tested the below packages for enabling handshake parameter(mod_reqtimeout) in apache. Looks the package is working fine. "
* Local autopkgtest inside qemu, revealed no issues:
autopkgtest [12:09:48]: @@@@@@@@@@@@@@@@@@@@ summary
duplicate-module-load PASS
htcacheclean PASS
ssl-passphrase PASS
chroot PASS
[Other Info]
[Original description]
Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18.
Lack of this feature was exhausting free connections when sent corrupted packets. |
|
| 2019-10-10 23:13:45 |
Eric Desrochers |
tags |
patch sts verification-needed verification-needed-xenial |
patch sts verification-done-xenial verification-needed |
|
| 2019-10-10 23:34:07 |
Eric Desrochers |
removed subscriber STS Sponsors |
|
|
|
| 2019-10-16 05:35:03 |
Launchpad Janitor |
apache2 (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2019-10-16 05:35:16 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-10-18 00:42:04 |
Mathew Hodson |
tags |
patch sts verification-done-xenial verification-needed |
patch sts verification-done-xenial |
|
