On Sat, Dec 10, 2016 at 08:20:59PM -0000, Eric Desrochers wrote: > > What will happen to existing Trusty users who are relying on the > current ddns functionality? > > Existing Trusty user at next isc-dhcp-client pkg upgrade will > automatically receive (Recommends: isc-dhcp-client-ddns).
Currently (without this SRU), existing Trusty users will have DDNS-by-default dropped on a release upgrade to Xenial. Users who still need it would need to install isc-dhcp-client-ddns manually, which is acceptable in a release upgrade. This is a good thing for security, and so should continue to happen, right? If you get all users automatically receiving isc-dhcp-client-ddns in this SRU, then subsequently the users' behaviour after upgrade to Xenial will change. They will continue to have isc-dhcp-client-ddns installed, and so won't get the benefit of this improvement. > And for users bother by the extra random port they will simply have to > apt-get purge isc-dhcp-client-ddns. This part sounds like it'll work well then, but I'm not sure about the change in release upgrade behaviour above. In comment #20, you said that there doesn't seem to be a way to disable DDNS at runtime in Trusty. But this is presumably based on the upstream-shipped build configuration. How difficult would it be to do by patching the code? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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: In Progress Status in isc-dhcp source package in Trusty: In Progress 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
