CVE-2021-21299

{"id": "CVE-2021-21299", "metrics": {"cvssMetricV2": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"version": "2.0", "baseScore": 6.8, "accessVector": "NETWORK", "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "authentication": "NONE", "integrityImpact": "PARTIAL", "accessComplexity": "MEDIUM", "availabilityImpact": "PARTIAL", "confidentialityImpact": "PARTIAL"}, "acInsufInfo": false, "impactScore": 6.4, "baseSeverity": "MEDIUM", "obtainAllPrivilege": false, "exploitabilityScore": 8.6, "obtainUserPrivilege": false, "obtainOtherPrivilege": false, "userInteractionRequired": false}], "cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 8.1, "attackVector": "NETWORK", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 2.2}, {"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 4.8, "attackVector": "NETWORK", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N", "integrityImpact": "LOW", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "LOW"}, "impactScore": 2.5, "exploitabilityScore": 2.2}]}, "published": "2021-02-11T18:15:16.800", "references": [{"url": "https://crates.io/crates/hyper", "tags": ["Product", "Third Party Advisory"], "source": "security-advisories@github.com"}, {"url": "https://github.com/hyperium/hyper/commit/8f93123efef5c1361086688fe4f34c83c89cec02", "tags": ["Patch", "Third Party Advisory"], "source": "security-advisories@github.com"}, {"url": "https://github.com/hyperium/hyper/security/advisories/GHSA-6hfq-h8hq-87mf", "tags": ["Third Party Advisory"], "source": "security-advisories@github.com"}, {"url": "https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn", "tags": ["Third Party Advisory"], "source": "security-advisories@github.com"}, {"url": "https://rustsec.org/advisories/RUSTSEC-2021-0020.html", "tags": ["Third Party Advisory"], "source": "security-advisories@github.com"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-444"}]}], "descriptions": [{"lang": "en", "value": "hyper is an open-source HTTP library for Rust (crates.io). In hyper from version 0.12.0 and before versions 0.13.10 and 0.14.3 there is a vulnerability that can enable a request smuggling attack. The HTTP server code had a flaw that incorrectly understands some requests with multiple transfer-encoding headers to have a chunked payload, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that understands the request payload boundary differently can result in \"request smuggling\" or \"desync attacks\". To determine if vulnerable, all these things must be true: 1) Using hyper as an HTTP server (the client is not affected), 2) Using HTTP/1.1 (HTTP/2 does not use transfer-encoding), 3) Using a vulnerable HTTP proxy upstream to hyper. If an upstream proxy correctly rejects the illegal transfer-encoding headers, the desync attack cannot succeed. If there is no proxy upstream of hyper, hyper cannot start the desync attack, as the client will repair the headers before forwarding. This is fixed in versions 0.14.3 and 0.13.10. As a workaround one can take the following options: 1) Reject requests that contain a `transfer-encoding` header, 2) Ensure any upstream proxy handles `transfer-encoding` correctly."}, {"lang": "es", "value": "hyper es una biblioteca HTTP de c\u00f3digo abierto para Rust (crates.io). En Hyper desde la versi\u00f3n 0.12.0 y antes de las versiones 0.13.10 y 0.14.3, se presenta una vulnerabilidad que puede habilitar un ataque de trafico no autorizado de peticiones. El c\u00f3digo del servidor HTTP ten\u00eda un fallo que entiende incorrectamente que algunas peticiones con m\u00faltiples encabezados transfer-encoding tienen una carga \u00fatil fragmentada, cuando deber\u00eda haber sido rechazada como ilegal. Esto, combinado con un proxy HTTP aguas arriba que entiende el l\u00edmite de carga \u00fatil de la petici\u00f3n de manera diferente, puede resultar en \"request smuggling\" o \"desync attacks\". Para determinar si es vulnerable, todas estas cosas deben ser ciertas: 1) Usar Hyper como servidor HTTP (el cliente no se ve afectado), 2) Usar HTTP/1.1 (HTTP/2 no usa transfer-encoding), 3) Usar un Proxy HTTP vulnerable aguas arriba de hiper. Si un proxy aguas arriba rechaza correctamente los encabezados transfer-encoding ilegales, el ataque de desincronizaci\u00f3n no puede tener \u00e9xito. Si no existe un proxy aguas arriba de Hyper, Hyper no puede iniciar el ataque de desincronizaci\u00f3n, ya que el cliente reparar\u00e1 los encabezados antes de reenviar. Esto se corrige en las versiones 0.14.3 y 0.13.10. Como soluci\u00f3n alternativa, se pueden tomar las siguientes opciones: 1) Rechazar las peticiones que contengan un encabezado \"transfer-encoding\", 2) Asegurarse de que cualquier proxy ascendente maneje correctamente \"transfer-encoding\""}], "lastModified": "2021-02-19T18:28:26.657", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:a:hyper:hyper:*:*:*:*:*:rust:*:*", "vulnerable": true, "matchCriteriaId": "F7FC7D00-33F1-4ACB-8092-470E14701DA9", "versionEndExcluding": "0.13.10", "versionStartIncluding": "0.12.0"}, {"criteria": "cpe:2.3:a:hyper:hyper:*:*:*:*:*:rust:*:*", "vulnerable": true, "matchCriteriaId": "E4C26856-B337-4B3F-80FA-B417727F07B2", "versionEndExcluding": "0.14.3", "versionStartIncluding": "0.14.0"}], "operator": "OR"}]}], "sourceIdentifier": "security-advisories@github.com"}