CVE-2020-8285: FTP wildcard stack overflow

How it was found

Summary:

User 'xnynx' on github filed PR 6255 highlighting this problem. Filed publicly

My first gut reaction was that this had to be a problem with curl_fnmatch as that has caused us grief in the past (and on most platforms we use the native fnmatch() now, but not on Windows IIRC and this is a reported to happen on Windows), but I then built a test program and I made it crash in what seems like potential stack overflow due to recursive calls to wc_statemach from within itself.

Steps To Reproduce:

1. build 6255.c (attached)
2. run it (with a debugger)
3. inspect the crash

The example app lists a directory with 40,000 files on funet.fi.

Crash stack trace

Program received signal SIGSEGV, Segmentation fault.
0x0000555555582039 in curl_dbg_log (
    format=<error reading variable: Cannot access memory at address 0x7fffff7fefb8>)
    at memdebug.c:437
437     {
(gdb) bt
#0  0x0000555555582039 in curl_dbg_log (
    format=<error reading variable: Cannot access memory at address 0x7fffff7fefb8>)
    at memdebug.c:437
#1  0x0000555555581b57 in curl_dbg_realloc (ptr=0x0, wantedsize=32, line=98, 
    source=0x55555563d738 "dynbuf.c") at memdebug.c:247
#2  0x00005555555c01d3 in dyn_nappend (s=0x7fffff800820, 
    mem=0x7fffff7ff187 "rP\b\200\377\377\177", len=1) at dynbuf.c:98
#3  0x00005555555c0409 in Curl_dyn_addn (s=0x7fffff800820, mem=0x7fffff7ff187, 
    len=1) at dynbuf.c:164
#4  0x0000555555587a20 in alloc_addbyter (output=114, data=0x7fffff800850)
    at mprintf.c:1045
#5  0x000055555558710f in dprintf_formatf (data=0x7fffff800850, 
    stream=0x5555555879e8 <alloc_addbyter>, format=0x555555642498 "%s%s", 
    ap_save=0x7fffff800890) at mprintf.c:846
#6  0x0000555555587aea in curl_mvaprintf (format=0x555555642498 "%s%s", 
    ap_save=0x7fffff800890) at mprintf.c:1080
#7  0x0000555555587be6 in curl_maprintf (format=0x555555642498 "%s%s")
    at mprintf.c:1095
#8  0x00005555555eae21 in wc_statemach (conn=0x5555556b9068) at ftp.c:3836
#9  0x00005555555eb0a3 in wc_statemach (conn=0x5555556b9068) at ftp.c:3894
#10 0x00005555555eaf44 in wc_statemach (conn=0x5555556b9068) at ftp.c:3856
#11 0x00005555555eb0a3 in wc_statemach (conn=0x5555556b9068) at ftp.c:3894
#12 0x00005555555eaf44 in wc_statemach (conn=0x5555556b9068) at ftp.c:3856
#13 0x00005555555eb0a3 in wc_statemach (conn=0x5555556b9068) at ftp.c:3894
#14 0x00005555555eaf44 in wc_statemach (conn=0x5555556b9068) at ftp.c:3856
#15 0x00005555555eb0a3 in wc_statemach (conn=0x5555556b9068) at ftp.c:3894
#16 0x00005555555eaf44 in wc_statemach (conn=0x5555556b9068) at ftp.c:3856
#17 0x00005555555eb0a3 in wc_statemach (conn=0x5555556b9068) at ftp.c:3894

(gdb) fr 2
#2  0x00005555555c01d3 in dyn_nappend (s=0x7fffff800820, 
    mem=0x7fffff7ff187 "rP\b\200\377\377\177", len=1) at dynbuf.c:98
98          void *p = realloc(s->bufr, a);
(gdb) p s
$1 = (struct dynbuf *) 0x7fffff800820
(gdb) p *s
$2 = {bufr = 0x0, leng = 0, allc = 0, toobig = 8000000, init = 200167898}

Impact

I haven't yet worked out exactly how to get what into the stack and what the worst kind of exploit of this might be, but a stack overflow that can be triggered by adding/crafting files in the server feels bad.