Re: [Dnsmasq-discuss] reproducible segmentation fault - bisected!

2017-08-28 Thread Christian Kujau 
On Mon, 28 Aug 2017, Kevin Darbyshire-Bryant wrote:
> My workaround is to only call memset if the difference between buffer begin
> and buffer limit is bigger than the query length, thus it retains Simon's
> intent of clearing memory most of the time but avoids the SIGSEGV trampling.

Thanks, with your patch dnsmasq doesn't crash anymore when receiving odd 
EDNS packets from dnseval.

And thanks for requesting the CVE - I thought about this too, as the bug 
constitutes some kind of DoS issue, but since nobody else complained, I 
suspected it to be some variation of PEBKAC on my part :)

Christian.
-- 
BOFH excuse #247:

Due to Federal Budget problems we have been forced to cut back on the number of 
users able to access the system at one time. (namely none allowed)

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

Re: [Dnsmasq-discuss] reproducible segmentation fault - bisected!

2017-08-28 Thread Christian Kujau 
On Mon, 28 Aug 2017, Christian Kujau wrote:
> On Mon, 28 Aug 2017, Kevin Darbyshire-Bryant wrote:
> > My workaround is to only call memset if the difference between buffer begin
> > and buffer limit is bigger than the query length, thus it retains Simon's
> > intent of clearing memory most of the time but avoids the SIGSEGV trampling.
> 
> Thanks, with your patch dnsmasq doesn't crash anymore when receiving odd 
> EDNS packets from dnseval.
> 
> And thanks for requesting the CVE - I thought about this too, as the bug 
> constitutes some kind of DoS issue, but since nobody else complained, I 
> suspected it to be some variation of PEBKAC on my part :)

Oh, I believe it was Juan Manuel requesting the CVE - thanks!

C.
-- 
BOFH excuse #247:

Due to Federal Budget problems we have been forced to cut back on the number of 
users able to access the system at one time. (namely none allowed)

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

Re: [Dnsmasq-discuss] reproducible segmentation fault - bisected!

2017-08-28 Thread Kevin Darbyshire-Bryant 



On 27/08/17 08:18, Christian Kujau wrote:

OK, so I should have done this in the first place and used git bisect to
find out which commit in Dnsmasq introduced this behaviour:

  fa78573778cb23337f67f5d0c9de723169919047 is the first bad commit
  commit fa78573778cb23337f67f5d0c9de723169919047
  Author: Simon Kelley 
  Date:   Fri Jul 22 20:56:01 2016 +0100

 Zero packet buffers before building output, to reduce risk
 of information leakage.



Hi Christian,

Thanks for all your investigation and info so far.  I too can now crash 
dnsmasq at will :-)   So putting my novice C and even more novice gdb to 
work I've come up with what I feel is a slightly less invasive 
mitigation to the problemwhich in essence is 'we've been sent a 
query but not yet allocated any buffer to it/updated the header limit 
offset but we pass a non zero query length.  The result is we try to 
clear the memory before our buffer.


My workaround is to only call memset if the difference between buffer 
begin and buffer limit is bigger than the query length, thus it retains 
Simon's intent of clearing memory most of the time but avoids the 
SIGSEGV trampling.


This is to be regarded as a sticking plaster rather than real fix but 
that needs far greater minds than I to understand the code & intent :-)


Hope this helps someone.

Kevin


>From 340a26f915d8c3bb54c44f58d432cc7240631a74 Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant 
Date: Mon, 28 Aug 2017 14:52:10 +0100
Subject: [PATCH] dnsmasq: rfc1035: mitigate CVE-2017-13704

Work around a problem where answer_request() attempts to clear from the
end of a request to end of request buffer but the end of the buffer is
at the same place as the start.

Originally this meant that memset() tried to clear data before the
buffer leading to segmentation violation.  Instead only clear to end of
buffer it is bigger than the request length.

