Bug #7688: DHCP client leaks hostname "amnesia"

Bug #7688

DHCP client leaks hostname "amnesia"

Added by sajolida 2014-07-29 20:53:37 . Updated 2014-09-02 05:15:59 .

Status:

Resolved

Priority:

High

Assignee:

Category:

Target version:

Tails_1.1.1

Start date:

2014-08-10

Due date:

% Done:

100%

Feature Branch:

bugfix/7688-no-dhcp-send-hostname

Type of work:

Code

Blueprint:

Starter:

Affected tool:

Deliverable for:

Description

1. Boot Tails 1.1.
2. Install Wireshark.
3. Monitor the network until a periodic
DHCP refresh is done.
4. Click on the “DHCP Request” packet
going out to the local router/gateway/dhcp-server.

In the data in the packet one can see:

Bootstrap Protocol
Message type: Boot Request (1)
[…]
Option: (12) Host Name
Length: 7
Host Name: amnesia
[…]

In earlier Tails versions the hostname was not leaked, so this is a regression.

Subtasks

Bug #7769: Resets hostname to the one provided by the DHCP server

Resolved

intrigeri

100

Related issues

Related to Tails - Feature #5655: Share username and hostname amongst all anonymity distributions	Confirmed	2016-03-17
Related to Tails - ~~Feature #7712~~: Automatically test hostname leaks	Resolved	2014-08-01

History

#1 Updated by intrigeri 2014-07-30 09:03:52

Target version set to Tails_1.1.1
Type of work changed from Code to Research

Tentatively flagged for 1.1.1, so that we have this security regression on our radar. And there’s no lead for a fix yet, so marking as needing research.

#2 Updated by BitingBird 2014-07-30 22:30:34

related to Feature #5655: Share username and hostname amongst all anonymity distributions added

#3 Updated by intrigeri 2014-07-31 18:05:43

(All that follows is valid on Wheezy. Not checked anything newer yet.)

NetworkManager runs dhclient with the -cf /var/run/nm-dhclient-eth0.conf option. That file contains send host-name "amnesia"; # added by NetworkManager, and is created by the nm_dhcp_dhclient_create_config function in src/dhcp-manager/nm-dhcp-dhclient-utils.c. Each connection has a dhcp-send-hostname setting (docs/api/html/ref-settings.html) that defaults to TRUE.

On the short term, simply commenting out the line that adds the line we don’t want should be enough.

As suggested on https://mail.gnome.org/archives/networkmanager-list/2014-January/msg00011.html, if using the “keyfile” plugin only (that is, after disabling the “ifupdown” one), adding this to /etc/NetworkManager/NetworkManager.conf seems to resolve the problem:

[ipv4]
dhcp-send-hostname=false

But:

I’m not sure what would be the consequences of disabling the “ifupdown” plugin. My understanding of https://wiki.gnome.org/Projects/NetworkManager/SystemSettings leads me to think it’s a complete no-op in our case, but this should be tested more thoroughly.
One also has to patch the system-wide dhclient.conf, since it contains send host-name = gethostname();, and its content is merged into the NM-generated dhclient config file.
I’ve not sniffed the network to confirm that doing all of the above is enough.

#4 Updated by intrigeri 2014-07-31 18:44:56

Status changed from Confirmed to In Progress
% Done changed from 0 to 10

#5 Updated by intrigeri 2014-07-31 20:49:18

Feature Branch set to bugfix/7688-no-dhcp-send-hostname
Type of work changed from Research to Code

Implemented the solution described above. The generated dhclient.conf looks good. Left to do:

~~sniff the network to confirm that the hostname is not sent over DHCP~~ (~~Feature #7712~~);
~~verify that it works for a manually added (e.g. Wi-Fi) network connection too~~ (~~Feature #7712~~);
~~verify that the resulting ISO generally works fine~~: passes the automated test suite;
~~verify that this solution also works on Jessie~~: works fine on current sid, verified with Wireshark;
~~write design documentation~~.