DHCP support (TITLE LENGTH EXTENDED)

[phabricator-migrator]

Information

ID: 239
PHID: PHID-TASK-ir3ccaskoe63igdu2ir5
Author: Patrick
Status at Migration Time: open
Priority at Migration Time: Normal

Description

Latest considerations on DHCP:

Dev/DHCP

Main TODO for now:

• Does DHCP have some feature which a compromised Whonix-Workstation could abuse? Does DHCP have a feature such as “tell me the IP of your upstream router”?
  ** TODO: Read this stuff…
  *** https://www.ietf.org/rfc/rfc2131.txt
  *** Dynamic Host Configuration Protocol - Wikipedia

Forum discussion:

DHCP Server on the Gateway

May you please provide some more specific information here (if available to you)? Thanks!

Help welcome.

Comments

---

HulaHoop

2015-03-19 23:59:32 UTC

Running a DHCP on the gateway is bad for many reasons.

The default DHCP daemon was vulnerable to shellshock because it uses environment variables.

Address exhaustion attacks by a malicious workstation can disrupt other workstations even if they are on different internal networks because they share the same server. Unfortunately this is a protocol deficiency and is not going away anytime soon.

KVM supports giving each internal network its own simplified dhcp server and address range.

---

Patrick

2015-03-20 09:05:27 UTC

Won’t become a standard feature. Optional. Anything that works for #data_center_support.

---

HulaHoop

2016-03-14 02:19:46 UTC

From what I see DHCP servers have their own DNS resolver set by default and pass queries recursively upstream if they cannot answer it for whatever reason.

Domain Name System - Wikipedia

such a user will either have configured that server’s address manually or allowed DHCP to set it; however, where systems administrators have configured systems to use their own DNS servers, their DNS resolvers point to separately maintained name servers of the organization. In any event, the name server thus queried will follow the process outlined above, until it either successfully finds a result or does not.

libvirt: Network XML format

The name attribute on the domain element defines the DNS domain of the DHCP server. This element is optional, and is only used for those networks with a mode of “nat” or “route” (or an isolated network with no element). Since 0.4.5

If the optional localOnly attribute on the domain element is “yes”, then DNS requests under this domain will only be resolved by the virtual network’s own DNS server - they will not be forwarded to the host’s upstream DNS server. If localOnly is “no”, and by default, unresolved requests will be forwarded. Since 1.2.12

---

Patrick

2016-03-14 17:00:10 UTC

This is a huge task. Reading all the protocol and protocol extensions.
Plus DHCP server documentation and possibly source code.

If someone wants to help with this…

1. get an overview of available DHCP servers in Debian
2. pick the more minimal ones
3. ask the developers of the DHCP server if they work or can be
   configured to work with Whonix’s threat model [1] [2]

---

[1] No IP discovery from the workstation, no clearnet DNS leaks.
[2] be simple as in only provide IP addressed to workstations that
connect, no other fancy features

---

HulaHoop

2016-03-15 02:15:06 UTC

The DHCP functionality in Libvirt can be customized to stop that harmful behavior as documented. A generic DHCP package will run into the problems described here however.

At least now we know what the limitations are.

---

HulaHoop

2016-09-24 00:56:02 UTC

Why do we insist on running the server on the GW? It will always increase attack surface. Alternatively I think its fine if it runs on Workstation-zero where other new cloned WSs on the internal network can bootstrap from.

pydhcplib is the best choice for client/server combo because its memory safe.

---

Patrick

2016-09-24 05:24:31 UTC

Alternatively I think its fine if it runs on Workstation-zero where other new cloned WSs on the internal network can bootstrap from.

I don’t understand?

Why do we insist on running the server on the GW? It will always
increase attack surface.

Good question. Has long not been reconsidered. In past perhaps because
of physical isolation, but that would not count anymore nowadays.

Virtualizer specific. Some comments here:

whonix-gw-network-conf/etc/network/interfaces.d/30_non-qubes-whonix at master · Whonix/whonix-gw-network-conf · GitHub

• VirtualBox: as per comments, seams doable.
• KVM: no idea
• Qubes: does not need this

So if I make it work for VirtualBox, I wouldn’t know if the same config
would work for KVM. In case of VirtualBox, I don’t remember if it caused
conflicts with real LAN, other VMs or cloned Whonix-Gateways.

pydhcplib is the best choice for client/server combo because its memory safe.

Yes, memory safe language would be nice. However, that’s a lib, not a
binary. If you can make it work, we can consider it.

---

HulaHoop

2016-09-24 12:39:10 UTC

There is the original WS with IP 10.152.152.11. Why not turn it into a DHCP server for any new clones added to the internal network?

A clone when it boots up checks for DHCP requests and disables its own server copy if it detects and sets a dynamic IP.

I don’t remember if it caused conflicts with real LAN, other VMs or cloned Whonix-Gateways.

What kind of conflicts? Could you fool the Gateway filtering rules with spoofed IPs?

