CVE-2024-47742

{"id": "CVE-2024-47742", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.8, "attackVector": "LOCAL", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 1.8}]}, "published": "2024-10-21T13:15:04.297", "references": [{"url": "https://git.kernel.org/stable/c/28f1cd94d3f1092728fb775a0fe26c5f1ac2ebeb", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/3d2411f4edcb649eaf232160db459bb4770b5251", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/6c4e13fdfcab34811c3143a0a03c05fec4e870ec", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/7420c1bf7fc784e587b87329cc6dfa3dca537aa4", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/9b1ca33ebd05b3acef5b976c04e5e791af93ce1b", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a77fc4acfd49fc6076e565445b2bc5fdc3244da4", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/c30558e6c5c9ad6c86459d9acce1520ceeab9ea6", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d1768e5535d3ded59f888637016e6f821f4e069f", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/f0e5311aa8022107d63c54e2f03684ec097d1394", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Modified", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-22"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware_loader: Block path traversal\n\nMost firmware names are hardcoded strings, or are constructed from fairly\nconstrained format strings where the dynamic parts are just some hex\nnumbers or such.\n\nHowever, there are a couple codepaths in the kernel where firmware file\nnames contain string components that are passed through from a device or\nsemi-privileged userspace; the ones I could find (not counting interfaces\nthat require root privileges) are:\n\n - lpfc_sli4_request_firmware_update() seems to construct the firmware\n filename from \"ModelName\", a string that was previously parsed out of\n some descriptor (\"Vital Product Data\") in lpfc_fill_vpd()\n - nfp_net_fw_find() seems to construct a firmware filename from a model\n name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I\n think parses some descriptor that was read from the device.\n (But this case likely isn't exploitable because the format string looks\n like \"netronome/nic_%s\", and there shouldn't be any *folders* starting\n with \"netronome/nic_\". The previous case was different because there,\n the \"%s\" is *at the start* of the format string.)\n - module_flash_fw_schedule() is reachable from the\n ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as\n GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is\n enough to pass the privilege check), and takes a userspace-provided\n firmware name.\n (But I think to reach this case, you need to have CAP_NET_ADMIN over a\n network namespace that a special kind of ethernet device is mapped into,\n so I think this is not a viable attack path in practice.)\n\nFix it by rejecting any firmware names containing \"..\" path components.\n\nFor what it's worth, I went looking and haven't found any USB device\ndrivers that use the firmware loader dangerously."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Block path traversal La mayor\u00eda de los nombres de firmware son cadenas codificadas o se construyen a partir de cadenas de formato bastante restringidas donde las partes din\u00e1micas son solo algunos n\u00fameros hexadecimales o algo as\u00ed. Sin embargo, hay un par de rutas de c\u00f3digo en el kernel donde los nombres de archivo de firmware contienen componentes de cadena que se pasan desde un dispositivo o un espacio de usuario semiprivilegiado; los que pude encontrar (sin contar las interfaces que requieren privilegios de root) son: - lpfc_sli4_request_firmware_update() parece construir el nombre de archivo de firmware a partir de \"ModelName\", una cadena que se analiz\u00f3 previamente a partir de alg\u00fan descriptor (\"Vital Product Data\") en lpfc_fill_vpd() - nfp_net_fw_find() parece construir un nombre de archivo de firmware a partir de un nombre de modelo que proviene de nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), que creo que analiza alg\u00fan descriptor que se ley\u00f3 desde el dispositivo. (Pero este caso probablemente no sea explotable porque la cadena de formato se parece a \"netronome/nic_%s\", y no deber\u00eda haber ninguna *carpeta* que comience con \"netronome/nic_\". El caso anterior era diferente porque all\u00ed, el \"%s\" est\u00e1 *al comienzo* de la cadena de formato). - module_flash_fw_schedule() es accesible desde el comando netlink ETHTOOL_MSG_MODULE_FW_FLASH_ACT, que est\u00e1 marcado como GENL_UNS_ADMIN_PERM (lo que significa que CAP_NET_ADMIN dentro de un espacio de nombres de usuario es suficiente para pasar la verificaci\u00f3n de privilegios), y toma un nombre de firmware provisto por el espacio de usuario. (Pero creo que para llegar a este caso, necesita tener CAP_NET_ADMIN sobre un espacio de nombres de red en el que se asigna un tipo especial de dispositivo Ethernet, por lo que creo que esta no es una ruta de ataque viable en la pr\u00e1ctica). Arr\u00e9glelo rechazando cualquier nombre de firmware que contenga componentes de ruta \"..\" Por si sirve de algo, he buscado y no he encontrado ning\u00fan controlador de dispositivo USB que utilice el cargador de firmware de forma peligrosa."}], "lastModified": "2024-11-08T16:15:27.613", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "3B73A13A-D7BE-4035-BEF2-2821D9D5CB6D", "versionEndExcluding": "5.10.227", "versionStartIncluding": "3.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "4D51C05D-455B-4D8D-89E7-A58E140B864C", "versionEndExcluding": "5.15.168", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "D01BD22E-ACD1-4618-9D01-6116570BE1EE", "versionEndExcluding": "6.1.113", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "D448821D-C085-4CAF-88FA-2DDE7BE21976", "versionEndExcluding": "6.6.54", "versionStartIncluding": "6.2"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "CE94BB8D-B0AB-4563-9ED7-A12122B56EBE", "versionEndExcluding": "6.10.13", "versionStartIncluding": "6.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "AB755D26-97F4-43B6-8604-CD076811E181", "versionEndExcluding": "6.11.2", "versionStartIncluding": "6.11"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}