Two Base64 Memory-Safety CVEs
in the AWS SDK for C++

Context

The AWS SDK for C++ is the client library through which C++ applications talk to AWS services, and Base64 decoding sits on a path that almost every such application exercises: it is how binary payloads, signatures, and service responses are carried over text protocols. That makes the decoder a piece of parsing code that routinely handles attacker-influenced input, in a language with no bounds checking of its own.

The decoder in question was hand-written rather than delegated to a hardened implementation. Hand-written decoders are exactly the shape of code where length arithmetic goes wrong quietly: the buffer is sized from one calculation, the write loop is bounded by another, and the two agree on the inputs anyone thought to test.

Approach

We analysed the decoder with ESBMC, our software model checker, which automatically detects, or proves the absence of, runtime errors such as buffer overflows in C++ programs. Rather than testing individual strings, we supplied symbolic inputs: the decoder was asked to run on every input up to a given bound at once, and the solver was asked whether any of them could drive a memory-safety violation.

This is the difference that mattered here. A fuzzer or a unit-test suite samples the input space and reports what it happened to hit; bounded model checking reasons over the whole space up to the bound and either returns a concrete counterexample or establishes that none exists. The counterexamples ESBMC produced were exact input strings, which made the reports directly actionable for the AWS Security team.

Results

If you use the SDK

Upgrade to AWS SDK for C++ 1.11.862 or later. Because the fix moves Base64 handling into the AWS Common Runtime, a version bump alone is not always sufficient: if you build the SDK from source or link it statically, confirm that your build actually picks up the updated aws-crt-cpp dependency, rather than resolving to a pinned or vendored copy of the old one.

What this means

Parsing and decoding routines in production C++ are small, self-contained, and heavily exercised, which is precisely the profile that bounded model checking handles well. A decoder of this size can be reasoned about exhaustively up to a useful bound in the time it takes to write a handful of unit tests, and the output is either a concrete crashing input or a proof that none exists below the bound. For teams shipping C++ that touches untrusted bytes, that is a cheaper and sharper instrument than adding another sample of the input space to a test suite.