Skip to main content
Snyk Blog

In this article

Una versión de Node.js corrige una vulnerabilidad crítica de seguridad HTTP

Escrito por
Headshot of Ulises Gascón

Ulises Gascón

Node How even quick async functions can block the Event Loop starve tumb

6 de febrero de 2020

0 minutos de lectura

Hoy, 6 de febrero de 2020, se publicó una nueva versión de seguridad de Node.js que corrige un problema de gravedad crítica y dos de gravedad alta. Esta versión también incluye un análisis HTTP más estricto. Según las notas oficiales de la versión incluidas en el siguiente commit de Node.js:

Además, el análisis HTTP es más estricto para mejorar la seguridad. Como esto puede causar problemas de interoperabilidad con algunas implementaciones HTTP que no cumplen las especificaciones, es posible desactivar las comprobaciones estrictas con el indicador de línea de comandos --insecure-http-parser o con la opción HTTP insecureHTTPParser. Se recomienda evitar el uso del analizador HTTP inseguro.

En resumen

Todas las versiones con soporte activo de Node.js, 10.x, 12.x y 13.x, son vulnerables. Te recomendamos encarecidamente actualizar lo antes posible a las siguientes versiones corregidas: 10.19.0, 12.15.0 y 13.8.0

¿Estoy en riesgo?

Las versiones 10.x, 12.x y 13.x de Node.js que usan HTTP y TLS de forma directa o indirecta, como los proyectos basados en aplicaciones web de Express, están afectadas.

También estás en riesgo si usas versiones de Node.js sin soporte, como 11.x, 9.x y <= 8.x.

Se identificaron las siguientes vulnerabilidades de Node.js junto con sus respectivos CVE:

  • CVE-2019-15606: Los valores de los encabezados HTTP no eliminan los OWS finales.

  • CVE-2019-15605: Contrabando de solicitudes HTTP mediante un encabezado Transfer-Encoding malformado.

  • CVE-2019-15604: Provocar de forma remota una aserción en un servidor TLS con una cadena de certificado malformada.

Acerca de la vulnerabilidad de encabezados HTTP de Node.js CVE-2019-15606

La vulnerabilidad está relacionada con valores de encabezados HTTP que no eliminan los OWS finales, tal como se describe en los comentarios de este commit en GitHub:

Los valores de los encabezados HTTP pueden tener OWS finales, pero deben eliminarse. No forman parte semántica del valor del encabezado y, si se consideran parte de este, pueden provocar una desigualdad espuria entre los valores esperados y los reales del encabezado.

Ten en cuenta que es común que haya un SPC de OWS inicial antes del valor del campo, y el analizador HTTP ya lo maneja eliminando todos los OWS iniciales. El usuario del analizador solo debe eliminar los OWS finales.

        header-field   = field-name ":" OWS field-value OWS
    ; https://tools.ietf.org/html/rfc7230#section-3.2
OWS            = *( SP / HTAB )
    ; https://tools.ietf.org/html/rfc7230#section-3.2.3

¿Cómo se corrigió esta vulnerabilidad?

Acerca de la vulnerabilidad de Node.js de contrabando de solicitudes HTTP CVE-2019-15605

Se descubrió que Node.js era vulnerable a ataques de contrabando de solicitudes HTTP mediante un encabezado Transfer-Encoding malformado. A continuación se muestra un ejemplo de cómo habría ocurrido esto, usando el siguiente fragmento de solicitud HTTP, que ahora se utiliza para probar esta regresión:

POST / HTTP/1.1
Content-Type: text/plain; charset=utf-8
Host: hacker.exploit.com
Connection: keep-alive
Content-Length: 10
Transfer-Encoding: chunked, eee

HELLOWORLDPOST / HTTP/1.1
Content-Type: text/plain; charset=utf-8
Host: hacker.exploit.com
Connection: keep-alive
Content-Length: 28

I AM A SMUGGLED REQUEST!!!

¿Cómo se corrigió esta vulnerabilidad?

  • Commits relacionados: eea3a7429b test: no es posible contrabandear solicitudes usando TE y 8f41e837bb deps: actualizar llhttp a 2.0.4

  • Las referencias que aún no son públicas son el pull request original de GitHub yel informe de HackerOne

Acerca de la vulnerabilidad de Node.js identificada como CVE-2019-15604

Se descubrió que Node.js era vulnerable a un problema de TLS que podía provocar de forma remota una aserción en un servidor TLS con una cadena de certificado malformada, tal como se detalla en el mensaje del commit original:

X509V3_EXT_print puede devolver un valor distinto de 1 si la extensión X509 no admite la impresión en un búfer. En lugar de fallar con una aserción irrecuperable, reemplaza el valor correspondiente en el hashmap por un valor null de JS.

¿Cómo se corrigió esta vulnerabilidad?

  • Commits relacionados: 1156a9e5f8 crypto: corregir una aserción causada por una extensión no compatible.

  • Los detalles del informe de seguridad están en el informe de HackerOne

En Snyk valoramos a la comunidad de seguridad y creemos que la divulgación responsable de vulnerabilidades en paquetes de código abierto nos ayuda a garantizar la seguridad y la privacidad de los usuarios. Si crees que encontraste una vulnerabilidad en un software de código abierto, puedes contactarnos en https://snyk.io/vulnerability-disclosure. Nuestro programa de divulgación responsable busca proteger tanto al desarrollador como al investigador que reporta la vulnerabilidad, y permitir que los desarrolladores se beneficien de forma segura de las vulnerabilidades descubiertas por los investigadores.