Signed-off-by: Kevin Darbyshire-Bryant 
---
 src/rfc1035.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/rfc1035.c b/src/rfc1035.c
index 26f5301..91a9641 100644
--- a/src/rfc1035.c
+++ b/src/rfc1035.c
@@ -1225,7 +1225,8 @@ size_t answer_request(struct dns_header *header, char *limit, size_t qlen,
 
   /* Clear buffer beyond request to avoid risk of
  information disclosure. */
-  memset(((char *)header) + qlen, 0, 
+  if ( (limit - ((char *)header)) > qlen )
+  memset(((char *)header) + qlen, 0,
 	 (limit - ((char *)header)) - qlen);
   
   if (ntohs(header->ancount) != 0 ||
-- 
2.7.4

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

Re: [Dnsmasq-discuss] reproducible segmentation fault

2017-08-28 Thread Kevin Darbyshire-Bryant 



On 28/08/17 09:27, Juan Manuel Fernandez wrote:

Hi,

Last weeks we were fuzzing dnsmasq and found this crash 
(https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg11597.html 
) . 
We tried to reach Simon on Friday but we have not had any response from 
him. We asked mitre for a CVE id and were assigned CVE-2017-13704.


Be aware that it's a bank holiday Monday here in the UK which means it's 
popular time to go away for a week or so with family/friends.  This may 
explain the lack of response so far.


Good that a CVE is assigned.  Even better you've got some example 
packets that induce the issue  :-)


In our original mail to Simon we attached two packets as examples: one 
that crash the application, and another where the memset is set to a 
lenght of 0 (making it useless).


Regards,
Juan Manuel Fernandez
Tarlogic


Cheers,

Kevin

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

Re: [Dnsmasq-discuss] reproducible segmentation fault

2017-08-28 Thread Juan Manuel Fernandez 
Hi,

Last weeks we were fuzzing dnsmasq and found this crash (
https://www.mail-archive.com/dnsmasq-discuss@lists.thekelle
ys.org.uk/msg11597.html) . We tried to reach Simon on Friday but we have
not had any response from him. We asked mitre for a CVE id and were
assigned CVE-2017-13704.


In our original mail to Simon we attached two packets as examples: one that
crash the application, and another where the memset is set to a lenght of 0
(making it useless).

Regards,
Juan Manuel Fernandez
[image: Tarlogic]
Juan Manuel Fernández Torres
Security Engineer
juanma.fernan...@tarlogic.com
(0034) 912 919 319
[image: follow on twiter]

[image:
contact on linked] 
www.tarlogic.com
POLÍTICA DE PRIVACIDAD Este mensaje es solamente para la persona a la que
va dirigido. Puede contener información confidencial o legalmente
protegida. No hay renuncia a la confidencialidad o privilegio por cualquier
transmisión mala / errónea. Si usted ha recibido este mensaje por error, le
rogamos que borre de su sistema inmediatamente el mensaje así como todas
sus copias, destruya todas las copias del mismo de su disco duro y
notifique al remitente. No debe, directa o indirectamente, usar, revelar,
distribuir, imprimir o copiar ninguna de las partes de este mensaje si no
es usted el destinatario. Cualquier opinión expresada en este mensaje
proviene del remitente, excepto cuando el mensaje establezca lo contrario y
el remitente esta autorizado para establecer que dichas opiniones provienen
de Tarlogic Security S.L.. Nótese que el correo electrónico vía Internet no
permite asegurar ni la confidencialidad de los mensajes que se transmiten
ni la correcta recepción de los mismos. En el caso de que el destinatario
de este mensaje no consintiera la utilización del correo electrónico vía
Internet, rogamos lo ponga en nuestro conocimiento de manera inmediata.

  DISCLAIMER This message contains confidential information and is intended
only for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the
sender immediately by e-mail if you have received this e-mail by mistake
and delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message, which arise as a result of e-mail
transmission.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss