gsd-2023-43636
Vulnerability from gsd
Modified
2023-12-13 01:20
Details
In EVE OS, the “measured boot” mechanism prevents a compromised device from accessing the encrypted data located in the vault. As per the “measured boot” design, the PCR values calculated at different stages of the boot process will change if any of their respective parts are changed. This includes, among other things, the configuration of the bios, grub, the kernel cmdline, initrd, and more. However, this mechanism does not validate the entire rootfs, so an attacker can edit the filesystem and gain control over the system. As the default filesystem used by EVE OS is squashfs, this is somewhat harder than an ext4, which is easily changeable. This will not stop an attacker, as an attacker can repackage the squashfs with their changes in it and replace the partition altogether. This can also be done directly on the device, as the “003-storage-init” container contains the “mksquashfs” and “unsquashfs” binaries (with the corresponding libs). An attacker can gain full control over the device without changing the PCR values, thus not triggering the “measured boot” mechanism, and having full access to the vault. Note: This issue was partially fixed in these commits (after disclosure to Zededa), where the config partition measurement was added to PCR13: • aa3501d6c57206ced222c33aea15a9169d629141 • 5fef4d92e75838cc78010edaed5247dfbdae1889. This issue was made viable in version 9.0.0 when the calculation was moved to PCR14 but it was not included in the measured boot.
Aliases
Aliases



