Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 25 Aug 2015 22:26:54 -0400 (EDT)
Subject: Re: CVE request: 2 issues in inspircd

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:
>   * a DoS can be triggered by invalid DNS packets. See:

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

>> 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:
>> 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
>> 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
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 *!*

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 ]
Version: GnuPG v1


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.