ghsa-649x-hxfx-57j2
Vulnerability from github
Published
2024-05-08 14:32
Modified
2024-05-10 21:33
Severity ?
4.9 (Medium) - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Summary
Vitess vulnerable to infinite memory consumption and vtgate crash
Details

Summary

When executing the following simple query, the vtgate will go into an endless loop that also keeps consuming memory and eventually will OOM.

Details

When running the following query, the evalengine will try evaluate it and runs forever.

select _utf16 0xFF

The source of the bug lies in the collation logic that we have. The bug applies to all utf16, utf32 and ucs2 encodings. In general, the bug is there for any encoding where the minimal byte length for a single character is more than 1 byte.

The decoding functions for these collations all implement logic like the following to enforce the minimal character length:

https://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/unicode/utf16.go#L69-L71

The problem is that all the callers of DecodeRune expect progress by returning the number of bytes consumed. This means that if there's only 1 byte left in an input, it will here return still 0 and the caller(s) don't consume the character.

One example of such a caller is the following:

https://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/convert.go#L73-L79

The logic here moves forward the pointer in the input []byte but if DecodeRune returns 0 in case of error, it will keep running forever. The OOM happens since it keeps adding the ? as the invalid character to the destination buffer infinitely, growing forever until it runs out of memory.

The fix here would be to always return forward progress also on invalid strings.

There's also a separate bug here that even if progress is guaranteed, select _utf16 0xFF will return the wrong result currently. MySQL will pad here the input when the _utf16 introducer is used with leading 0x00 bytes and then decode to UTF-16, resulting in the output of ÿ here.

PoC

select _utf16 0xFF

Impact

Denial of service attack by triggering unbounded memory usage.

Show details on source website

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/vitessio/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.0.0"
            },
            {
              "fixed": "19.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/vitessio/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "18.0.0"
            },
            {
              "fixed": "18.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/vitessio/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "17.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "vitess.io/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "vitess.io/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.18.0"
            },
            {
              "fixed": "0.18.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "vitess.io/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.19.0"
            },
            {
              "fixed": "0.19.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-32886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-08T14:32:32Z",
    "nvd_published_at": "2024-05-08T14:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen executing the following simple query, the `vtgate` will go into an endless loop that also keeps consuming memory and eventually will OOM.\n\n### Details\n\nWhen running the following query, the `evalengine` will try evaluate it and runs forever.\n\n```\nselect _utf16 0xFF\n```\n\nThe source of the bug lies in the collation logic that we have. The bug applies to all `utf16`,  `utf32` and `ucs2` encodings.  In general, the bug is there for any encoding where the minimal byte length for a single character is more than 1 byte.\n\nThe decoding functions for these collations all implement logic like the following to enforce the minimal character length:\n\nhttps://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/unicode/utf16.go#L69-L71\n\nThe problem is that all the callers of `DecodeRune` expect progress by returning the number of bytes consumed. This means that if there\u0027s only 1 byte left in an input, it will here return still `0` and the caller(s) don\u0027t consume the character. \n\nOne example of such a caller is the following:\n\nhttps://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/convert.go#L73-L79\n\nThe logic here moves forward the pointer in the input `[]byte` but if `DecodeRune` returns `0` in case of error, it will keep running forever. The OOM happens since it keeps adding the `?` as the invalid character to the destination buffer infinitely, growing forever until it runs out of memory.\n\nThe fix here would be to always return forward progress also on invalid strings. \n\nThere\u0027s also a separate bug here that even if progress is guaranteed, `select _utf16 0xFF` will return the wrong result currently. MySQL will pad here the input when the `_utf16` introducer is used with leading `0x00` bytes and then decode to UTF-16, resulting in the output of `\u00ff` here. \n\n### PoC\n\n```\nselect _utf16 0xFF\n```\n\n### Impact\n\nDenial of service attack by triggering unbounded memory usage.",
  "id": "GHSA-649x-hxfx-57j2",
  "modified": "2024-05-10T21:33:14Z",
  "published": "2024-05-08T14:32:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/security/advisories/GHSA-649x-hxfx-57j2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32886"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/commit/2fd5ba1dbf6e9b32fdfdaf869d130066b1b5c0df"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/commit/9df4b66550e46b5d7079e21ed0e1b0f49f92b055"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/commit/c46dc5b6a4329a10589ca928392218d96031ac8d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/commit/d438adf7e34a6cf00fe441db80842ec669a99202"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vitessio/vitess"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/convert.go#L73-L79"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/unicode/utf16.go#L69-L71"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vitess vulnerable to infinite memory consumption and vtgate crash"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.