Stack-based Buffer Overflow in the dname_concatenate() function

[fcambus]

Hi,

While fuzzing nsd-checkzone with American Fuzzy Lop, I found a Stack-based Buffer Overflow in the dname_concatenate() function, in dname.c L464.

Attaching a reproducer (gzipped so GitHub accepts it), issue can be reproduced by running:

nsd-checkzone all.rr zone02

zone02.gz

=================================================================
==7395==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcd6a9763f at pc 0x0000004dadbc bp 0x7ffcd6a97510 sp 0x7ffcd6a96cc0
WRITE of size 8 at 0x7ffcd6a9763f thread T0
#0 0x4dadbb in __asan_memcpy (/home/fcambus/nsd/nsd-checkzone+0x4dadbb)
#1 0x534251 in dname_concatenate /home/fcambus/nsd/dname.c:464:2
#2 0x69e61f in yyparse /home/fcambus/nsd/./zparser.y:1024:12
#3 0x689fd1 in zonec_read /home/fcambus/nsd/zonec.c:1623:2
#4 0x6aedd1 in check_zone /home/fcambus/nsd/nsd-checkzone.c:61:11
#5 0x6aea07 in main /home/fcambus/nsd/nsd-checkzone.c:127:2
#6 0x7fa60ece6b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#7 0x41c1d9 in _start (/home/fcambus/nsd/nsd-checkzone+0x41c1d9)

Address 0x7ffcd6a9763f is located in stack of thread T0 at offset 287 in frame
#0 0x533f8f in dname_concatenate /home/fcambus/nsd/dname.c:458

This frame has 1 object(s):
[32, 287) 'temp' (line 459) <== Memory access at offset 287 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions are supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/fcambus/nsd/nsd-checkzone+0x4dadbb) in __asan_memcpy
Shadow bytes around the buggy address:
0x10001ad4ae70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4ae80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4ae90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4aea0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
0x10001ad4aeb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10001ad4aec0: 00 00 00 00 00 00 00[07]f3 f3 f3 f3 f3 f3 f3 f3
0x10001ad4aed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4aee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4aef0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
0x10001ad4af00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001ad4af10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==7395==ABORTING

[fcambus]

This issue got assigned CVE-2019-13207.

[wcawijngaards]

Thank you for the detailed report! That is very useful, the check on the max length of the concatenate was missing here. The commit adds it.
Reading zone files happens from the disk configuration (I mean, this is not data received in a DNS packet). There was an assertion guarding it too. (I.e. I am thinking the severity is low enough to wait for the next release and not intrude on the release-candidate in-progress).