[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 24 Dec 2013 10:21:03 -0500 (EST)
From: cve-assign@...re.org
To: vdanen@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, carnil@...ian.org
Subject: Re: CVE request: denial of service in Nagios (process_cgivars())
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> http://sourceforge.net/p/nagios/nagioscore/ci/d97e03f32741a7d851826b03ed73ff4c9612a866/
> Can you please advise if any additional CVE(s) will be assigned to
> this commit in Nagios then?
The situation is a bit complicated but it appears that the best choice
is to add one CVE assignment.
As mentioned in the
http://openwall.com/lists/oss-security/2013/12/16/4 post,
CVE-2013-7108 is for the https://dev.icinga.org/issues/5251 report.
This mentions specific affected Icinga files. The issue in the same
files in Nagios has this same CVE ID.
Nagios changed two other files. The first file is contrib/daemonchk.c.
This is a fix for the same type of off-by-one issue covered by
CVE-2013-7108, but it was announced at a different time and therefore
is assigned a different CVE ID, CVE-2013-7205 for Nagios. Our
information from Icinga upstream is that the contrib/daemonchk.c code
isn't exposed to untrusted input with the Icinga distribution as
shipped, and would only be exposed if the user decides to change the
build/installation process. Therefore, Icinga upstream is not
accepting this as an Icinga vulnerability.
Another observation about contrib/daemonchk.c is that the
process_cgivars function apparently accomplishes nothing, and the call
and the code itself (with the originally erroneous length checking)
could perhaps just be omitted, because the variables[x] values are
never used. However, later use of the variables[x] values is
irrelevant to the reported attack possibility.
The second file is cgi/statuswml.c. Here, the Nagios commit adds a
block of new code -- this isn't an off-by-one change like the other
cases. As far as we can tell, this block of new code doesn't correct
any exploitable vulnerability and thus there won't be any associated
CVE ID. The code might be a good idea for consistency reasons, but we
didn't notice any viable attack that would involve long variables[x]
values.
Finally (although it's not directly relevant to CVE assignment),
Icinga does not use the cgi/statuswml.c code and is no longer even
shipping it.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJSuaVyAAoJEKllVAevmvmsE/sIALIOCCsIyfU4kDVoQOjB2FYC
bqS1B/OfcYkIhcSqGiH/MS+aCaP7bdiVXsy6d89se8XIWe7GRni54rS6nBROmQ6b
trvXGGy/SJkEvgYE0CQb6UEQl1FFej7lUzHEWCsRaHaUK+s90dEngAi6WjcZj/fc
Udyr/V/22uBA++Q96IlL0GokAQE0DLymifWwSgkE5EDkQvulEuZ+6TqK+cDIKcFJ
tnRWk5uLEtEpu84i2RaXC/FeHPSdjrPtIX0FVO/Q1LX0yTxwk5+ilJNQsdWZqcMv
BPpIXY8xE8BWAnGuQ72odtiSoiV8jzZ4nJIxkjDYTCShwhkJNBWznB9R5VOw/hQ=
=onXN
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
