A similiar issue to CVE-2019-5435
DICT protocol can use one url like “dict://localhost:3306”, and function unescape_word() is used to deal with the character in url like this comment
/* According to RFC2229 section 2.2, these letters need to be escaped with
\[letter] */
if((ch <= 32) || (ch == 127) ||
(ch == '\'') || (ch == '\"') || (ch == '\\')) {
dictp[olen++] = '\\';
}
and the bug case here /curl/lib/dict.c
static char *unescape_word(const char *inputbuff)
{
char *newp = NULL;
char *dictp;
size_t len;
CURLcode result = Curl_urldecode(inputbuff, 0, &newp, &len, <------------- get len
REJECT_NADA);
if(!newp || result)
return NULL;
dictp = malloc(len*2 + 1); <------------ overflow here
//.....
}
In my analysis(maybe wrong), the inputbuff
in DICT url is “dict:[inputbuff]”, for example “//localhost:3306” in “dict://localhost:3306”, and len
is the length of inputbuff
.
And the length of inputbuff
multiplied by 2 and then passed to malloc. This may lead to a integer overflow on a 32bit OS when the inputbuff is longer than 2GB
unescape_word
was called by dict_do(), If someone use libcurl to code, and call dict_do() with a extreme long url, it might be triggered.
It might leads to a crash or some other impact.