Nginx advisories with not vulnerable versions inside the vulnerable range

[Maxim Dounin]

Hello!

On Tue, Dec 28, 2021 at 02:14:07PM +0530, Hritik Vijay wrote:

> I'm trying to parse the advisories page present at
> https://nginx.org/en/security_advisories.html. So far, I've understood
> the even-odd minor versioning scheme for branches (thanks to Maxim at https://marc.info/?l=nginx&m=163174223924231&w=2).
> There still exists some advisories that are hard to understand. 
> For example:
> 	Excessive CPU usage in HTTP/2 with small window updates
> 	Severity: medium
> 	Advisory
> 	CVE-2019-9511
> 	Not vulnerable: 1.17.3+, 1.16.1+
> 	Vulnerable: 1.9.5-1.17.2
> 
> Here, the vulnerable versions are through 1.9.5 to 1.17.2, even though
> the versions 1.16.1+ are marked not vulnerable.
> Looking at the odd numbers in the vulnerable range, I could infer that
> perhaps the vulnerability spanned through the mainline branch only. Even
> then it raises some questions. Following are some interpretations and
> the problems with them:

[...]

> Interpretation:
> 	All versions from 1.9.5 to 1.17.2 are vulnerable, regardless of the
> 	branch, except the ones mentioned in the not vulnerable range
> Problem:
> 	If the not vulnerable range is to be interpreted as an "exception"
> 	to the vulnerable range then there's no point in mentioning 1.17.3+
> 	as it already lies outside the vulnerable range.

That's the correct interpretation.  While explicitly mentioning 
1.17.3+ as not vulnerable is not strictly needed, it is just 
duplicate information to simplify reading.

> The last interpretation sounds most reasonable to me with the following
> changes:
> 	All versions from 1.9.5 to 1.17.2 are vulnerable, regardless of the
> 	branch. It was fixed in the only provided mainline branch that is
> 	1.17.3+, although some fixes were provided to the stable branches as
> 	well (here only one stable branch, that is 1.16.1+).
> 
> This will require a hard requirement for the following:
> Not Vulnerable: 
> 	One mainline version with plus sign,
> 	One or many stable branch version with plus sign
> Vulnerable:
> 	A range independent of branching scheme (mainline and stable)
> 
> Although, this sounds right and suits for most of the advisories present
> on the page, it doesn't handle:
> 	Buffer underflow vulnerability
> 	Severity: major
> 	VU#180065  CVE-2009-2629
> 	Not vulnerable: 0.8.15+, 0.7.62+, 0.6.39+, 0.5.38+
> 	Vulnerable: 0.1.0-0.8.14
> 
> As there are more than one mainline branch - 0.7.62+ and 0.5.38+ - in
> the "Not Vulnerable" range, where there should only be one. Once a
> vulnerability is fixed in a lower mainline version (0.5.38) it must have
> been fixed in later mainline and stable versions, which doesn't seem to
> be the case here (as 0.7.62+ and 0.6.39+ are mentioned explicitly).

Your interpretation of "mainline" and "stable" is incorrect here.  
The odd/even numbering scheme is in use only starting with nginx 
1.0.x.  In previous versions, a branch was simply declared stable 
at some point.  For example, 0.5.x branch was mainline (current) 
till 0.5.25, and then 0.6.0 version was released, and 0.5.x branch 
was declared stable[1].  Similarly, 0.6.x branch was mainline till 
0.6.31, and was declared stable after 0.7.0 release.

For additional details about all existing branches check the 
download page (http://nginx.org/en/download.html) and relevant 
CHANGES and CHANGES-X.Y files.

Note that it is generally trivial to find out if a version is 
vulnerable or not from the information about a vulnerability, 
without any knowledge about nginx branches.  That is:

- Check if the version is in "Vulnerable" range.  If it's not, the 
  version is not vulnerable.

- If it is, check if the branch is explicitly listed in the "Not 
  vulnerable".  If it's not, the version is vulnerable.  If it 
  is, check the minor number: if it's greater or equal to the 
  version listed as not vulnerable, the version is not vulnerable, 
  else the version is vulnerable.

Hope this helps.

[1] http://mailman.nginx.org/pipermail/nginx/2007-June/001080.html

-- 
Maxim Dounin
http://mdounin.ru/