Ubuntu
isc-dhcp package

DHCP Transaction ID (xid) is logged with INFO loglevel

Bug #1717476 reported by Sven Blumenstein
264
This bug affects 1 person
Affects Status Importance Assigned to Milestone
isc-dhcp (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

The patch dhcp-4.2.4-improved-xid.patch (https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141) added logging of the Transaction ID (xid) to dhclient:

- log_info ("DHCPACK from %s", piaddr (packet -> client_addr));
+ log_info ("DHCPACK from %s (xid=0x%x)", piaddr (packet -> client_addr), client -> xid);
- log_info ("DHCPNAK from %s", piaddr (packet -> client_addr));
+ log_info ("DHCPNAK from %s (xid=0x%x)", piaddr (packet -> client_addr), client -> xid);
- log_info ("DHCPDISCOVER on %s to %s port %d interval %ld",
+ log_info ("DHCPDISCOVER on %s to %s port %d interval %ld (xid=0x%x)",
- log_info ("DHCPREQUEST of %s on %s to %s port %d",
+ log_info ("DHCPREQUEST of %s on %s to %s port %d (xid=0x%x)",
- log_info ("DHCPDECLINE on %s to %s port %d",
+ log_info ("DHCPDECLINE on %s to %s port %d (xid=0x%x)",
- log_info ("DHCPRELEASE on %s to %s port %d",
+ log_info ("DHCPRELEASE on %s to %s port %d (xid=0x%x)",

Under certain circumstances, this can lead to the xid being leaked to remote machines (syslog) or visible to unprivileged users.

Having the xid, it is possible to flood a target machine with DHCPACK replies and spoof a upcoming DHCPREQUEST answer (Proof of concept avail on request).

I would not say this is a direct security issue, but more of a potential information disclosure and could lead to an issue in combination with other factors (e.g. syslog files of a target machine are accessible to an attacker). Still I don't see why this logging of xid is necessary and would recommend to either:

- remove logging of the xid entirely
- only log xid in log level DEBUG

This issue was confirmed to be in place for the the most recent version of isc-dhcp-client shipped with Ubuntu 17.04. (4.3.5-3ubuntu1).

Note: this patch is not included in the Debian package of isc-dhcp-client (https://packages.debian.org/stretch/isc-dhcp-client), therefor this issue does only affect Ubuntu.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hi Sven,

I'm not sure what the next step should be.

This does appear to affect others (the DEP-3 tags in this patch indicates
it came from Fedora
http://pkgs.fedoraproject.org/cgit/rpms/dhcp.git/tree/dhcp-improved-xid.patch )
and several of the other patches in 4.2.4-7ubuntu14.1 indicated that
printing xid's exists beyond just this one patch.

xids appear to be generated through random():
http://sources.debian.net/src/isc-dhcp/4.3.5-3/client/dhclient.c/#L1073

If these can be generated with such a poor quality generator are we
confident this is a security issue? Afterall guessing this seed value
shouldn't be too difficult:
http://sources.debian.net/src/isc-dhcp/4.3.5-3/client/dhclient.c/#L715

.. and probably being able to find four xids would be enough to crack the
random() generator even without the seed. Probably a few minutes with
ethtool to get new MACs on an interface would be sufficient.

Do you know if there are upstream bugs filed with ISC for these issues?

Thanks

Revision history for this message
Sven Blumenstein (svbl) wrote :

Hi Seth,

I don't know about any upstream bug and I also agree on the weakness of the RNG used. Depending on how dhclient is used, the RNG isn't the worst part though. If you manually invoke it, the XID is obviously different and hard to predict every time. If it is spawned by NetworkManager though, it runs as daemon in the background and the XID is only generated once, which makes a brute-force attempt more feasible. I agree, there should probably be a separate bug for improving the RNG to generate XID's.

But of course having the XID potentially leaked through log files makes the issues with the RNG obsolete. So I am wondering if there is a legitimate reason why the XID is logged at INFO level at all?

Revision history for this message
Sven Blumenstein (svbl) wrote :

JFYI, I opened an issue with ISC, they are currently triaging the report.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Can I make this bug public?

Revision history for this message
Sven Blumenstein (svbl) wrote :

I pinged the ISC twice because they did not react in two months. They did reply once and asked to keep this need-to-know until they decided if it is a security issue or not. Apparently that takes a long while... I pinged them again to speed up the process.

Revision history for this message
Sven Blumenstein (svbl) wrote :

Still no reply from the ISC, and I pinged them like 10 times now. I don't mind if you mark this public.

Seth Arnold (seth-arnold)
information type: Private Security → Public Security
Revision history for this message
Vicky Risk (vicky-u) wrote :

Hi Sven - I just became aware of this because of your tweet. We (ISC) investigated this back in September and determined it was not present in ISC's distribution. Further, we felt it was not a significant security issue in any case. I haven't found any issue in our bug database with your name as reporter, however, so if you can tell me the bugID, I will make sure it is updated and closed. I sincerely apologize if we dropped the ball on updating you. If you would like to message me privately, I would also like to know what alias or ID you pinged so many times, because I suspect that ended up in a spam filter somewhere - at least I can't find it in our issue tracker. Thank you.

Revision history for this message
Sven Blumenstein (svbl) wrote :

Hi Vicky,

thanks for the reply! I'll send you the details privately.

Cheers

Marc Deslauriers (mdeslaur)
Changed in isc-dhcp (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.