CVE-2024-1635

{"id": "CVE-2024-1635", "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "secalert@redhat.com", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.5, "attackVector": "NETWORK", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 3.9}]}, "published": "2024-02-19T22:15:48.647", "references": [{"url": "https://access.redhat.com/errata/RHSA-2024:1674", "source": "secalert@redhat.com"}, {"url": "https://access.redhat.com/errata/RHSA-2024:1675", "source": "secalert@redhat.com"}, {"url": "https://access.redhat.com/errata/RHSA-2024:1676", "source": "secalert@redhat.com"}, {"url": "https://access.redhat.com/errata/RHSA-2024:1677", "source": "secalert@redhat.com"}, {"url": "https://access.redhat.com/errata/RHSA-2024:1860", "source": "secalert@redhat.com"}, {"url": "https://access.redhat.com/errata/RHSA-2024:1861", "source": "secalert@redhat.com"}, {"url": "https://access.redhat.com/errata/RHSA-2024:1862", "source": "secalert@redhat.com"}, {"url": "https://access.redhat.com/errata/RHSA-2024:1864", "source": "secalert@redhat.com"}, {"url": "https://access.redhat.com/errata/RHSA-2024:1866", "source": "secalert@redhat.com"}, {"url": "https://access.redhat.com/security/cve/CVE-2024-1635", "source": "secalert@redhat.com"}, {"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2264928", "source": "secalert@redhat.com"}, {"url": "https://security.netapp.com/advisory/ntap-20240322-0007/", "source": "secalert@redhat.com"}], "vulnStatus": "Awaiting Analysis", "weaknesses": [{"type": "Primary", "source": "secalert@redhat.com", "description": [{"lang": "en", "value": "CWE-400"}]}], "descriptions": [{"lang": "en", "value": "A vulnerability was found in Undertow. This vulnerability impacts a server that supports the wildfly-http-client protocol. Whenever a malicious user opens and closes a connection with the HTTP port of the server and then closes the connection immediately, the server will end with both memory and open file limits exhausted at some point, depending on the amount of memory available. \r\n\r\nAt HTTP upgrade to remoting, the WriteTimeoutStreamSinkConduit leaks connections if RemotingConnection is closed by Remoting ServerConnectionOpenListener. Because the remoting connection originates in Undertow as part of the HTTP upgrade, there is an external layer to the remoting connection. This connection is unaware of the outermost layer when closing the connection during the connection opening procedure. Hence, the Undertow WriteTimeoutStreamSinkConduit is not notified of the closed connection in this scenario. Because WriteTimeoutStreamSinkConduit creates a timeout task, the whole dependency tree leaks via that task, which is added to XNIO WorkerThread. So, the workerThread points to the Undertow conduit, which contains the connections and causes the leak."}, {"lang": "es", "value": "Se encontr\u00f3 una vulnerabilidad en Undertow. Esta vulnerabilidad afecta a un servidor que admite el protocolo wildfly-http-client. Siempre que un usuario malintencionado abre y cierra una conexi\u00f3n con el puerto HTTP del servidor y luego cierra la conexi\u00f3n inmediatamente, el servidor finalizar\u00e1 con los l\u00edmites de memoria y de archivos abiertos agotados en alg\u00fan momento, dependiendo de la cantidad de memoria disponible. En la actualizaci\u00f3n HTTP a comunicaci\u00f3n remota, WriteTimeoutStreamSinkConduit pierde conexiones si RemotingConnection se cierra mediante Remoting ServerConnectionOpenListener. Debido a que la conexi\u00f3n remota se origina en Undertow como parte de la actualizaci\u00f3n HTTP, existe una capa externa a la conexi\u00f3n remota. Esta conexi\u00f3n desconoce la capa m\u00e1s externa al cerrar la conexi\u00f3n durante el procedimiento de apertura de la conexi\u00f3n. Por lo tanto, Undertow WriteTimeoutStreamSinkConduit no recibe notificaci\u00f3n de la conexi\u00f3n cerrada en este escenario. Debido a que WriteTimeoutStreamSinkConduit crea una tarea de tiempo de espera, todo el \u00e1rbol de dependencia se filtra a trav\u00e9s de esa tarea, que se agrega a XNIO WorkerThread. Entonces, el hilo de trabajo apunta al conducto Undertow, que contiene las conexiones y causa la fuga."}], "lastModified": "2024-04-17T16:15:07.720", "sourceIdentifier": "secalert@redhat.com"}