Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150826022654.C3EC06C0019@smtpvmsrv1.mitre.org>
Date: Tue, 25 Aug 2015 22:26:54 -0400 (EDT)
From: cve-assign@...re.org
To: sdelafond@...il.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: 2 issues in inspircd

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> the Debian Security Team is requesting 2 CVEs for inspircd.
> 
>   * the fix that was included in Debian for CVE-2012-1836 is incomplete,
>     and does not solve the original remote code execution problem. See:
> 
>       https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780880#5
> 
>   * a DoS can be triggered by invalid DNS packets. See:
> 
>       https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780880#5
>       https://github.com/inspircd/inspircd/commit/58c893e834ff20495d007709220881a3ff13f423

We think 3 CVE IDs are needed; see below. (Two of them are
CVE-2012-#### IDs because a 2012 commit message announced the
vulnerability.)

>> I am an upstream maintainer for InspIRCd. The patch you have for
>> CVE-2012-1836 (patches/03_CVE-2012-1836.diff) is not the same patch we
>> released as part of 2.0.7 (there was no 2.0.6) to address the CVE. It
>> appears to be a a version of this commit:
>> https://github.com/inspircd/inspircd/commit/9aa28f3730fb3dd69c1e06f78bb2bbc43d36c684.
>> However this commit was never in a release, and was only in git for
>> about 6 days (due to someone other than me pulling it in).

It appears that 9aa28f3730fb3dd69c1e06f78bb2bbc43d36c684 did
accomplish something. For example, it adds an "if (o +
header.payload[i] > sizeof(DNSHeader))" test that was not present in
the 2.0.5 dns.cpp, but is present in the 2.0.7 dns.cpp. Therefore, it
is necessary to have a new CVE ID associated with the remaining
original problem.

>> This commit and your patch do not fix the problem. You can still send
>> maliciously crafted packets and cause remote code execution. This was
>> fixed in
>> https://github.com/inspircd/inspircd/commit/ed28c1ba666b39581adb860bf51cdde43c84cc89,
>> prior to the 2.0.7 release.

Because the ed28c1ba666b39581adb860bf51cdde43c84cc89 patch is:

  -  if (length - i < 10)
  +  if (static_cast<int>(length - i) < 10)

this implies that the original problem was in handling the case where
i is greater than length, and thus a "length - i < 10" comparison is
something like a "4000000000 < 10" comparison. The original patch
attempted to fix this with:

  -  if (length - i < 10)
  +  if ((unsigned) length - i < 10)

which doesn't accomplish anything. Use CVE-2012-6696 for this
vulnerability involving mishandling of unsigned values.


>> Furthermore, your patch introduces a buffer underflow where it has
>> "i =- 12" and not "i -= 12". This causes it to start reading from
>> before the packet's buffer. It is unclear to me what this can cause.

We disagree with this analysis. The Debian patch in question is in the
http://anonscm.debian.org/cgit/collab-maint/inspircd.git/commit/?id=c9c6b10b9f1489d3c9fb3929dfe73c26ffec89a4
commit from 2012-04-09. Here, debian/patches/03_CVE-2012-1836.diff
adds the problematic "i =- 12" line but also changes the data type of
i from int to unsigned. Thus, "i =- 12" sets i to a value greater than
4 billion, the "i < length" test will be false, and the while loop
will exit. As far as we can tell, nothing is read from outside a
buffer. We think the general outcome is that decompression for CNAME
and PTR records results in safely determining the wrong answer. We
didn't look at what types of wrong answers can occur: possibly the
result can be either an empty string or a truncated name. Our guess is
that this is security relevant because IRC daemons can rely on DNS
lookups for access control, e.g., to support

  /MODE #channel +b *!*@...mple.com

but we didn't look at the specific role of dns.cpp in InspIRCd. In any
case, we want to assign a CVE ID for the code problem of "i =- 12"
where "i -= 12" was intended: use CVE-2015-6674. Again, this has a
directly resultant issue in which there's misuse of an unsigned
variable, and (possibly?) an indirectly resultant issue of ban bypass.


>> Additionally, at the same time I commited
>> 58c893e834ff20495d007709220881a3ff13f423 to prevent malicious packets
>> from causing InspIRCd to infinite loop. This is not a part of the CVE
>> as it does not allow remote code execution, but is still a critical
>> problem due to the potential for denial of service.

Use CVE-2012-6697 for this infinite-loop issue.

- -- 
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

iQIcBAEBCAAGBQJV3SINAAoJEL54rhJi8gl5mcoQAKVaZtXyEh0zbdf3LeEPvZ6p
e5ptlLFvcCqcX9eq9WTPA0Bq1n1+SzWafGhIBpr7SW0P6PkWw8NYmAP0rJPL7aD7
CIFEo2a8GcvPptaB4lzTZlxYogBHvIDiuDIpVi02yJlHCQJSLjN2ckOFWQy5WBD7
GT7vCgq4VQxC+u6O87Roj13yXaEaDdwBXDJH2v8JTKR1/yyJ8SexHjXDXbsKfyum
+0SfwUED4BVtPw1gpjgWdtlXyPpTi16/uSofUOWZe6ohCzBE2yB74E1dfbu/wOMK
YidVNjfiQT7svXdlQEmWSe64dCsEWMKLlCqEZ3LTSwfYadXKfMMzZUFfHGLNGpRV
qQB6RuZIMc8+tkuQfKL4iIAE7FMgTMQqurbURxJDwoDCEpI5yqeel/HWYKn1kkvq
Hm5kux9wwU0vsTJiPbJKijy0OejC5esHGMTTQNhQR9Cn6X3dHugD1LoG8nuJ59wb
glzRlj3yZgntZX8MnoumrdV8hfWwxJ2iH29rJ4KqrtgAq5zQ7auB4fb6Lp3SG6du
qvQcEXRslXrItgMOo9DYhB2szIhPjopOpD40Q+SmRPeCRVdBUoZ944mnYpi4liWu
VRORW7Ztg5nOnvxeQGYa543zv4GMQx0ehHVoOhJjZyvAvIphVBncsR2riN4qR2pD
09GUl6VPwiWtDD8wHt+U
=cRan
-----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.