CVE-2022-39199 - How A Broken UUID Check in immudb Lets Servers Fool Clients

Published: NVD CVE-2022-39199  
Patched in: immudb v1.4.1  
Affected: immudb client SDKs up to v1.4.  
Severity: Moderate

What’s immudb?

immudb is an open-source database built to provide cryptographic proof for all your data. Every record you save is verifiable, making sure your data hasn’t been tampered with. Built for trust, right?

Its client Software Development Kits (SDKs) use a *server UUID* to keep track of which immudb server they’re talking to. This way, you can juggle connections to different immudb servers without getting their states mixed up.

But what happens when that trust is misplaced? Enter CVE-2022-39199.

The Vulnerability Explained

Originally discovered and reported on GitHub, this issue is surprisingly simple:

The client records this UUID and uses it to keep the right state for that server.

- However, the SDK does not validate the UUID at all. The server can report ANY value as its UUID, and the client will blindly believe it.

What’s the impact?  
A malicious immudb server (or a man-in-the-middle attacker) can change its reported UUID at will. The client, seeing a new UUID, thinks it’s talking to a *new* server, and starts storing a fresh state for it. This means the client could...

- Lose track of the actual state/history it *should* have

Accept data as verified when in fact it’s not from the original server it thinks it is

In simple terms: the server can fool a client into believing it’s switched to an entirely new server, and the client will treat all data as trustworthy—even when it isn’t.

Here’s some typical Go code that sets up an immudb client connection

import "github.com/codenotary/immudb/pkg/client"

func main() {
    cli, err := client.NewImmuClient(client.DefaultOptions())
    if err != nil {
        panic(err)
    }
    // The client just accepts whatever UUID the server reports here
}

Under the hood, the SDK gets the server UUID like so

// Pseudo-code
state := server.Response.State
clientStateHandler.SaveState(state.ServerUUID, state)

Notice: No validation! The client relies 100% on what the server says.

Next time, the attacker makes the fake server report a *different* UUID to the same client.

3. The client believes it’s now talking to a new server, wipes out past state and accepts the new state.

The attacker can supply any fake "cryptographic verification data" and the client will trust it.

All it takes is control of the server or the ability to MITM the client-server traffic.

Official Patch

Good news:  
The immudb devs fixed this in version 1.4.1! Now, the SDK verifies the server’s UUID and makes sure it matches what you expect, stopping attackers from tricking the client.

👉 Upgrade now! Get the latest version:  
https://github.com/codenotary/immudb/releases/tag/v1.4.1

Workaround for Older Versions

Can’t upgrade? There’s a workaround. immudb’s SDK lets you supply a custom "state handler". If you ignore the server UUID and always use the one you trust, the server can’t trick your client anymore.

Here’s how you might do it in Go

type MyFixedStateHandler struct {
    trustedUUID string
    state       *client.State
}

func (s *MyFixedStateHandler) SaveState(_ string, st *client.State) error {
    s.state = st
    s.state.ServerUUID = s.trustedUUID // Ignore server-supplied UUID
    return nil
}

func (s *MyFixedStateHandler) GetState(serverUUID string) (*client.State, error) {
    if s.state != nil && s.trustedUUID == serverUUID {
        return s.state, nil
    }
    return nil, fmt.Errorf("state not found")
}

// Usage:
trustedUUID := "put-your-real-server-uuid-here"
handler := &MyFixedStateHandler{trustedUUID: trustedUUID}
cli, err := client.NewImmuClient(client.DefaultOptions().WithStateHandler(handler))

This makes the client ignore any changes in the server's UUID.

Final Words

CVE-2022-39199 is a reminder that *never trusting user input* applies even when your “user” is a database server.

References

- NVD CVE-2022-39199
- GitHub Security Advisory
- immudb release v1.4.1


Stay safe, and always double-check those connections—even if you’re just talking to your own database!

Timeline

Published on: 11/22/2022 20:15:00 UTC
Last modified on: 11/26/2022 03:32:00 UTC