However, that’s a lib, not a binary. If you can make it work, we can consider it.

I’ll look into it.

---

Patrick

2016-09-24 14:03:42 UTC

I messed that up. My last comment T239#10445 was an answer for T559 - please scratch my last comment.

---

Moving the DHCP server to another place than Whonix-Gateway, one that doesn’t know its own real external IP address, is a good idea.

There are some challenges:

• How does the original Whonix-Workstation know it is the original Whonix-Workstation and not number two or a clone?
• I am not yet convinced, that a Whonix-Workstation as currently defined is a proper place for that. That is kinda a strange idea.

Imagine a data center. Many workstations, many wires to Whonix-Gateway. How would they connect to the master workstation for DHCP? That seems strange.

Perhaps for data center support, two gateway would be better. A Whonix-Workstation → Whonix-DHCP-Server → Whonix-Gateway.

So a Whonix-Workstation master that runs a DHCP server would not really work for data center support. It’s still an interesting for VirtualBox / KVM.

---

HulaHoop

2016-09-25 02:31:46 UTC

How does the original Whonix-Workstation know it is the original Whonix-Workstation and not number two or a clone?

Good question. The way this happens is pydhcp listens to the network to see if there are any DHCP packets broadcasted and parses it. If it does not detect anything (in case of master WS) it assumes the role of the server and starts broadcasting. The good thing about this is network DHCP server is auto-replaced if master WS goes down for any reason. There should be a sufficiently long interval for checking to allow a comfortable race condition.

When subordinate WSs detect DHCP packets they immediately override the hardcoded static IP and only keep client functionality on.

I am not yet convinced, that a Whonix-Workstation as currently defined is a proper place for that. That is kinda a strange idea.

Its not unreasonable given that enabling DHCP for internal networks means DNSMASQ instance on the host is used to communicate with high risk VMs. My goal is fix usability problems while not risking anything more than we have to.

IMO though the multi WS behind a GW is not as critical a usecase because one must assume that these VMs are of the same trust level which would not justify the extra resources needed to spin them up. - might as well use the same WS then. The proper way is to have different GW-WS pairs to isolate activities. So I don’t think this particular ticket is a good investment of time if its difficult.

Imagine a data center. Many workstations, many wires to Whonix-Gateway. How would they connect to the master workstation for DHCP? That seems strange.

It could work for physical isolation builds supposing they are wired to the same switch (equivalent of an internal net I guess)

---

HulaHoop

2016-09-30 19:39:52 UTC

From my tests in the other ticket:

Tested that multiple GWs using the same static ip works. No documentation changes needed for that.

Since this is true for the external net then multiple identical static ips on inet should work without conflicting too (without DHCP support at all). The reason multi-WS isn’t working has something to do with cpfp limitations in answering multiple WS requests I think.

---

HulaHoop

2016-09-30 21:13:20 UTC

Tests confirm that TBB on multi-WSs work without changing the static IP. Timesync on both VMs finishes successfully. TPO check reports the same IP in both TBB instances. The problems I see is Tor Button is confused and reports Tor is not working and New identity sometimes hangs with a “cannot connect to controlport to change IP”

---

Patrick

2016-10-01 16:57:27 UTC

I don’t know. May work. Sounds rather difficult. At the moment I cannot even think this through. #data_center_support currently is no focus to me. No prospective sponsor for this at the moment. And we don’t have anyone who would actually implement this anyhow at the moment.

If someone wanted #data_center_support, I’d probably also not implement this one and rather go for Qubes-Whonix. That seems a lot more manageable for #data_center_support. It can service many ws behind the same gw without need for any dhcp. And it has qrexec, a service service that allows to easily and securely copy around files from one VM to another. And allows to run commands inside a VM, invoked from outside a VM. All controlled by policy which VM can control which other VM.

A data center that wanted to provide custom Tor hidden services for clients had various options available to script this.

DHCP support would have been interesting to more easily support multi ws behind same gw. (T567) But since the increased attack surface, probably a better solution has to be found to simplify this. Would perhaps not be that hard. Just each ws needs a unique IP. That must be doable somehow. We could just go for a random IP and hope that is not used by another ws. Or ask the user for a unique number for the VM in a specific range and then automatically adjust it. Worth another ticket.

! In T239#10619, @HulaHoop wrote:
The reason multi-WS isn’t working has something to do with cpfp limitations in answering multiple WS requests I think.

It should be perfectly capable to do this. If not, there is very good chance it will in Whonix 14.

---

HulaHoop

2016-11-12 21:08:43 UTC

For the record:

Fact. AFL uncovered many serious 0days in the DHCP server reference implementation.

isc-dhcp

ISC Dhcp : Security vulnerabilities, CVEs

Especially CVE-2009-0692 : Stack-based buffer overflow in the script_write_params method in client/dhclient.c in ISC DHCP dhclient 4.1 before 4.1.0

---

dnsmasq

How I nearly almost saved the Internet, starring afl-fuzz and dnsmasq | SkullSecurity Blog