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.