7.5 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
NONE
Integrity Impact
NONE
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
5 Medium
CVSS2
Access Vector
NETWORK
Access Complexity
LOW
Authentication
NONE
Confidentiality Impact
NONE
Integrity Impact
NONE
Availability Impact
PARTIAL
AV:N/AC:L/Au:N/C:N/I:N/A:P
0.004 Low
EPSS
Percentile
71.4%
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.
The example app lists a directory with 40,000 files on funet.fi.
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}
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.
7.5 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
NONE
Integrity Impact
NONE
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
5 Medium
CVSS2
Access Vector
NETWORK
Access Complexity
LOW
Authentication
NONE
Confidentiality Impact
NONE
Integrity Impact
NONE
Availability Impact
PARTIAL
AV:N/AC:L/Au:N/C:N/I:N/A:P
0.004 Low
EPSS
Percentile
71.4%