{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-04T10:12:10.984Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf"
          },
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment/"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "platforms": [
            "all"
          ],
          "product": "AWS SDK",
          "vendor": "Amazon",
          "versions": [
            {
              "lessThan": "2.0.0",
              "status": "affected",
              "version": "stable",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "value": "Thai Duong"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "A weak robustness vulnerability exists in the AWS Encryption SDKs for Java, Python, C and Javalcript prior to versions 2.0.0. Due to the non-committing property of AES-GCM (and other AEAD ciphers such as AES-GCM-SIV or (X)ChaCha20Poly1305) used by the SDKs to encrypt messages, an attacker can craft a unique cyphertext which will decrypt to multiple different results, and becomes especially relevant in a multi-recipient setting. We recommend users update their SDK to 2.0.0 or later."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.8,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-310",
              "description": "CWE-310 Cryptographic Issues",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2020-11-16T11:55:11.000Z",
        "orgId": "14ed7db2-1595-443d-9d34-6215bf890778",
        "shortName": "Google"
      },
      "references": [
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf"
        },
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment/"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Robustness weakness in AWS KMS and Encryption SDKs",
      "x_generator": {
        "engine": "Vulnogram 0.0.9"
      },
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "security@google.com",
          "ID": "CVE-2020-8897",
          "STATE": "PUBLIC",
          "TITLE": "Robustness weakness in AWS KMS and Encryption SDKs"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "AWS SDK",
                      "version": {
                        "version_data": [
                          {
                            "platform": "all",
                            "version_affected": "\u003c",
                            "version_name": "stable",
                            "version_value": "2.0.0"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "Amazon"
              }
            ]
          }
        },
        "credit": [
          {
            "lang": "eng",
            "value": "Thai Duong"
          }
        ],
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "A weak robustness vulnerability exists in the AWS Encryption SDKs for Java, Python, C and Javalcript prior to versions 2.0.0. Due to the non-committing property of AES-GCM (and other AEAD ciphers such as AES-GCM-SIV or (X)ChaCha20Poly1305) used by the SDKs to encrypt messages, an attacker can craft a unique cyphertext which will decrypt to multiple different results, and becomes especially relevant in a multi-recipient setting. We recommend users update their SDK to 2.0.0 or later."
            }
          ]
        },
        "generator": {
          "engine": "Vulnogram 0.0.9"
        },
        "impact": {
          "cvss": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.8,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N",
            "version": "3.1"
          }
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "CWE-310 Cryptographic Issues"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf",
              "refsource": "CONFIRM",
              "url": "https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf"
            },
            {
              "name": "https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment/",
              "refsource": "CONFIRM",
              "url": "https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment/"
            }
          ]
        },
        "source": {
          "discovery": "EXTERNAL"
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "14ed7db2-1595-443d-9d34-6215bf890778",
    "assignerShortName": "Google",
    "cveId": "CVE-2020-8897",
    "datePublished": "2020-11-16T11:55:11.000Z",
    "dateReserved": "2020-02-12T00:00:00.000Z",
    "dateUpdated": "2024-08-04T10:12:10.984Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.amazonaws:aws-encryption-sdk-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "aws-encryption-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8897"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-327"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-10-08T22:24:29Z",
    "nvd_published_at": "2020-11-16T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "Authors: Thai \"[thaidn](https://twitter.com/xorninja)\" Duong\n\n# Summary\n\nThe following security vulnerabilities was discovered and reported to Amazon, affecting AWS KMS and all versions of [AWS Encryption SDKs](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) prior to version 2.0.0:\n\n* **Information leakage**: an attacker can create ciphertexts that would leak the user\u2019s AWS account ID, encryption context, user agent, and IP address upon decryption\n* **Ciphertext forgery**: an attacker can create ciphertexts that are accepted by other users\n* **Robustness**: an attacker can create ciphertexts that decrypt to different plaintexts for different users\n\nThe first two bugs are somewhat surprising because they show that the ciphertext format can lead to vulnerabilities. These bugs (and the infamous [alg: \"None\"](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/) bugs in JWT) belong to a class of vulnerabilities called **in-band protocol negotiation**. This is the second time we\u2019ve found in-band protocol negotiation vulnerabilities in AWS cryptography libraries; see this [bug](https://github.com/google/security-research/security/advisories/GHSA-7f33-f4f5-xwgw) in S3 Crypto SDK discovered by my colleague Sophie Schmieg.\n\nIn JWT and S3 SDK the culprit is the algorithm field\u2014here it is the key ID. Because the key ID is used to determine which decryption key to use, it can\u2019t be meaningfully authenticated despite being under the attacker\u2019s control. If the key ID is a URL indicating where to fetch the key, the attacker can replace it with their own URL, and learn side-channel information such as the timing and machines on which the decryption happens (this can also lead to [SSRF](https://portswigger.net/web-security/ssrf) issues, but that\u2019s another topic for another day).\n\nIn AWS, the key ID is a unique [Amazon Resource Name](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). If an attacker were to capture a ciphertext from a user and replace its key ID with their own, the victim\u2019s AWS account ID, encryption context, user agent, and IP address would be logged to the attacker\u2019s AWS account whenever the victim attempted to decrypt the modified ciphertext.\n\nThe last bug shows that the non-committing property of AES-GCM (and other AEAD ciphers such as [AES-GCM-SIV](https://keymaterial.net/2020/09/07/invisible-salamanders-in-aes-gcm-siv/) or (X)ChaCha20Poly1305) is especially problematic in multi-recipient settings. These ciphers have a property that can cause nonidentical plaintexts when decrypting a single ciphertext with two different keys! For example, you can send a single encrypted email to Alice and Bob which, upon decryption, reads \u201cattack\u201d to Alice and \u201cretreat\u201d to Bob. The AWS Encryption SDKs are vulnerable to this attack because they allow a single ciphertext to be generated for multiple recipients, with each decrypting using a different key. I believe this kind of problem is prevalent. I briefly looked at [JWE](https://tools.ietf.org/html/rfc7516) and I think it is vulnerable.\n\n# Mitigations\n\nAmazon has fixed these bugs in release 2.0.0 of the SDKs. A new major version was required because, unfortunately, the fix for the last bug requires a breaking change from earlier versions. All users are recommended to upgrade. More details about Amazon\u2019s mitigations can be found in [their announcement](https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment/).\n\nWe\u2019re collaborating with Shay Gueron on a paper regarding fast committing AEADs.\n\n# Vulnerabilities\n\n## Information Leakage\n\nThe [Encrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html) API in AWS KMS encrypts plaintext into ciphertext by using a customer master key (CMK). The ciphertext format is undocumented, but it contains metadata that specifies the CMK and the encryption algorithm. I reverse-engineered the format and found the location of the CMK. Externally the CMK is identified by its key ARN, but within a ciphertext it is represented by an internal ID, which remained stable during my testing.\n\nWhen I replaced the internal ID of a CMK in a ciphertext with the internal ID of another CMK, I found that AWS KMS attempted to decrypt the ciphertext with the new CMK. The encryption failed and the failure event\u2014including the AWS Account ID, the user agent and the IP address of the caller\u2014was logged to Cloud Trail in the account that owned the replacement CMK.\n\nThis enables the following attack:\n* The attacker creates a CMK that has a key policy that allows access from everyone. This requires no prior knowledge about the victim.\n* The attacker intercepts a ciphertext from the victim, and replaces its CMK with their CMK.\n* Whenever the victim attempts to decrypt the modified ciphertext, the attacker learns the timing of such actions, the victim\u2019s AWS Account ID, user agent, encryption context, and IP address.\n\nThis attack requires the victim to have an IAM policy that allows them to access the attacker\u2019s CMK. I found that this practice was allowed by the AWS Visual Policy Editor, but I don\u2019t know whether it is common.\n\nThe AWS Encryption SDKs also succumb to this attack. The SDKs implement envelope encryption: encrypting data with a data encryption key (DEK) and then wrapping the DEK with a CMK using the Encrypt API in AWS KMS. The wrapped DEK is stored as part of the final ciphertext (format is defined [here](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/message-format.html)). The attacker can mount this attack by replacing the CMK in the wrapped DEK with their own.\n\n```\n{\n    \"eventVersion\": \"1.05\",\n    \"userIdentity\": {\n        \"type\": \"AWSAccount\",\n        \"principalId\": \"\u003credacted this is the principal ID of the victim\u003e\",\n        \"accountId\": \"\u003credacted - this is the AWS account ID of the victim\u003e\"\n    },\n    \"eventTime\": \"2020-06-21T21:05:04Z\",\n    \"eventSource\": \"kms.amazonaws.com\",\n    \"eventName\": \"Decrypt\",\n    \"awsRegion\": \"us-west-2\",\n    \"sourceIPAddress\": \"\u003credacted - this is the IP address of the victim\u003e\",\n    \"userAgent\": \"\u003credacted - this is the user agent of the victim\u003e\",\n    \"errorCode\": \"InvalidCiphertextException\",\n    \"requestParameters\": {\n        // The encryption context might include other data from the victim\n        \"encryptionContext\": {\n            \"aws-crypto-public-key\": \"AzfNOGOnNYFmpHspKrAm1L6XtRybONkmkhmB/IriKSA7b2NsV4MEPMph9yX2KTPKWw==\"\n        },\n        \"encryptionAlgorithm\": \"SYMMETRIC_DEFAULT\"\n    },\n    \"responseElements\": null,\n    \"requestID\": \"aeced8e8-75a2-42c3-96ac-d1fa2a1c5ee6\",\n    \"eventID\": \"780a0a6e-4ad8-43d4-a426-75d05022f870\",\n    \"readOnly\": true,\n    \"resources\": [\n        {\n            \"accountId\": \"\u003credacted - this is the account ID of the attacker\u003e\",\n            \"type\": \"AWS::KMS::Key\",\n            \"ARN\": \u003credacted - this is the key ARN of the attacker\u003e\n        }\n    ],\n    \"eventType\": \"AwsApiCall\",\n    \"recipientAccountId\": \"\u003credacted - this is the account ID of the attacker\u003e\",\n    \"sharedEventID\": \"033e147c-8a36-42f5-9d6c-9e071eb752b7\"\n}\n```\n**Figure 1: A failure event logged to the attacker\u2019s Cloud Trail when the victim attempted to decrypt a modified ciphertext containing the attacker\u2019s CMK.**\n\n## Ciphertext Forgery\n\nThe [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) API in AWS KMS doesn\u2019t require the caller to specify the CMK. This parameter is required only when the ciphertext was encrypted under an asymmetric CMK. Otherwise, AWS KMS uses the metadata that it adds to the ciphertext blob to determine which CMK was used to encrypt the ciphertext.\n\nThis leads to the following attack:\n* The attacker creates a CMK that has a key policy that allows access from everyone. This requires no prior knowledge about the victim.\n* The attacker generates a ciphertext by calling the Encrypt API with their key.\n* The attacker intercepts a ciphertext from the victim, and replaces it entirely with their ciphertext.\n* The victim successfully decrypts the ciphertext, as if it was encrypted under their own key. The attacker also learns when this happened, the victim\u2019s AWS Account ID, user agent, encryption context, and IP address.\n\nSimilar to the information leakage attack, this attack also requires the victim to have an IAM policy that allows them to access the attacker\u2019s CMK.\n\nThe AWS Encryption SDKs also succumb to this attack. They don\u2019t specify the CMK when they call the Decrypt API to unwrap the DEK.\n\n## Robustness\n\nThe AWS Encryption SDKs allow a single ciphertext to be generated for multiple recipients, with each decrypting using a different key. To that end, it wraps the DEK multiple times, each under a different CMK. The wrapped DEKs can be combined to form a single ciphertext which can be sent to multiple recipients who can use their own credentials to decrypt it. It\u2019s reasonable to expect that all recipients should decrypt the ciphertext to an identical plaintext. However, because of the use of AES-GMAC and AES-GCM, it\u2019s possible to create a ciphertext that decrypts to two valid yet different plaintexts for two different users. In other words, the AWS Encryption SDKs are [not](https://eprint.iacr.org/2008/440.pdf) [robust](https://eprint.iacr.org/2019/016.pdf).\n\nThe encryption of a message under two CMKs can be summarized as follows:\n* A DEK is randomly generated, and two wrapped DEKs are produced by calling the Encrypt API using the two CMKs\n* A per-message AES-GCM key (K) is derived using HKDF from the DEK, a randomly generated message ID, and a fixed algorithm ID.\n* A header is formed from the wrapped DEKs, the encryption context, and other metadata. A header authentication tag is computed on the header using AES-GMAC with K and a zero IV.\n* The message is encrypted using AES-GCM with K, a non-zero IV, and fixed associated additional data. This produces a message authentication tag.\n* The ciphertext consists of the header, the header authentication tag, the encrypted message, and the message authentication tag.\n\n(There\u2019s also a self-signed digital signature that is irrelevant to this discussion).\n\nIn order to decrypt a ciphertext, the AWS Encryption SDKs loops over the list of wrapped DEKs and returns the first one that it can successfully unwrap. The attacker therefore can wrap a unique DEK for each recipient. Next, the attacker exploits the non-committing property of GMAC to produce two messages that have the same GMAC tag under two different keys. The attacker has to do this twice, one for the header authentication tag and one for the message authentication tag.\n\n```\nGiven a data blob B of one 128-bit block B_1, a GMAC tag is computed as follows:\n\nB_1 * H^2 + B_len * H + J\n\nwhere H and J depends on the key and B_len depends on the length of B.\n\nTo find a message that can produce the same tag under two different keys, one\ncan add append to B a new block B_2 whose value can be deduced by solving\nan algebraic equation. That is, we want to find B_2 such that:\n\nB_1 * H^3 + B_2 * H^2 + B_len * H + J = B_1 * H\u2019^3 + B_2 * H\u2019^2 + B_len * H\u2019 + J\u2019\n\nwhere H\u2019 and J\u2019 are the corresponding H and J of the other key.\n\nB_2 is the only unknown value in this equation, thus it can be computed using\nfinite field arithmetics of GF(2^128):\n\nB_2 = [B_1 * (H^3+H\u2019^3) + B_len * (H + H\u2019) + J + J\u2019] * (H^2 + H\u2019^2)^-1.\n```\n**Figure 2: How to find a message that has the same GMAC tag under two different keys.**\n\nThe overall attack works as follows:\n* The attacker generates a random DEK, derives a per-message key K, and encrypts message M with it using AES in counter mode. This generates a ciphertext C.\n* The attacker generates another random DEK\u2019, derives a per-message key K\u2019, and performs trial decryption of C until the decrypted message M\u2019 has desirable properties. For example, if the attacker wants the first bit of M\u2019 different from that of M, this process should only take a few attempts.\n* The attacker finds a block C* such that the GMAC of C\u2019 = C || C* under K and K\u2019 are identical. Denote this tag C\u2019_tag.\n* The attacker wraps DEK and DEK\u2019 under two recipients\u2019 CMK.\n* The attacker forms a header H and adds a block H* to the encryption context such that the new H\u2019 has the same authentication tag H\u2019_tag under K and K\u2019.\n* The attacker output H\u2019, H\u2019_tag, C\u2019, C\u2019_tag.\n\nThis attack is similar to the one discovered in [Facebook Messenger](https://eprint.iacr.org/2019/016.pdf).\n\n# Acknowledgement\n\nI\u2019m grateful to Jen Barnason for carefully editing this advisory. I will never publish anything without her approval! I want to thank my friend and coworker Sophie \u201cQueen of Hashing\u201d Schmieg for wonderful discussions and for showing me how the arithmetic in GF(2^128) works. I want to thank Jonathan Bannet for asking the questions that led to this work.",
  "id": "GHSA-wqgp-vphw-hphf",
  "modified": "2024-09-04T19:24:49Z",
  "published": "2021-10-12T16:01:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8897"
    },
    {
      "type": "WEB",
      "url": "https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/aws-encryption-sdk/PYSEC-2020-261.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Security issues in AWS KMS and AWS Encryption SDKs: in-band protocol negotiation and robustness"
}