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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