Published: 2024-06-05  
Author: Security Analyst  
Affected Product: TiDB  
Versions Affected: Prior to 6.4., 6.1.3


When dealing with databases, data formatting is everything. A single bad code line can leak out critical information or even compromise your server. The vulnerability known as CVE-2022-3023 is a textbook example—a classic, yet dangerous, *externally-controlled format string* bug affecting TiDB, the popular distributed SQL database.

Below, I’ll walk you through what this bug is, how it was introduced, how an attacker could exploit it, and most importantly, how to fix it for good.

What is a Format String Vulnerability? (Simple Terms)

Ever seen code like this?

fmt.Printf(userInput)

Instead of the safer

fmt.Printf("%s", userInput)


The first code sample is a trap! If userInput is externally supplied (for example, from a network request, user data, or a log message), a hacker can sneak format specifiers like %x, %s, or %n into their input. The program, in trying to interpret those symbols, can end up leaking memory contents, leaking secrets, or even crashing.

How this Problem Unfolded in TiDB

TiDB, the open-source MySQL-compatible distributed SQL database, had a few critical areas where unsafe format string processing happened. Specifically, versions before 6.4. and 6.1.3 used untrusted input as a formatting string in Go's fmt family of functions.

Here’s a simplified pseudocode of what went wrong

// BAD: vulnerable version (simplified)
func LogMessage(msg string) {
    log.Printf(msg) // User input goes directly into format string!
}

What’s dangerous here? If an attacker sends a message like

"%x %x %x"


The database will try to print data from the stack where those %x map, possibly leaking memory content. Even innocent features like logging or error handling can become an attacker’s playground.

Find a Place to Inject Input:

If TiDB exposes any API, error log line, or function where user-controlled data ends up as a printf format string, that’s enough.

`

GET /api/endpoint?username=%x%x%x

`

or send SQL queries/messages with malicious percent formats.

Observe Information Disclosure:

If the log or error message is saved, the attacker can view leaked bytes from memory—possibly including secrets, tokens, or sensitive data.

Let’s build a basic replica. Suppose there’s an endpoint that logs user queries

package main

import (
    "fmt"
    "log"
    "net/http"
)

func main() {
    http.HandleFunc("/query", func(w http.ResponseWriter, r *http.Request) {
        query := r.URL.Query().Get("q")
        log.Printf(query) // VULNERABLE
        fmt.Fprintf(w, "Query received")
    })
    log.Fatal(http.ListenAndServe(":808", nil))
}

A hacker curls your server like

curl "http://localhost:808/query?q=%x %x %x"


The log will try to print three stack values as hex—potentially leaking secrets. In a real, large codebase like TiDB, this can spill data from deeper inside the process.

The Official Fix

The proper defensive coding is simple: never use untrusted data as a format string! Always use a constant format string and supply user data as arguments.

Safe Code

log.Printf("%s", userInput)

The TiDB maintainers fixed the problem in PR #35737

// SAFE: fixed version
func LogMessage(msg string) {
    log.Printf("%s", msg)
}

Upgrade Now!

If you’re running TiDB, upgrade to 6.4. or 6.1.3 (or later) to patch this issue

- Release 6.4. notes
- Release 6.1.3 notes

References

- GitHub Security Advisory for CVE-2022-3023
- NVD entry for CVE-2022-3023
- PingCAP/tidb commit fixing format string usage
- OWASP: Uncontrolled Format String

Conclusion

CVE-2022-3023 in TiDB is a great cautionary tale for any developer: never trust user input as a formatting string, especially in logging and error handling. Bugs like these are easy to miss but easy to fix. Make sure to keep your dependencies updated and always review code for patterns like this.

If you’re running any affected version of TiDB, act today and upgrade. Exposure to format string vulnerabilities is just too risky, especially for mission-critical data.

Stay secure, and code safe!

*(This article is for educational and awareness purposes only. Please use responsibly and always report findings to the affected vendor.)*

Timeline

Published on: 11/04/2022 12:15:00 UTC
Last modified on: 11/05/2022 02:02:00 UTC