[Dnsmasq-discuss] Out-of-bound heap write when parsing invalid --dhcp-mac option

[Simon Kelley]

On 10/12/2019 00:01, Klaus Eisentraut wrote:
> Hi,
> 
> I found another crash in parsing code of a configuration file or command
> line options. To reproduce it, simply run
> 
>   dnsmasq --dhcp-mac=,AAAAA...AAAAA
> 
> with "a lot of" A (>=89 with dnsmasq 2.80 on Linux 5.4.2-arch1-1). If
> you run dnsmasq without Address Sanitizer (ASAN), it won't crash
> immediately, but instead overwrite glibc metadata and crash later on:
> 
>> $ dnsmasq --dhcp-mac=,AAAAA...AAAAA
>> malloc(): invalid next size (unsorted)
>> Terminated (core dumped)
> 
> If you compile & run it with -fsanitize=address, you can see the actual
> root cause:
> 
>> $ ./dnsmasq-asan --dhcp-mac=,AAAAA...AAAAA
>> =================================================================
>> ==32920==ERROR: AddressSanitizer: heap-buffer-overflow on address
>> 0x606000000118 at pc 0x55f58e931e2d bp 0x7ffc8a3af1a0 sp
>> 0x7ffc8a3af190
>> WRITE of size 1 at 0x606000000118 thread T0
>>  #0 0x55f58e931e2c in parse_hex /tmp/dnsmasq/src/util.c:573
>>  #1 0x55f58e95d6b9 in one_opt /tmp/dnsmasq/src/option.c:3690
>>  #2 0x55f58e992879 in read_opts /tmp/dnsmasq/src/option.c:5045
>>  #3 0x55f58e8e198e in main /tmp/dnsmasq/src/dnsmasq.c:95
>>  #4 0x7f1fff40d152 in __libc_start_main (/usr/lib/libc.so.6+0x27152)
>>  #5 0x55f58e8edfbd in _start (/home/klaus/dnsmasq-fuzzing/src/dnsmasq-
>> asan+0x2ffbd)
>>
>> 0x606000000118 is located 0 bytes to the right of 56-byte region
>> [0x6060000000e0,0x606000000118)
>> allocated by thread T0 here:
>>   #0 0x7f1fff6bdcd8 in __interceptor_calloc /build/gcc/src
>> /gcc/libsanitizer/asan/asan_malloc_linux.cc:153
>>    #1 0x55f58e92e5a8 in safe_malloc /tmp/dnsmasq/src/util.c:278
>>
>> SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/dnsmasq
>> /src/util.c:573 in parse_hex
> 
>>From a quick grep in the code, there may be other, more interesting ways
> to reach the parse_hex(...) function, too.
> 
>

Thanks for finding that. None of the uses of parse_hex is with untrusted
data, so this is an annoyance, not a security hole.

Patch pushed to git.


Cheers,

Simon.