Project

General

Profile

Actions

Bug #6430

open

pfsense should sanity-check hostnames when copying from dhcpd.leases to /etc/hosts

Added by Criggie . over 8 years ago. Updated over 5 years ago.

Status:
Confirmed
Priority:
Low
Assignee:
-
Category:
DNS Resolver
Target version:
-
Start date:
05/31/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

Description

Background - I was troubleshooting something and did a dig of localhost.

@aLinuxServer ~ $ dig localhost
...
;; QUESTION SECTION:
;localhost. IN A

;; ANSWER SECTION:
localhost. 1 IN A 127.0.0.1
localhost. 1 IN A 10.3.3.216
@

For some reason pfsense was replying back with a local LAN IP address for localhost as well as the proper address.

In /etc/hosts were these lines:

[2.2.6-RELEASE][root@pfsense.abc.local]/conf: grep localhost /etc/hosts
127.0.0.1 localhost localhost.abc.local
::1 localhost localhost.abc.local
10.3.3.216 localhost.abc.local localhost # dynamic entry from dhcpd.leases

We found that yesterday there had been a wireless client with a client-hostname of "localhost"

In /var/dhcpd/var/db/dhcpd.leases there's this stanza
lease 10.3.3.216 {
starts 2 2016/05/31 19:33:17;
ends 3 2016/06/01 07:24:57;
tstp 3 2016/06/01 07:24:57;
cltt 2 2016/05/31 19:33:17;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet c0:bd:d1:20:6e:19;
uid "\001\300\275\321 n\031";
option agent.circuit-id 0:0:0:0;
option agent.remote-id f0:7f:6:9d:f3:40;
client-hostname "localhost";
}

So my suggestion is not to blindly copy data from dhcpd.leases to /etc/hosts.

Threat cases

A host called wpad adding another IP to an existing WPAD record, and then some/all windows clients using it as a proxy. I have tested and confirmed this with a spare win10 tablet and it started receiving multiple port 80 requests for http://wpad.abc.local/proxy.pac and http://wpad.abc.local/wpad.dat

A host presenting a client-hostname of "google.com" and then intercepting all web traffic, doing a MITM attack. Windows didn't allow a . in the machine's hostname, but it sounds possible.

In our case this was not malicious by the user.

Suggested Solution

  • Maintain a list of keywords which should not be copied from dhcp leases to /etc/hosts
  • Filter out any hostnames that have non-permitted characters like newlines or brackets or quotes, or unicode.
    From RFC952: A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), and minus sign (-). The period (.) may be used to separate parts of a FQDN but must not otherwise appear in the "name"
Actions #1

Updated by Chris Buechler over 8 years ago

  • Status changed from New to Confirmed
  • Priority changed from Normal to Low
  • Affected Version set to All

It ought to ignore at least localhost and the system's own hostname.

the second suggestion is already done by dhcpleases.

Actions #2

Updated by Jim Pingle over 5 years ago

  • Category set to DNS Resolver
Actions

Also available in: Atom PDF