I can't answer your question about if this has been fixed, as there's
not enough information to identify the problem or trigger the bug.

Can you provide  proof-concept code, or even just packet captures of the
malformed packets that cause problems?

I've confused by the "dhcp to be unresponsive from
the switch for a small amount of time." observation. What's happening
here? Note that dnsmasq can queue DHCPDISCOVER requests whilst is if
doing address-in-use testing. If that's causing the unresponsiveness
then it's expected and there are mitigations in place to avoid DOS. If,
on the other hand, the malformed packets are crashing dnsmasq and some
daemon-framework is restarting it, that's bad, and we'd like to know
about it.



Cheers

Simon.



On 10/12/2018 05:59, P, Sreelakshmi wrote:
> Hi All,
> 
>  
> 
> Does anyone has any update on this?
> 
>  
> 
> Thanks!
> 
>  
> 
> *From:* P, Sreelakshmi
> *Sent:* Friday, December 7, 2018 4:19 PM
> *To:* 'dnsmasq-discuss@lists.thekelleys.org.uk'
> <dnsmasq-discuss@lists.thekelleys.org.uk>
> *Subject:* Validation for malformed DHCP packets in dnsmasq
> 
>  
> 
> Hi,
> 
>  
> 
> We are using dnsmasq 2.78. We see that there are some security
> vulnerability w.r.t malformed DHCP packets as explained below.
> 
>  
> 
> *_Problem 1:_*
> 
> A malformed dhcp discover packet can cause dhcp to be unresponsive from
> the switch for a small amount of time.  If this was repeated over time
> an attacker could make the dhcp service unresponsive DOSing the box. 
> 
>  
> 
> It starts out with the malformed discover immediately followed by a dhcp
> decline.  then the client sends another dhcp discover packet.  The
> switch does not respond to this discover. 
> 
> After about two seconds the client tries again and dhcp works as normal. 
> 
>  
> 
> *_Problem 2:_*
> 
> DHCP request with anomaly causing DOS condition
> 
>  
> 
> A Malformed DHCP request causes dhcp server to not respond for a short
> period of time.  The request is modified by reducing the size of the
> data in the mac address field in the dhcp request.
> 
> After the request is sent to the switch the client sends another dhcp
> discover which is not responded to.  After about 1.5 seconds the client
> tries again and the discover is responded to.
> 
>  
> 
> *_Problem 3:_*
> 
> DHCP discover packet with extra byte in hardware address causing DOS of
> DHCP on switch
> 
>  
> 
> If an extra byte is added to the hardware address field in a dhcp
> discover it will cause the DHCP service to become unresponsive for a
> short period of time.  If repeated it could be used as a DOS attack.
> 
>  
> 
> *_Problem 4:_*
> 
> DHCPv6 solicit with anomaly in Identity association length field causing DOS
> 
>  
> 
> When the integer value 65534 is placed in the Identity association
> length field of a dhcpv6 solicit packet the switch enters a DOS state
> for a couple seconds
> 
>  
> 
> *_Problem 5:_*
> 
> DHCPv6 solicit 2 Extra bytes trailing option status code causes DOS
> 
>  
> 
> Sending dhcpv6 solicits with extra bytes trailing the option status code
> causes the switch dhcp server to become temporarily unresponsive.
> 
>  
> 
> In a summary, to overcome this problem, DHCP packet validation has to be
> done. Has any fix related to any of these problems have gone in after 2.78?
> 
>  
> 
> Thanks in Advance!!
> 
>  
> 
> Regards,
> 
> Sree
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to