| 2013-05-03 14:52:43 |
Rodney Beede |
bug |
|
|
added bug |
| 2013-05-07 22:51:54 |
Brian Murray |
isc-dhcp (Ubuntu): importance |
Undecided |
Medium |
|
| 2013-05-07 22:53:31 |
Brian Murray |
isc-dhcp (Ubuntu): status |
New |
Triaged |
|
| 2013-05-07 22:53:41 |
Brian Murray |
tags |
|
raring |
|
| 2013-05-07 23:04:24 |
Brian Murray |
bug |
|
|
added subscriber Brian Murray |
| 2013-06-09 17:06:31 |
CsCs |
bug |
|
|
added subscriber CsCs |
| 2013-06-30 18:59:53 |
japi |
bug |
|
|
added subscriber japi |
| 2013-11-18 15:24:55 |
Yves-Alexis Perez |
bug |
|
|
added subscriber Yves-Alexis Perez |
| 2014-08-31 10:29:38 |
Michael Bazzinotti |
bug |
|
|
added subscriber Michael Bazzinotti |
| 2015-06-25 11:34:08 |
Sérgio Faria |
bug |
|
|
added subscriber Sérgio Faria |
| 2015-09-21 00:32:54 |
Tim Utschig |
bug |
|
|
added subscriber Tim Utschig |
| 2015-10-05 19:36:05 |
Michael Johnson |
bug |
|
|
added subscriber Michael Johnson |
| 2016-03-27 16:42:46 |
graemewalker |
bug |
|
|
added subscriber ghw |
| 2016-11-24 16:47:49 |
David Coronel |
bug |
|
|
added subscriber David Coronel |
| 2016-11-24 17:39:37 |
Eric Desrochers |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712503 |
|
| 2016-11-24 17:51:17 |
Eric Desrochers |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798237 |
|
| 2016-11-24 18:16:20 |
Eric Desrochers |
isc-dhcp (Ubuntu): status |
Triaged |
In Progress |
|
| 2016-11-24 18:16:24 |
Eric Desrochers |
isc-dhcp (Ubuntu): assignee |
|
Eric Desrochers (slashd) |
|
| 2016-11-27 12:57:58 |
Dominique Poulain |
bug |
|
|
added subscriber Dominique Poulain |
| 2016-11-28 21:31:14 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2016-11-29 01:26:02 |
Eric Desrochers |
tags |
raring |
|
|
| 2016-12-02 15:27:12 |
Eric Desrochers |
isc-dhcp (Ubuntu): importance |
Medium |
High |
|
| 2016-12-02 19:33:37 |
Mathew Hodson |
tags |
|
trusty |
|
| 2016-12-05 13:40:29 |
Robie Basak |
nominated for series |
|
Ubuntu Trusty |
|
| 2016-12-05 13:40:29 |
Robie Basak |
bug task added |
|
isc-dhcp (Ubuntu Trusty) |
|
| 2016-12-05 20:44:16 |
Eric Desrochers |
isc-dhcp (Ubuntu Trusty): status |
New |
Confirmed |
|
| 2016-12-10 04:10:44 |
Eric Desrochers |
isc-dhcp (Ubuntu Trusty): assignee |
|
Eric Desrochers (slashd) |
|
| 2016-12-10 04:10:48 |
Eric Desrochers |
isc-dhcp (Ubuntu Trusty): importance |
Undecided |
Medium |
|
| 2016-12-10 04:11:09 |
Eric Desrochers |
isc-dhcp (Ubuntu Trusty): status |
Confirmed |
In Progress |
|
| 2016-12-10 17:15:05 |
Eric Desrochers |
description |
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
* none expected
I did the split such that users will automatically get isc-dhcp-client-ddns installed but users bothered by this bug then will have the option to switch to the one without it by uninstalling (isc-dhcp-client-ddns),
so existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
Without isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Note that this is how Xenial does it.
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
|
| 2016-12-13 14:29:55 |
Louis Bouchard |
nominated for series |
|
Ubuntu Yakkety |
|
| 2016-12-13 14:29:55 |
Louis Bouchard |
bug task added |
|
isc-dhcp (Ubuntu Yakkety) |
|
| 2016-12-13 14:29:55 |
Louis Bouchard |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-12-13 14:29:55 |
Louis Bouchard |
bug task added |
|
isc-dhcp (Ubuntu Xenial) |
|
| 2016-12-13 14:30:05 |
Louis Bouchard |
isc-dhcp (Ubuntu): status |
In Progress |
Fix Released |
|
| 2016-12-13 14:30:10 |
Louis Bouchard |
isc-dhcp (Ubuntu Xenial): status |
New |
Fix Released |
|
| 2016-12-13 14:30:16 |
Louis Bouchard |
isc-dhcp (Ubuntu Yakkety): status |
New |
Fix Released |
|
| 2016-12-15 16:32:50 |
Eric Desrochers |
attachment added |
|
debdiff_noddns_proposal_still_in_progress https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/+attachment/4792032/+files/noddns_binary_pkg.debdiff |
|
| 2016-12-19 13:36:46 |
Eric Desrochers |
attachment added |
|
V2_debdiff_noddns_proposal_still_in_progress https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/+attachment/4793975/+files/V2_no_ddns_binary_pkg.debdiff |
|
| 2016-12-19 13:37:08 |
Eric Desrochers |
attachment removed |
debdiff_noddns_proposal_still_in_progress https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/+attachment/4792032/+files/noddns_binary_pkg.debdiff |
|
|
| 2016-12-20 21:11:46 |
Eric Desrochers |
isc-dhcp (Ubuntu Trusty): importance |
Medium |
Wishlist |
|
| 2016-12-20 21:12:44 |
Eric Desrochers |
isc-dhcp (Ubuntu): importance |
High |
Undecided |
|
| 2017-04-19 12:58:01 |
Eric Desrochers |
attachment added |
|
verif-xenial.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/+attachment/4864794/+files/verif-xenial.debdiff |
|
| 2017-04-19 12:58:24 |
Eric Desrochers |
attachment added |
|
verif-trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/+attachment/4864795/+files/verif-trusty.debdiff |
|
| 2017-04-19 13:44:59 |
Eric Desrochers |
description |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
* none expected
I did the split such that users will automatically get isc-dhcp-client-ddns installed but users bothered by this bug then will have the option to switch to the one without it by uninstalling (isc-dhcp-client-ddns),
so existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
Without isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Note that this is how Xenial does it.
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
I did the split such that Trusty users will automatically get "isc-dhcp-client-ddns" installed but users bothered by this bug will have the option to switch to "isc-dhcp-client-noddns".
Existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
Without isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Note that this is how Xenial does it.
Caribou and I, slashd, have also tested a couple of release upgrade from Trusty to Xenial with both scenarios :
1 - Trusty upgrade to Xenial with "isc-dhcp-client-ddns"
2- Trusty upgrade to Xenial with "isc-dhcp-client-noddns"
and both scenarios worked as expected for caribou and I. (See comment #42)
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
|
| 2017-04-19 15:32:57 |
Eric Desrochers |
description |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
I did the split such that Trusty users will automatically get "isc-dhcp-client-ddns" installed but users bothered by this bug will have the option to switch to "isc-dhcp-client-noddns".
Existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
Without isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Note that this is how Xenial does it.
Caribou and I, slashd, have also tested a couple of release upgrade from Trusty to Xenial with both scenarios :
1 - Trusty upgrade to Xenial with "isc-dhcp-client-ddns"
2- Trusty upgrade to Xenial with "isc-dhcp-client-noddns"
and both scenarios worked as expected for caribou and I. (See comment #42)
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
I did the split such that Trusty users will automatically get "isc-dhcp-client-ddns" installed but users bothered by this bug will have the option to switch to "isc-dhcp-client-noddns".
Existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
Without isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Note that this is how Xenial does it.
Caribou and I, slashd, have also tested a couple of release upgrade from Trusty to Xenial with both scenarios :
1 - Trusty upgrade to Xenial with "isc-dhcp-client-ddns"
2- Trusty upgrade to Xenial with "isc-dhcp-client-noddns"
and both scenarios worked as expected for caribou and I. (See comment #42)
===
** Upgrade tested with isc-dhcp-client **
# dpkg -l
ii isc-dhcp-client 4.2.4-7ubuntu12.8 amd64 ISC DHCP client
ii isc-dhcp-common 4.2.4-7ubuntu12.8 amd64 common files used by all the isc-dhcp* packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:20114 0.0.0.0:* 632/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 632/dhclient
udp6 0 0 :::52249 :::* 632/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.3-5ubuntu12.7 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 633/dhclient
** Upgrade tested with isc-dhcp-noddns (4.2.4-7ubuntu12.9) **
# dpkg -l
ii isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 682/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
# dpkg -l | grep -i dhcp
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
rc isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
ii isc-dhcp-common 4.3.3-5ubuntu12.6 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 639/dhclient
===
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
|
| 2017-04-19 15:43:00 |
Eric Desrochers |
attachment added |
|
lp1176046_trusty.debdiff https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/+attachment/4864919/+files/lp1176046_trusty.debdiff |
|
| 2017-04-19 15:43:30 |
Eric Desrochers |
attachment added |
|
lp1176046_xenial.debdiff https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/+attachment/4864920/+files/lp1176046_xenial.debdiff |
|
| 2017-04-19 15:49:30 |
Eric Desrochers |
attachment removed |
lp1176046_xenial.debdiff https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/+attachment/4864920/+files/lp1176046_xenial.debdiff |
|
|
| 2017-04-19 15:51:02 |
Eric Desrochers |
attachment added |
|
lp1176046_xenial.debdiff https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/+attachment/4864921/+files/lp1176046_xenial.debdiff |
|
| 2017-04-19 15:58:37 |
Eric Desrochers |
description |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
I did the split such that Trusty users will automatically get "isc-dhcp-client-ddns" installed but users bothered by this bug will have the option to switch to "isc-dhcp-client-noddns".
Existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
Without isc-dhcp-client-ddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Note that this is how Xenial does it.
Caribou and I, slashd, have also tested a couple of release upgrade from Trusty to Xenial with both scenarios :
1 - Trusty upgrade to Xenial with "isc-dhcp-client-ddns"
2- Trusty upgrade to Xenial with "isc-dhcp-client-noddns"
and both scenarios worked as expected for caribou and I. (See comment #42)
===
** Upgrade tested with isc-dhcp-client **
# dpkg -l
ii isc-dhcp-client 4.2.4-7ubuntu12.8 amd64 ISC DHCP client
ii isc-dhcp-common 4.2.4-7ubuntu12.8 amd64 common files used by all the isc-dhcp* packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:20114 0.0.0.0:* 632/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 632/dhclient
udp6 0 0 :::52249 :::* 632/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.3-5ubuntu12.7 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 633/dhclient
** Upgrade tested with isc-dhcp-noddns (4.2.4-7ubuntu12.9) **
# dpkg -l
ii isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 682/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
# dpkg -l | grep -i dhcp
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
rc isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
ii isc-dhcp-common 4.3.3-5ubuntu12.6 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 639/dhclient
===
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
I did the split such that Trusty users will automatically get "isc-dhcp-client-ddns" installed but users bothered by this bug will have the option to switch to "isc-dhcp-client-noddns".
Existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client:
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
With isc-dhcp-client-noddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Note that this is how Xenial does it.
Caribou and I, slashd, have also tested a couple of release upgrade from Trusty to Xenial with both scenarios :
1 - Trusty upgrade to Xenial with "isc-dhcp-client-ddns"
2- Trusty upgrade to Xenial with "isc-dhcp-client-noddns"
and both scenarios worked as expected for caribou and I. (See comment #42)
Results :
===
** Upgrade tested with isc-dhcp-client **
# dpkg -l
ii isc-dhcp-client 4.2.4-7ubuntu12.8 amd64 ISC DHCP client
ii isc-dhcp-common 4.2.4-7ubuntu12.8 amd64 common files used by all the isc-dhcp* packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:20114 0.0.0.0:* 632/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 632/dhclient
udp6 0 0 :::52249 :::* 632/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.3-5ubuntu12.7 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 633/dhclient
** Upgrade tested with isc-dhcp-noddns (4.2.4-7ubuntu12.9) **
# dpkg -l
ii isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 682/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
# dpkg -l | grep -i dhcp
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
rc isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
ii isc-dhcp-common 4.3.3-5ubuntu12.6 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 639/dhclient
===
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
|
| 2017-04-19 16:01:06 |
Eric Desrochers |
description |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
I did the split such that Trusty users will automatically get "isc-dhcp-client-ddns" installed but users bothered by this bug will have the option to switch to "isc-dhcp-client-noddns".
Existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client:
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
With isc-dhcp-client-noddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Note that this is how Xenial does it.
Caribou and I, slashd, have also tested a couple of release upgrade from Trusty to Xenial with both scenarios :
1 - Trusty upgrade to Xenial with "isc-dhcp-client-ddns"
2- Trusty upgrade to Xenial with "isc-dhcp-client-noddns"
and both scenarios worked as expected for caribou and I. (See comment #42)
Results :
===
** Upgrade tested with isc-dhcp-client **
# dpkg -l
ii isc-dhcp-client 4.2.4-7ubuntu12.8 amd64 ISC DHCP client
ii isc-dhcp-common 4.2.4-7ubuntu12.8 amd64 common files used by all the isc-dhcp* packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:20114 0.0.0.0:* 632/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 632/dhclient
udp6 0 0 :::52249 :::* 632/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.3-5ubuntu12.7 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 633/dhclient
** Upgrade tested with isc-dhcp-noddns (4.2.4-7ubuntu12.9) **
# dpkg -l
ii isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 682/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
# dpkg -l | grep -i dhcp
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
rc isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
ii isc-dhcp-common 4.3.3-5ubuntu12.6 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 639/dhclient
===
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
I did the split such that Trusty users will automatically get "isc-dhcp-client-ddns" installed but users bothered by this bug will have the option to switch to "isc-dhcp-client-noddns".
Existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client:
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
With isc-dhcp-client-noddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Xenial also has both distinct dhclient binary package but in the opposite way. We have decided to use the opposite way approach for not impacting actual Trusty users by changing the nature of isc-dhcp-client itself.
Caribou and I, slashd, have also tested a couple of release upgrades from Trusty to Xenial with both scenarios :
1 - Trusty upgrade to Xenial with "isc-dhcp-client-ddns"
2 - Trusty upgrade to Xenial with "isc-dhcp-client-noddns"
and both scenarios worked as expected for caribou and I. (See comment #42)
Results :
===
** Upgrade tested with isc-dhcp-client **
# dpkg -l
ii isc-dhcp-client 4.2.4-7ubuntu12.8 amd64 ISC DHCP client
ii isc-dhcp-common 4.2.4-7ubuntu12.8 amd64 common files used by all the isc-dhcp* packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:20114 0.0.0.0:* 632/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 632/dhclient
udp6 0 0 :::52249 :::* 632/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.3-5ubuntu12.7 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 633/dhclient
** Upgrade tested with isc-dhcp-noddns (4.2.4-7ubuntu12.9) **
# dpkg -l
ii isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 682/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
# dpkg -l | grep -i dhcp
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
rc isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
ii isc-dhcp-common 4.3.3-5ubuntu12.6 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 639/dhclient
===
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
|
| 2017-04-19 16:31:26 |
Eric Desrochers |
description |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
I did the split such that Trusty users will automatically get "isc-dhcp-client-ddns" installed but users bothered by this bug will have the option to switch to "isc-dhcp-client-noddns".
Existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client:
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
With isc-dhcp-client-noddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Xenial also has both distinct dhclient binary package but in the opposite way. We have decided to use the opposite way approach for not impacting actual Trusty users by changing the nature of isc-dhcp-client itself.
Caribou and I, slashd, have also tested a couple of release upgrades from Trusty to Xenial with both scenarios :
1 - Trusty upgrade to Xenial with "isc-dhcp-client-ddns"
2 - Trusty upgrade to Xenial with "isc-dhcp-client-noddns"
and both scenarios worked as expected for caribou and I. (See comment #42)
Results :
===
** Upgrade tested with isc-dhcp-client **
# dpkg -l
ii isc-dhcp-client 4.2.4-7ubuntu12.8 amd64 ISC DHCP client
ii isc-dhcp-common 4.2.4-7ubuntu12.8 amd64 common files used by all the isc-dhcp* packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:20114 0.0.0.0:* 632/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 632/dhclient
udp6 0 0 :::52249 :::* 632/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.3-5ubuntu12.7 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 633/dhclient
** Upgrade tested with isc-dhcp-noddns (4.2.4-7ubuntu12.9) **
# dpkg -l
ii isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 682/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
# dpkg -l | grep -i dhcp
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
rc isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
ii isc-dhcp-common 4.3.3-5ubuntu12.6 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 639/dhclient
===
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
[Impact]
In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality.
The DDNS functionnality, generate 2 random extra ports between 1024-65535.
Impact reported by users :
"One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown."
"We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports."
There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization.
There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time.
I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing.
Xenial has separated dhclient in two packages :
isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports)
isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports)
The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality.
[Test Case]
Run a Trusty image with following package :
isc-dhcp-client
isc-dhcp-common
```
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
```
[Regression Potential]
I did the split such that Trusty users will automatically get "isc-dhcp-client-ddns" installed but users bothered by this bug will have the option to switch to "isc-dhcp-client-noddns".
Existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention.
With isc-dhcp-client:
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <----------- extra random port
dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <----------- extra random port
With isc-dhcp-client-noddns :
dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc
Xenial also has both distinct dhclient binary package but in the opposite way. We have decided to use the opposite way approach for not impacting actual Trusty users by changing the nature of isc-dhcp-client itself.
Caribou and I, slashd, have also tested a couple of release upgrades from Trusty to Xenial with both scenarios :
1 - Trusty upgrade to Xenial with "isc-dhcp-client-ddns"
2 - Trusty upgrade to Xenial with "isc-dhcp-client-noddns"
and both scenarios worked as expected for caribou and I. (See comment #42)
Results :
===
** Upgrade tested with isc-dhcp-client **
# dpkg -l
ii isc-dhcp-client 4.2.4-7ubuntu12.8 amd64 ISC DHCP client
ii isc-dhcp-common 4.2.4-7ubuntu12.8 amd64 common files used by all the isc-dhcp* packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:20114 0.0.0.0:* 632/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 632/dhclient
udp6 0 0 :::52249 :::* 632/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.3-5ubuntu12.7 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep -i dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 633/dhclient
** Upgrade tested with isc-dhcp-noddns (4.2.4-7ubuntu12.9) **
# dpkg -l
ii isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 682/dhclient
After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2)
# dpkg -l | grep -i dhcp
ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64 DHCP client for automatically obtaining an IP address
rc isc-dhcp-client-noddns 4.2.4-7ubuntu12.9 amd64 Dynamic DNS (DDNS) disabled DHCP client
ii isc-dhcp-common 4.3.3-5ubuntu12.6 amd64 common files used by all of the isc-dhcp packages
# netstat -anputa | grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 639/dhclient
===
For ~ubuntu-sru, the above tests/scenarios will also be part of the testing phase once the package will be found in -proposed and I'll make sure they all succeed before tagging the bug to "verfication-done".
[Other Info]
* See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU.
[Original Description]
Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter.
dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system.
Initial research of the code also suggested omapi, but adding omapi port 9999 to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled.
Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results.
Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10&t=95273&p=495605#p495605
One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown.
Example netstat -lnp output:
udp 0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient
udp6 0 0 :::45664 :::* 2659/dhclient |
|
| 2017-04-19 19:06:04 |
Eric Desrochers |
isc-dhcp (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2017-04-19 19:06:07 |
Eric Desrochers |
isc-dhcp (Ubuntu Xenial): assignee |
|
Eric Desrochers (slashd) |
|
| 2017-05-24 14:21:24 |
Eric Desrochers |
isc-dhcp (Ubuntu Xenial): status |
Fix Released |
In Progress |
|
| 2017-05-25 12:27:20 |
Robie Basak |
isc-dhcp (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2017-05-25 12:27:23 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-05-25 12:27:27 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2017-05-25 12:27:33 |
Robie Basak |
tags |
trusty |
trusty verification-needed |
|
| 2017-05-25 12:28:40 |
Robie Basak |
isc-dhcp (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-05-29 13:41:42 |
Eric Desrochers |
tags |
trusty verification-needed |
trusty verification-done-trusty verification-needed-xenial |
|
| 2017-05-29 15:04:42 |
Eric Desrochers |
tags |
trusty verification-done-trusty verification-needed-xenial |
trusty verification-done-trusty verification-done-xenial |
|
| 2017-05-29 22:13:52 |
Eric Desrochers |
bug task deleted |
isc-dhcp (Ubuntu Yakkety) |
|
|
| 2017-06-01 14:37:06 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-06-01 14:37:04 |
Launchpad Janitor |
isc-dhcp (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2017-06-01 14:37:24 |
Launchpad Janitor |
isc-dhcp (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
