dhclient leaks sys-net boot time within DUID-LLT in Client-ID option of DHCP request

[hopefulfork]

Qubes OS version: R3.2

Affected TemplateVMs: fedora-23

Currently dhclient in sys-net uses DUID-LLT scheme [rfc-3315], section 9.2. As dhclient doesn't have persistent storage, this procedure is performed at each boot. This results in leaking time value that is represented in seconds since midnight (UTC), January 1, 2000, modulo 2^32.

Consequences:

1. Security: leak of system boot time may help with some kinds of attacks. For example, it may be used to help guessing seeds of some random number generators (e.g. simple ones that use time to seed themselves).

2. Privacy: this leak may be used to identify Qubes system in a network - its time part in DUID-LLT will very often be close to current time, unlike other systems.

tcpdump from sys-net (second part of MAC is spoofed, oui part is hidden as XX:YY:ZZ):

09:43:45.380378 EAPOL key (3) v2, len 117
09:43:45.380813 EAPOL key (3) v1, len 117
09:43:45.396282 EAPOL key (3) v2, len 151
09:43:45.404394 EAPOL key (3) v1, len 95
09:43:45.752094 IP6 (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff50:9af1 to_ex { }]
09:43:46.048415 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from XX:YY:ZZ:50:9a:f1 (oui Unknown), length 300, xid 0x2e1b1036, Flags [none] (0x0000)
	  Client-Ethernet-Address XX:YY:ZZ:50:9a:f1 (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    Parameter-Request Option 55, length 18:
	      Subnet-Mask, BR, Time-Zone, Classless-Static-Route
	      Domain-Name, Domain-Name-Server, Hostname, YD
	      YS, NTP, MTU, Option 119
	      Default-Gateway, Classless-Static-Route, Classless-Static-Route-Microsoft, Static-Route
	      Option 252, NTP
	    Client-ID Option 61, length 19: hardware-type 255, ZZ:50:9a:f1:00:01:00:01:1f:d5:50:52:XX:YY:ZZ:50:9a:f1

Time is encoded here as 1f:d5:50:52, that corresponds to ~16.9 years since 2000 (yestarday).

Expected behavior:

For systems without persistent storage DUID-LL should be used; this is very similar to DUID-LLT but does not include time - [rfc-3315], section 9.4. [rfc-4361], sections 6.1, 6.2 also basically confirms [rfc-3315].

Note: alternative solution, adding persistent storage for DUID in sys-net will break MAC randomization feature as this will expose MAC as part of DUID.

Steps to reproduce the behavior:

1. Boot into Qubes
2. Disconnect network in sys-net (if connected)
3. Start tcpdump in sys-net, e.g. "tcpdump -i wlp0s0 -vv > dump1.txt" (replace interface name with your own)
4. Connect to some wireless network (using NetworkManager applet)
5. Stop tcpdump in sys-net
6. Reboot (can just shutdown all dependent VMs and reboot sys-net)
7. Repeat steps 1-5, using dump2.txt
8. Compare dump1.txt and dump2.txt - see the difference in Client-ID part

References

[rfc-3315] https://tools.ietf.org/html/rfc3315
[rfc-4361] https://tools.ietf.org/html/rfc4361