Node.js release fixes a critical HTTP security vulnerability

Escrito por:

6 de fevereiro de 2020

0 minutos de leitura

A new Node.js security release was published earlier today, 6th of February, 2020 which fixes one Critical severity and two High severity issues. This release also includes stricter HTTP parsing. According to the official release notes included in the following Node.js commit:

Also, HTTP parsing is more strict to be more secure. Since this may cause problems in interoperability with some non-conformant HTTP implementations, it is possible to disable the strict checks with the --insecure-http-parser command line flag, or the insecureHTTPParser http option. Using the insecure HTTP parser should be avoided.

TL;DR

All actively supported versions 10.x, 12.x, and 13.x of Node.js are vulnerable. We strongly encourage you to upgrade as soon as you can to the following fixed versions: 10.19.0, 12.15.0 and 13.8.0

2020-02-06, Version 10.19.0, Dubnium (LTS)
2020-02-06, Version 12.15.0, Erbium (LTS)
2020-02-06, Version 13.8.0, current

Am I affected?

Node.js versions 10.x, 12.x, and 13.x that are using HTTP and TLS directly or indirectly, such as projects based on the Express web applications are affected.

You are also affected if you are using any of the unsupported Node.js versions such as 11.x, 9.x and <= 8.x.

The following Node.js vulnerabilities were identified along with their CVE assignments:

CVE-2019-15606: HTTP header values do not have trailing OWS trimmed.
CVE-2019-15605: HTTP request smuggling using malformed Transfer-Encoding header.
CVE-2019-15604: Remotely trigger an assertion on a TLS server with a malformed certificate string.

About the Node.js HTTP header vulnerability CVE-2019-15606

The vulnerability relates to HTTP header values that do not have trailing OWS trimmed, as described in this commits comments on GitHub:

HTTP header values can have trailing OWS, but it should be stripped. It is not semantically part of the header’s value, and if treated as part of the value, it can cause spurious inequality between expected and actual header values.
Note that a single SPC of leading OWS is common before the field-value, and it is already handled by the HTTP parser by stripping all leading OWS. It is only the trailing OWS that must be stripped by the parser user.

        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

"How was this vulnerability fixed?

Relevant Commits: 25b6897e8a http: strip trailing OWS from header values.
Related: RFC 7230 Section 3.2 and Section 3.2.3
Not yet public references are the original GitHub Pull Request and HackerOne report

About the Node.js HTTP request smuggling vulnerability CVE-2019-15605

Node.js was discovered to be vulnerable to HTTP request smuggling attacks using malformed Transfer-Encoding header. An example of how this would have taken place is provided using the following HTTP request snippet, which is now used to test for this regression:

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!!!

How was this vulnerability fixed?

Relevant Commits: eea3a7429b test: using TE to smuggle reqs is not possible and 8f41e837bb deps: update llhttp to 2.0.4
Not yet public references are the original GitHub Pull Request and HackerOne report

About the Node.js vulnerability identified as CVE-2019-15604

Node.js was found to be vulnerable to a TLS issue which could remotely trigger an assertion on a TLS server with a malformed certificate string, as is detailed in the original commit message:

X509V3_EXT_print can return value different from 1 if the X509extension does not support printing to a buffer. Instead of failing withan unrecoverable assertion - replace the relevant value in the hashmapwith a JS null value.

How was this vulnerability fixed?

Relevant Commits: 1156a9e5f8 crypto: fix assertion caused by unsupported ext.
The security report details in the HackerOne report

We at Snyk value the security community and believe that responsible disclosure of security vulnerabilities in open source packages helps us ensure the security and privacy of the users. If you believe you found a vulnerability within an Open Source software, you can contact us through https://snyk.io/vulnerability-disclosure. Our responsible disclosure program aims to protect both the developer and the reported researcher, while allowing developers to safely benefit from vulnerabilities discovered by researchers.