[Bug 1176046] Re: isc-dhcp dhclient listens on extra random ports
Robie Basak
1176046 at bugs.launchpad.net
Mon Dec 19 11:37:56 UTC 2016
Let me try and restate this in detail to make sure I understand it.
Trusty: add a new binary package called isc-dhcp-client-noddns. This
will work the same as isc-dhcp-client-ddns in Xenial, but in reverse. It
will use the same dpkg-divert mechanism to provide a replacement
/sbin/dhclient that does not have the DDNS behaviour. Users must opt in
to it by installing this new package, so there should be no change in
behaviour to existing Trusty users and thus low regression risk.
Xenial: add a isc-dhcp-client-noddns transitional binary package that
deactivates the dpkg-divert and depends on isc-dhcp-client. "Default"
users upgrading from Trusty to Xenial are unaffected since they would
never have -noddns installed. Trusty users who had opted in to isc-dhcp-
client-noddns will transition to the Xenial isc-dhcp-client package that
provides no DDNS. Trusty users who are using isc-dhcp-client and want to
keep the DDNS support need to install isc-dhcp-client-ddns in Xenial, as
before. So no change in behaviour for any use case.
One thing that will need testing is upgrade ordering from Trusty to
Xenial with respect to the divert. For example, what if I am using isc-
dhcp-client-noddns and ask apt to upgrade me and add isc-dhcp-client-
ddns at the same time? Will the overlapping dpkg-diverts behave
themselves?
I don't see any problem with this approach, though it does require new
binaries in both Trusty and Xenial, which is a little ugly especially
for Xenial as there isn't a bug in Xenial currently. I'd appreciate
input from another SRU team member on this proposal.
I haven't reviewed your debdiff in detail - let's get general agreement
that this is a sensible approach first to avoid any wasted effort. But I
did notice:
> +++ isc-dhcp-4.2.4/debian/changelog
> + isc-dhcp-client : dhclient with DDNS functionality enabled
Perhaps add "(no behavioural change from previous version)" or
something, to make it clear to existing users seeing the SRU changelog
that they don't need to panic? Just noting for the future; no need to do
anything now. I think we should get an ack on the approach from ~ubuntu-
sru before proceeding further.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1176046
Title:
isc-dhcp dhclient listens on extra random ports
Status in isc-dhcp package in Ubuntu:
Fix Released
Status in isc-dhcp source package in Trusty:
In Progress
Status in isc-dhcp source package in Xenial:
Fix Released
Status in isc-dhcp source package in Yakkety:
Fix Released
Bug 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/+subscriptions
More information about the foundations-bugs
mailing list