Discussion:
Bug#914941: http-parser: CVE-2018-12121
(too old to reply)
Jérémy Lal
2018-11-28 22:20:01 UTC
Permalink
Source: http-parser
Severity: important
Tags: security

Hi,

I believe this commit should partly be applied to http-parser:
https://github.com/nodejs/node/commit/a8532d4d2

Specifically setting HTTP_MAX_HEADER_SIZE to a more reasonnable
default (8192 instead of 81920 bytes) should be good for all other
software depending on http-parser...

Jérémy


-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/
Florian Weimer
2019-07-21 20:20:01 UTC
Permalink
Post by Jérémy Lal
https://github.com/nodejs/node/commit/a8532d4d2
Specifically setting HTTP_MAX_HEADER_SIZE to a more reasonnable
default (8192 instead of 81920 bytes) should be good for all other
software depending on http-parser...
The default limit doesn't look so bad to me. The kernel will happily
allocate much more for a typical TCP connection, for example.

Lowering the limit in a Debian release could introduce regressions.
Jérémy Lal
2019-07-21 20:40:01 UTC
Permalink
Post by Florian Weimer
Post by Jérémy Lal
https://github.com/nodejs/node/commit/a8532d4d2
Specifically setting HTTP_MAX_HEADER_SIZE to a more reasonnable
default (8192 instead of 81920 bytes) should be good for all other
software depending on http-parser...
The default limit doesn't look so bad to me. The kernel will happily
allocate much more for a typical TCP connection, for example.
This is a comparison between apples (tcp level) and bananas (application
level),
so i think it's not a valid argument.
Post by Florian Weimer
Lowering the limit in a Debian release could introduce regressions.
Indeed, it could, in theory.
However most (probably all...) web servers set default limits on that value,
to get a rough idea one can have a look at
https://stackoverflow.com/questions/686217/maximum-on-http-header-values

Also note the vulnerability is tagged as *high*.
Meaning there's a good chance other software using http-parser is affected.
Ruby ? Python ?

Jérémy

Jérémy
Florian Weimer
2019-07-21 21:30:01 UTC
Permalink
Post by Jérémy Lal
Post by Florian Weimer
Post by Jérémy Lal
https://github.com/nodejs/node/commit/a8532d4d2
Specifically setting HTTP_MAX_HEADER_SIZE to a more reasonnable
default (8192 instead of 81920 bytes) should be good for all other
software depending on http-parser...
The default limit doesn't look so bad to me. The kernel will happily
allocate much more for a typical TCP connection, for example.
This is a comparison between apples (tcp level) and bananas
(application level), so i think it's not a valid argument.
How is this not a valid argument in the context of how http-parser is
expected to be used?

You need to tweak all these settings if you want to expose a service
to hostile clients.
Post by Jérémy Lal
Post by Florian Weimer
Lowering the limit in a Debian release could introduce regressions.
Indeed, it could, in theory.
However most (probably all...) web servers set default limits on that value,
to get a rough idea one can have a look at
https://stackoverflow.com/questions/686217/maximum-on-http-header-values
The answer is severely misguided. For example, the Apache default is
somewhere around 800 KiB, I think.
Post by Jérémy Lal
Also note the vulnerability is tagged as *high*.
That would be wrong. I don't know where you got this information.
Jérémy Lal
2019-07-21 22:10:02 UTC
Permalink
Post by Florian Weimer
Post by Jérémy Lal
Post by Florian Weimer
Post by Jérémy Lal
https://github.com/nodejs/node/commit/a8532d4d2
Specifically setting HTTP_MAX_HEADER_SIZE to a more reasonnable
default (8192 instead of 81920 bytes) should be good for all other
software depending on http-parser...
The default limit doesn't look so bad to me. The kernel will happily
allocate much more for a typical TCP connection, for example.
This is a comparison between apples (tcp level) and bananas
(application level), so i think it's not a valid argument.
How is this not a valid argument in the context of how http-parser is
expected to be used?
You need to tweak all these settings if you want to expose a service
to hostile clients.
Post by Jérémy Lal
Post by Florian Weimer
Lowering the limit in a Debian release could introduce regressions.
Indeed, it could, in theory.
However most (probably all...) web servers set default limits on that
value,
Post by Jérémy Lal
to get a rough idea one can have a look at
https://stackoverflow.com/questions/686217/maximum-on-http-header-values
The answer is severely misguided. For example, the Apache default is
somewhere around 800 KiB, I think.
Okay, the default (from the apache docs) is
LimitRequestFieldSize 8190
However it looks like it is the default for a single http request header
field,
not the sum of all of them.
Post by Florian Weimer
Also note the vulnerability is tagged as *high*.
That would be wrong. I don't know where you got this information.
https://nvd.nist.gov/vuln/detail/CVE-2018-12121
and links from there.

However, as you imply, this was surely a high severity issue for Node.js,
not
for http-parser. Since upstream Node.js fixed it by tweaking
HTTP_MAX_HEADER_SIZE, i assumed it was something affecting http-parser,
and that it would be worth backporting the fix for all.

If it is instead just a workaround, and there is no issue at all with
http-parser,
then please ignore my request. The nodejs debian package will continue to
use
its bundled fork of http-parser until they fix it another way not involving
changing
http-parser.

Jérémy

Loading...