CVE-2020-8285: FTP wildcard stack overflow

## Summary: User 'xnynx' on github filed [PR 6255](https://github.com/curl/curl/issues/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) 1. run it (with a debugger) 1. 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.