Several security issues were identified in nginx HTTP/2
implementation, which might cause excessive memory consumption
and CPU usage (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516).
The issues affect nginx compiled with the ngx_http_v2_module (not
compiled by default) if the "http2" option of the "listen" directive
is used in a configuration file.
The issues affect nginx 1.9.5 - 1.17.2.
The issues are fixed in nginx 1.17.3, 1.16.1.
Thanks to Jonathan Looney from Netflix for discovering these issues.
Adjusted for Nginx 1.10
CVE-2018-16843 CVE-2018-16844
=============================
Two security issues were identified in nginx HTTP/2 implementation,
which might cause excessive memory consumption (CVE-2018-16843)
and CPU usage (CVE-2018-16844).
The issues affect nginx compiled with the ngx_http_v2_module (not
compiled by default) if the "http2" option of the "listen" directive is
used in a configuration file.
The issues affects nginx 1.9.5 - 1.15.5.
To mitigate CVE-2018-16844 the http2_max_requests was also backported
from 1.14.
To mitigate CVE-2018-16843 the allocated frames has to be checked in
ngx_http_v2_send_settings() as well since SETTINGS frames are handled
separately before 1.13.2 (http://hg.nginx.org/nginx/rev/79de0d2aa432)
Thanks to Nginx's Maxim Dounin for his help.
CVE-2018-16845
==============
A security issue was identified in the ngx_http_mp4_module, which might
allow an attacker to cause infinite loop in a worker process, cause a
worker process crash, or might result in worker process memory
disclosure by using a specially crafted mp4 file (CVE-2018-16845).
The issue only affects nginx if it is built with the ngx_http_mp4_module
(the module is not built by default) and the "mp4" directive is used in
the configuration file. Further, the attack is only possible if an
attacker is able to trigger processing of a specially crafted mp4 file
with the ngx_http_mp4_module.
The issue affects nginx 1.1.3+, 1.0.7+.
A security issue was identified in nginx range filter. A specially
crafted request might result in an integer overflow and incorrect
processing of ranges, potentially resulting in sensitive information
leak (CVE-2017-7529).
When using nginx with standard modules this allows an attacker to
obtain a cache file header if a response was returned from cache.
In some configurations a cache file header may contain IP address
of the backend server or other sensitive information.
Besides, with 3rd party modules it is potentially possible that
the issue may lead to a denial of service or a disclosure of
a worker process memory. No such modules are currently known though.
The issue affects nginx 0.5.6 - 1.13.2.
The issue is fixed in nginx 1.13.3, 1.12.1.
For older versions, the following configuration can be used
as a temporary workaround:
max_ranges 1;
See http://mailman.nginx.org/pipermail/nginx-announce/2017/000200.htmlCloses: #868109
Previously a module that was removed (not purged) and then reinstalled
did not enable itself causing some confusion. Now, we maintain state by
moving the module symlink to .removed on package removal.
If the package is reinstalled the link is restored, if purged the link
is completely dropped.
Fixes issues during upgrades from non dynamic nginx versions (jessie).
When multiple modules are installed together for the first time,
nginx reload might fail because, at that time, the configuration
might reference directives provided by module packages that are
not yet configured.
There are also other cases where the instant reload might break,
using triggers seems like the correct way to proceed.
Since the modules don't depend on nginx binary packages
yet, there are some edge cases that /run/nginx.pid is not empty
and /usr/sbin/nginx doesn't exist.
We now dummy merge (-s ours) upstream into upstream-1.11 instead
of force pushing a clean branch on every release.
That way we can easier track the branch's history.
