A padding oracle vulnerability exists in the AWS S3 Crypto SDK for GoLang versions prior to V2. The SDK allows users to encrypt files with AES-CBC without computing a Message Authentication Code (MAC), which then allows an attacker who has write access to the target's S3 bucket and can observe whether or not an endpoint with access to the key can decrypt a file, they can reconstruct the plaintext with (on average) 128*length (plaintext) queries to the endpoint, by exploiting CBC's ability to manipulate the bytes of the next block and PKCS5 padding errors. Reference: https://aws.amazon.com/blogs/developer/updates-to-the-amazon-s3-encryption-client/?s=09 https://github.com/google/security-research/security/advisories/GHSA-f5pg-7wfw-84q9
External References: https://github.com/google/security-research/security/advisories/GHSA-f5pg-7wfw-84q9 https://aws.amazon.com/blogs/developer/updates-to-the-amazon-s3-encryption-client/?s=09
On closer inspection it appears that the service/s3/s3crypto subpath of the aws/aws-sdk-go package is not used in any CAM containers making them unaffected.
Latest related upstream fix is in version 1.34.0: https://github.com/aws/aws-sdk-go/commit/12ff57a16373dda5a0c22eafdf0fa1c4c224f7c4
Statement: The following products include components that use the AWS SDK (aws/aws-sdk-go), however they do not include code that encrypts or decrypts files in S3 buckets (aws/aws-sdk-go/service/s3/s3crypto). The below products are not affected by this flaw: * Red Hat Cluster Application Migration * Red Hat OpenShift Container Platform * Red Hat OpenShift ServiceMesh * Red Hat OpenShift Container Storage * Red Hat Ceph Storage * Red Hat Gluster Storage
This issue has been addressed in the following products: 3scale API Management Via RHSA-2021:3851 https://access.redhat.com/errata/RHSA-2021:3851
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-8911