Re: [Dnsmasq-discuss] Validation for malformed DHCP packets in dnsmasq

2019-01-20 Thread P, Sreelakshmi
Hi Simon,

Thanks for the reply. Attached is the pcap file that contains malformed packet. 
Extra byte is added to client MAC address to make it malformed. 

This behavior was tested using a tool called Defensics generally used to find 
security vulnerability.

Regards,
Sree

-Original Message-
From: Dnsmasq-discuss [mailto:dnsmasq-discuss-boun...@lists.thekelleys.org.uk] 
On Behalf Of Simon Kelley
Sent: Monday, December 17, 2018 3:21 AM
To: dnsmasq-discuss@lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Validation for malformed DHCP packets in dnsmasq

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'
> 
> *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


DhcpDiscoverExtraByteInHeader.pcap
Description: DhcpDiscoverExtraByteInHeader.pcap


BUG_15134_DhcpDiscoverExtraByteInHeader.pcap
Description: BUG_15134_DhcpDiscoverExtraByteInHeader.pcap
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Validation for malformed DHCP packets in dnsmasq

2018-12-16 Thread Simon Kelley
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'
> 
> *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


Re: [Dnsmasq-discuss] Validation for malformed DHCP packets in dnsmasq

2018-12-10 Thread September 1993
On Mon, Dec 10, 2018 at 05:59:11AM +, P, Sreelakshmi wrote:
> Hi All,
> 
> Does anyone has any update on this?

Understanding http://www.catb.org/~esr/faqs/smart-questions.html
is a good start.
 
> Thanks!

For making it possible to read in the discussion order.

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


Re: [Dnsmasq-discuss] Validation for malformed DHCP packets in dnsmasq

2018-12-09 Thread P, Sreelakshmi
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' 

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] Validation for malformed DHCP packets in dnsmasq

2018-12-07 Thread P, Sreelakshmi
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