GHSA-89v2-g37m-g3ff Improper Verification of Cryptographic Signature in aws-encryption-sdk-cli

Not scored Published

Attackers with KMS permissions can bypass ECDSA signature validation in streaming mode, undermining non-repudiation guarantees for signed messages.

Exploited in the wild
Not known
Login needed
Any signed-in user
Attackable
Over the internet
Victim action needed
Not needed
Fix
Available

What is GHSA-89v2-g37m-g3ff?

GHSA-89v2-g37m-g3ff is a vulnerability in aws-encryption-sdk-cli, published on 1 Jun 2021. Any signed-in user can exploit it over the network, with no action from the victim.

Official description

Impact

This advisory addresses several LOW severity issues with streaming signed messages and restricting processing of certain types of invalid messages.

This ESDK supports a streaming mode where callers may stream the plaintext of signed messages before the ECDSA signature is validated. In addition to these signatures, the ESDK uses AES-GCM encryption and all plaintext is verified before being released to a caller. There is no impact on the integrity of the ciphertext or decrypted plaintext, however some callers may rely on the the ECDSA signature for non-repudiation. Without validating the ECDSA signature, an actor with trusted KMS permissions to decrypt a message may also be able to encrypt messages. This update introduces a new API for callers who wish to stream only unsigned messages.

For customers who process ESDK messages from untrusted sources, this update also introduces a new configuration to limit the number of Encrypted Data Keys (EDKs) that the ESDK will attempt to process per message. This configuration provides customers with a way to limit the number of AWS KMS Decrypt API calls that the ESDK will make per message. This setting will reject messages with more EDKs than the configured limit.

Finally, this update adds early rejection of invalid messages with certain invalid combinations of algorithm suite and header data.

Patches

Fixed in versions 1.9 and 2.2. We recommend that all users upgrade to address these issues.

Customers leveraging the ESDK’s streaming features have several options to protect signature validation. One is to ensure that client code reads to the end of the stream before using released plaintext. With this release, using the new API for streaming and falling back to the non-streaming decrypt API for signed messages prevents using any plaintext from signed data before the signature is validated. See https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x

Users processing ESDK messages from untrusted sources should use the new maximum encrypted data keys parameter. See https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x

Workarounds

None

For more information

https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/concepts.html#digital-sigs

https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x

Which versions are affected by GHSA-89v2-g37m-g3ff?

4 open source packages ship an affected version, including aws-encryption-sdk-cli.

PackageAffectedFixed in
aws-encryption-sdk-cli PyPIAll versions1.9.0
aws-encryption-sdk-cli PyPIAll versions1.9.0
aws-encryption-sdk-cli PyPIFrom 2.0.02.2.0
aws-encryption-sdk-cli PyPIFrom 2.0.02.2.0

How do I fix GHSA-89v2-g37m-g3ff?

Upgrade aws-encryption-sdk-cli to a fixed version for your release line: 1.9.0 or 2.2.0.

Is GHSA-89v2-g37m-g3ff being exploited?

There is no known exploitation of GHSA-89v2-g37m-g3ff in the wild and no public exploit code.

Sources

Is GHSA-89v2-g37m-g3ff in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free