[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 31 Jul 2015 01:02:30 -0400 (EDT)
From: cve-assign@...re.org
To: scorneli@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, luodalongde@...il.com
Subject: Re: net-snmp snmp_pdu_parse() function incompletely initializaition vulnerability
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> https://sourceforge.net/p/net-snmp/bugs/2615/
> https://sourceforge.net/p/net-snmp/code/ci/f23bcd3ac6ddee5d0a48f9703007ccc738914791/
> https://bugzilla.redhat.com/show_bug.cgi?id=1212408
As far as we can tell, the primary vulnerability is described in
1212408 as:
Each time the function parses a new
varBind, a new netsnmp_variable_list item is allocated on the heap
and linked to the list of variables. The problem is that this item
is not removed from the list, even if snmp_pdu_parse() fails to
complete the parsing.
Use CVE-2015-5621.
The patch, among other changes, adds an snmp_free_var(vp) call in the
parsing-failure case. There are apparently a number of reasons for
having this snmp_free_var(vp) call, including less important reasons
such as avoiding a waste of resources by continuing to store the
useless vp data after a parsing failure. The behavior of greatest
interest is that the useless vp data has an uninitialized "type"
structure member, which can be accessed by later code in various ways.
This was the motivation for recommending an addition of a "vp->type =
0" line in the http://www.openwall.com/lists/oss-security/2015/04/13/1
post. However, the uninitialized "type" structure member is not a
separate primary vulnerability. The "type" structure member is
uninitialized only in cases where the entire vp data structure is
useless. This is the reason that
f23bcd3ac6ddee5d0a48f9703007ccc738914791 does not add a "vp->type = 0"
line. Accordingly, we feel that an additional CVE ID for lack of
"type" initialization would not make sense. If this paragraph is
misleading or wrong, or if lack of "type" initialization requires its
own CVE ID for another reason, please let us know.
- --
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
iQEcBAEBCAAGBQJVuwBvAAoJEKllVAevmvms1qUIAMfVwAcMghDOPaSMtv1IQ1Ca
a05/5knB4g2hG/Uj7R3ExMjW7gvj0Vz9649lz7kpmyo9K+BaVbvDJByLlelDQazU
FwRAocw+jBDc31ZwCGFlYyumDYk8WEN+/ll9PhvZWpOBEHW0XzQ5X5/jY39ZpNuG
2U1kQT89DW+s7AV7KpMwe4OMwWZPu03MN2SDoISDy2Q430Ez9CBRZflyW3mvVE8H
KCyP8r3Oiz6/p/PJkR707BF9x50se5YFZYMm0WGg849kDIS0MfIX7c/BMZTcy2/4
a2vChzPkVFZBxbJvrT3K5NOuXNhBqc5odqAytDTnFJ3Y8R0Lq24KQJLjf8EZ1wk=
=KnpH
-----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.
