Integer overflows in unescape_word()

How it was found

Summary:

A similiar issue to CVE-2019-5435

Steps To Reproduce:

analysis

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.

Impact

It might leads to a crash or some other impact.