Skip to content

Simple query results in infinite memory consumption and vtgate crash

Moderate
shlomi-noach published GHSA-649x-hxfx-57j2 May 8, 2024

Package

gomod github.com/vitessio/vitess (Go)

Affected versions

< 19.0.4, < 18.0.5, < 17.0.7

Patched versions

19.0.4, 18.0.5, 17.0.7

Description

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:

if len(b) < 2 {
return utf8.RuneError, 0
}

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:

for len(src) > 0 {
cp, width := srcCharset.DecodeRune(src)
if cp == utf8.RuneError && width < 3 {
failed++
cp = '?'
}
src = src[width:]

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.

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
High
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

CVE ID

CVE-2024-32886

Weaknesses

No CWEs

Credits