nvd-json-data-feeds/CVE-2023/CVE-2023-436xx/CVE-2023-43635.json

{
  "id": "CVE-2023-43635",
  "sourceIdentifier": "cve@asrg.io",
  "published": "2023-09-20T15:15:11.987",
  "lastModified": "2023-09-28T06:15:13.070",
  "vulnStatus": "Modified",
  "descriptions": [
    {
      "lang": "en",
      "value": "\nVault Key Sealed With SHA1 PCRs\n\n\n\n\n\n\nThe measured boot solution implemented in EVE OS leans on a PCR locking mechanism.\n\nDifferent parts of the system update different PCR values in the TPM, resulting in a unique\nvalue for each PCR entry.\n\nThese PCRs are then used in order to seal/unseal a key from the TPM which is used to\nencrypt/decrypt the \u201cvault\u201d directory.\n\nThis \u201cvault\u201d directory is the most sensitive point in the system and as such, its content should\nbe protected.\n\nThis mechanism is noted in Zededa\u2019s documentation as the \u201cmeasured boot\u201d mechanism,\ndesigned to protect said \u201cvault\u201d.\n\nThe code that\u2019s responsible for generating and fetching the key from the TPM assumes that\nSHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being\nchecked.\n\nThe issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.\nThis leads to several issues:\n\n\u2022 Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well\nas not sealing their keys at all, meaning the \u201cvault\u201d is not protected from an attacker.\n\n\u2022 SHA1 is considered insecure and reduces the complexity level required to unseal the\nkey in machines which have their SHA1 PCRs enabled.\n\n\n\nAn attacker can very easily retrieve the contents of the \u201cvault\u201d, which will effectively render\nthe \u201cmeasured boot\u201d mechanism meaningless.\n\n\n\n\n\n"
    },
    {
      "lang": "es",
      "value": "Vault Key Sealed With SHA1 PCRs La soluci\u00f3n de arranque medido implementada en EVE OS se apoya en un mecanismo de bloqueo de PCR. Diferentes partes del sistema actualizan diferentes valores de PCR en el TPM, lo que da como resultado un valor \u00fanico para cada entrada de PCR. Estos PCR se utilizan luego para sellar/abrir una clave del TPM que se utiliza para cifrar/descifrar el directorio \"vault\". Este directorio \"vault\" es el punto m\u00e1s sensible del sistema y, como tal, su contenido debe estar protegido. Este mecanismo est\u00e1 se\u00f1alado en la documentaci\u00f3n de Zededa como el mecanismo de \u201cmeasured boot\u201d, dise\u00f1ado para proteger dicha \u201cvault\u201d. El c\u00f3digo responsable de generar y obtener la clave del TPM asume que se utilizan PCR SHA256 para sellar/abrir la clave y, como tal, se verifica su presencia. El problema aqu\u00ed es que la clave no se sella mediante PCR SHA256, sino mediante PCR SHA1. Esto genera varios problemas: \u2022 M\u00e1quinas que tienen sus PCR SHA256 habilitadas pero las PCR SHA1 deshabilitadas, adem\u00e1s de que no sellan sus claves en absoluto, lo que significa que la \u201cvault\u201d no est\u00e1 protegida de un atacante. \u2022 SHA1 se considera inseguro y reduce el nivel de complejidad requerido para desbloquear la clave en m\u00e1quinas que tienen sus PCR SHA1 habilitados. Un atacante puede recuperar muy f\u00e1cilmente el contenido de la \"vault\", lo que efectivamente dejar\u00e1 sin sentido el mecanismo de \"measured boot\"."
    }
  ],
  "metrics": {
    "cvssMetricV31": [
      {
        "source": "nvd@nist.gov",
        "type": "Primary",
        "cvssData": {
          "version": "3.1",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
          "attackVector": "LOCAL",
          "attackComplexity": "LOW",
          "privilegesRequired": "LOW",
          "userInteraction": "NONE",
          "scope": "CHANGED",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "availabilityImpact": "HIGH",
          "baseScore": 8.8,
          "baseSeverity": "HIGH"
        },
        "exploitabilityScore": 2.0,
        "impactScore": 6.0
      },
      {
        "source": "cve@asrg.io",
        "type": "Secondary",
        "cvssData": {
          "version": "3.1",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
          "attackVector": "LOCAL",
          "attackComplexity": "LOW",
          "privilegesRequired": "LOW",
          "userInteraction": "NONE",
          "scope": "CHANGED",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "availabilityImpact": "HIGH",
          "baseScore": 8.8,
          "baseSeverity": "HIGH"
        },
        "exploitabilityScore": 2.0,
        "impactScore": 6.0
      }
    ]
  },
  "weaknesses": [
    {
      "source": "nvd@nist.gov",
      "type": "Primary",
      "description": [
        {
          "lang": "en",
          "value": "CWE-327"
        }
      ]
    },
    {
      "source": "cve@asrg.io",
      "type": "Secondary",
      "description": [
        {
          "lang": "en",
          "value": "CWE-328"
        },
        {
          "lang": "en",
          "value": "CWE-522"
        }
      ]
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "operator": "OR",
          "negate": false,
          "cpeMatch": [
            {
              "vulnerable": true,
              "criteria": "cpe:2.3:o:linuxfoundation:edge_virtualization_engine:*:*:*:*:*:*:*:*",
              "versionEndExcluding": "9.5.0",
              "matchCriteriaId": "B3C18178-A893-4EA6-8BBF-51F05CE4CB7E"
            }
          ]
        }
      ]
    }
  ],
  "references": [
    {
      "url": "https://asrg.io/security-advisories/cve-2023-43635/",
      "source": "cve@asrg.io"
    }
  ]
}