{
  "GSD": {
    "alias": "CVE-2023-43636",
    "id": "GSD-2023-43636"
  },
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2023-43636"
      ],
      "details": "\n\n\nIn EVE OS, the \u201cmeasured boot\u201d mechanism prevents a compromised device from accessing\nthe encrypted data located in the vault.\n\nAs per the \u201cmeasured boot\u201d design, the PCR values calculated at different stages of the boot\nprocess will change if any of their respective parts are changed.\n\nThis includes, among other things, the configuration of the bios, grub, the kernel cmdline,\ninitrd, and more.\n\nHowever, this mechanism does not validate the entire rootfs, so an attacker can edit the\nfilesystem and gain control over the system.\n\nAs the default filesystem used by EVE OS is squashfs, this is somewhat harder than an ext4,\nwhich is easily changeable.\n\nThis will not stop an attacker, as an attacker can repackage the squashfs with their changes\nin it and replace the partition altogether.\n\nThis can also be done directly on the device, as the \u201c003-storage-init\u201d container contains the\n\u201cmksquashfs\u201d and \u201cunsquashfs\u201d binaries (with the corresponding libs).\n\n\n\n\n\n\n\nAn attacker can gain full control over the device without changing the PCR values, thus not\ntriggering the \u201cmeasured boot\u201d mechanism, and having full access to the vault.\n\n\n\nNote:\n\nThis issue was partially fixed in these commits (after disclosure to Zededa), where the config\npartition measurement was added to PCR13:\n\n\u2022 aa3501d6c57206ced222c33aea15a9169d629141\n\n\u2022 5fef4d92e75838cc78010edaed5247dfbdae1889.\n\nThis issue was made viable in version 9.0.0 when the calculation was moved to PCR14 but it was not included in the measured boot.",
      "id": "GSD-2023-43636",
      "modified": "2023-12-13T01:20:44.726575Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "cve@asrg.io",
        "ID": "CVE-2023-43636",
        "STATE": "PUBLIC"
      },
      "affects": {
        "vendor": {
          "vendor_data": [
            {
              "product": {
                "product_data": [
                  {
                    "product_name": "EVE OS",
                    "version": {
                      "version_data": [
                        {
                          "version_affected": "\u003c",
                          "version_name": "9.0.0",
                          "version_value": "9.5.0"
                        },
                        {
                          "version_affected": "\u003c",
                          "version_name": "0",
                          "version_value": "8.6.0"
                        }
                      ]
                    }
                  }
                ]
              },
              "vendor_name": " LF-Edge, Zededa"
            }
          ]
        }
      },
      "credits": [
        {
          "lang": "en",
          "value": "Ilay Levi"
        }
      ],
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "\n\n\nIn EVE OS, the \u201cmeasured boot\u201d mechanism prevents a compromised device from accessing\nthe encrypted data located in the vault.\n\nAs per the \u201cmeasured boot\u201d design, the PCR values calculated at different stages of the boot\nprocess will change if any of their respective parts are changed.\n\nThis includes, among other things, the configuration of the bios, grub, the kernel cmdline,\ninitrd, and more.\n\nHowever, this mechanism does not validate the entire rootfs, so an attacker can edit the\nfilesystem and gain control over the system.\n\nAs the default filesystem used by EVE OS is squashfs, this is somewhat harder than an ext4,\nwhich is easily changeable.\n\nThis will not stop an attacker, as an attacker can repackage the squashfs with their changes\nin it and replace the partition altogether.\n\nThis can also be done directly on the device, as the \u201c003-storage-init\u201d container contains the\n\u201cmksquashfs\u201d and \u201cunsquashfs\u201d binaries (with the corresponding libs).\n\n\n\n\n\n\n\nAn attacker can gain full control over the device without changing the PCR values, thus not\ntriggering the \u201cmeasured boot\u201d mechanism, and having full access to the vault.\n\n\n\nNote:\n\nThis issue was partially fixed in these commits (after disclosure to Zededa), where the config\npartition measurement was added to PCR13:\n\n\u2022 aa3501d6c57206ced222c33aea15a9169d629141\n\n\u2022 5fef4d92e75838cc78010edaed5247dfbdae1889.\n\nThis issue was made viable in version 9.0.0 when the calculation was moved to PCR14 but it was not included in the measured boot."
          }
        ]
      },
      "generator": {
        "engine": "Vulnogram 0.1.0-dev"
      },
      "impact": {
        "cvss": [
          {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
            "version": "3.1"
          }
        ]
      },
      "problemtype": {
        "problemtype_data": [
          {
            "description": [
              {
                "cweId": "CWE-345",
                "lang": "eng",
                "value": "CWE-345 Insufficient Verification of Data Authenticity"
              }
            ]
          }
        ]
      },
      "references": {
        "reference_data": [
          {
            "name": "https://asrg.io/security-advisories/cve-2023-43636/",
            "refsource": "MISC",
            "url": "https://asrg.io/security-advisories/cve-2023-43636/"
          }
        ]
      },
      "source": {
        "discovery": "UNKNOWN"
      }
    },
    "nvd.nist.gov": {
      "configurations": {
        "CVE_data_version": "4.0",
        "nodes": [
          {
            "children": [],
            "cpe_match": [
              {
                "cpe23Uri": "cpe:2.3:o:linuxfoundation:edge_virtualization_engine:*:*:*:*:*:*:*:*",
                "cpe_name": [],
                "versionEndExcluding": "8.6.0",
                "vulnerable": true
              },
              {
                "cpe23Uri": "cpe:2.3:o:linuxfoundation:edge_virtualization_engine:*:*:*:*:*:*:*:*",
                "cpe_name": [],
                "versionEndExcluding": "9.5.0",
                "versionStartIncluding": "9.0.0",
                "vulnerable": true
              }
            ],
            "operator": "OR"
          }
        ]
      },
      "cve": {
        "CVE_data_meta": {
          "ASSIGNER": "cve@asrg.io",
          "ID": "CVE-2023-43636"
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "en",
              "value": "\n\n\nIn EVE OS, the \u201cmeasured boot\u201d mechanism prevents a compromised device from accessing\nthe encrypted data located in the vault.\n\nAs per the \u201cmeasured boot\u201d design, the PCR values calculated at different stages of the boot\nprocess will change if any of their respective parts are changed.\n\nThis includes, among other things, the configuration of the bios, grub, the kernel cmdline,\ninitrd, and more.\n\nHowever, this mechanism does not validate the entire rootfs, so an attacker can edit the\nfilesystem and gain control over the system.\n\nAs the default filesystem used by EVE OS is squashfs, this is somewhat harder than an ext4,\nwhich is easily changeable.\n\nThis will not stop an attacker, as an attacker can repackage the squashfs with their changes\nin it and replace the partition altogether.\n\nThis can also be done directly on the device, as the \u201c003-storage-init\u201d container contains the\n\u201cmksquashfs\u201d and \u201cunsquashfs\u201d binaries (with the corresponding libs).\n\n\n\n\n\n\n\nAn attacker can gain full control over the device without changing the PCR values, thus not\ntriggering the \u201cmeasured boot\u201d mechanism, and having full access to the vault.\n\n\n\nNote:\n\nThis issue was partially fixed in these commits (after disclosure to Zededa), where the config\npartition measurement was added to PCR13:\n\n\u2022 aa3501d6c57206ced222c33aea15a9169d629141\n\n\u2022 5fef4d92e75838cc78010edaed5247dfbdae1889.\n\nThis issue was made viable in version 9.0.0 when the calculation was moved to PCR14 but it was not included in the measured boot."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "en",
                  "value": "CWE-345"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://asrg.io/security-advisories/cve-2023-43636/",
              "refsource": "MISC",
              "tags": [],
              "url": "https://asrg.io/security-advisories/cve-2023-43636/"
            }
          ]
        }
      },
      "impact": {
        "baseMetricV3": {
          "cvssV3": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
            "version": "3.1"
          },
          "exploitabilityScore": 2.0,
          "impactScore": 6.0
        }
      },
      "lastModifiedDate": "2023-09-28T06:15Z",
      "publishedDate": "2023-09-20T15:15Z"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…