[Dnsmasq-discuss] DHCP Denial-of-Service

[Simon Kelley]

Luca Landi wrote:
> Hello Simon,
> 
> You know the 3 seconds wait for a pong (ping reply) during which dnsmasq 
> remains deaf to other DHCP requests? according to your comments around the 
> icmp_ping() function in dnsmasq.c it seems to be sort of "deliberate known 
> problem" and considering that it can lead to denial of service I was 
> wondering what the rationale has been behind your decision to leave dnsmasq 
> deliberately deaf to DHCP during those 3 seconds.

It's done like that because the DHCP code is not re-entrant. Another 
DHCP request arriving during the wait would overwrite the state 
associated with the existing DHCP request (specifically, the packet 
buffer.) It would be possible to change that, by dynamically allocating 
a new packet buffer for each request, and a few other changes. The 
problem than is that it introduces a new DoS by sending many requests 
and running dnsmasq out of memory.

In general, the DHCP protocol is impossible to secure against machines 
on the local net which want to break things, either by bombarding the 
server with requests, or acting as a rogue server and sending malicious 
replies. The trust model for DHCP really requires everything in the 
broadcast domain to co-operate.
> 
> In case you can't see how that can lead to DoS I'm going to describe the 
> scenario: a malicious DHCP client could exploit that dnsmasq's behavior by 
> just sending continuous (apparently legitimate) discovery requests which 
> make dnsmasq always compute the same IP address for which, of course, no 
> host responds to pings; this way the socket's receive buffer of UDP port 68 
> gets filled by those discovery requests because dnsmasq serves them at the 
> slow rate of one every 3 seconds and when other legitimate requests arrive 
> they just enter that very long queue and end up being served really too 
> late, thus leading to the overall DoS. Actually there's not even need for a 
> real flood of requests: all the malicious client needs to do to make that 
> happen sooner or later is to send just one request every 1 or 2 seconds; 
> this was my actual case due to a VoIP phone with buggy firmware which just 
> ignores dnsmasq's offers and keeps sending discovery requests.
> 

Whilst it's not easy to defend against a malicious attacker, it should 
be possible to improve things in this case, which must be fairly common. 
Maybe something like just caching the last result for 30 seconds or so, 
so that subsequent requests to check the same IP return immediately if 
nothing replied to the ARP request last time. Does that sound sensible?

> Thank you, cheers,
> Luca
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>