[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Re: CVE request: 2 issues in inspircd
From:       cve-assign () mitre ! org
Date:       2015-08-26 2:26:54
Message-ID: 20150826022654.C3EC06C0019 () smtpvmsrv1 ! mitre ! org
[Download RAW message or body]

-----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 *!*@example.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-----
[prev in list] [next in list] [prev in thread] [next in thread]