[Dnsmasq-discuss] reproducible segmentation fault - bisected!

[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 <simon at thekelleys.org.uk>
>   Date:   Fri Jul 22 20:56:01 2016 +0100
> 
>      Zero packet buffers before building output, to reduce risk
>      of information leakage.
<snip>

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 problem....which 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dnsmasq-rfc1035-mitigate-CVE-2017-13704.patch
Type: text/x-patch
Size: 1253 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20170828/9709fc0c/attachment.bin>