Date: Tue, 19 Jan 2016 21:51:10 -0500 (EST) From: cve-assign@...re.org To: fweimer@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE assignment request for security bugs fixed in glibc 2.23 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The MITRE CVE team generally can assign IDs for security-fix releases of products where a notable upstream vendor has already made a final determination of what issues are, from their perspective, vulnerabilities that require customers to perform a product update. This is, to some extent, independent of what our perspective otherwise would have been. Based on the set of issues mentioned, however, we probably don't have a shared understanding of what glibc bugs should be considered vulnerabilities and what ones should be considered ordinary bugs. This doesn't mean that there ought to be a decision process that is specific to glibc alone: there are people sending CVE ID requests to MITRE for other libraries, including similarly general-purpose libraries. Possibly part of the glibc vulnerability model is that memory-safety issues should be considered vulnerabilities, regardless of how unlikely it is for an attack to cross a privilege boundary. Similarly, possibly part of the model is that issues in which glibc simply provides the wrong answer are not vulnerabilities, regardless of whether there's a plausible scenario in which the wrong answer leads to a catastrophic security failure. If there should be some CVE IDs for wrong-answer issues, we don't know the best way to subdivide the space of wrong answers, e.g., wrong results in floating-point math are perhaps attackable less often than wrong results in string operations. None of this is going to be resolved today, so here are the five CVE IDs for the listed issues. > Passing out of range data to strftime() causes a segfault > https://sourceware.org/bugzilla/show_bug.cgi?id=18985 > > Out-of-range time values passed to the strftime function may cause it to > crash, leading to a denial of service, or potentially disclosure > information. Use CVE-2015-8776. We don't happen to know of any cases in which a reasonable application would, for example, allow a user to enter an integer value that refers to the 13th month in a way that crosses a privilege boundary. The glibc change might suggest that that application should be happy with output of the form "19 ? 2016" (the 19th day of an unknown month in 2016). We feel that there's a (probably weak) argument that this is a defense-in-depth change to glibc, not a vulnerability fix, because there's no universally understood way for glibc to inform an arbitrary application that it has elected to produce a malformed, but memory-safe, result. > LD_POINTER_GUARD is not ignored for privileged binaries > https://sourceware.org/bugzilla/show_bug.cgi?id=18928 > > LD_POINTER_GUARD was an environment variable which controls > security-related behavior, but was not ignored for privileged binaries > (in AT_SECURE mode). This might allow local attackers (who can supply > the environment variable) to bypass intended security restrictions. Use CVE-2015-8777. We don't feel that there is any way to conclude that this is a vulnerability unless confirmed by the upstream vendor (and it obviously is confirmed). For example, maybe LD_POINTER_GUARD was originally envisioned as a defense against remote attacks, and the ability of unprivileged local users to run setuid/setgid programs with LD_POINTER_GUARD=0 was an intentional workaround for scenarios in which pointer guarding was not working properly. > hcreate((size_t)-1) should fail with ENOMEM > https://sourceware.org/bugzilla/show_bug.cgi?id=18240 > > This is an integer overflow in hcreate and hcreate_r which can result in > an out-of-bound memory access. This could lead to application crashes > or, potentially, arbitrary code execution. Use CVE-2015-8778. We don't happen to know of any cases in which an application allows a user to specify hcreate arguments in a way that crosses a privilege boundary. > nan function unbounded stack allocation > https://sourceware.org/bugzilla/show_bug.cgi?id=16962 > > A stack overflow (unbounded alloca) can cause applications which process > long strings with the nan function to crash or, potentially, execute > arbitrary code. Use CVE-2014-9761. Here, it seems somewhat more plausible that the nan argument would ultimately originate from untrusted input in a way that crosses a privilege boundary. We don't know of a specific example that would be realistic. > catopen() Multiple unbounded stack allocations > https://sourceware.org/bugzilla/show_bug.cgi?id=17905 > > A stack overflow (unbounded alloca) in the catopen function can cause > applications which pass long strings to the catopen function to crash > or, potentially execute arbitrary code. Use CVE-2015-8779. At least for the https://sourceware.org/bugzilla/show_bug.cgi?id=17905#c0 example, we don't happen to know of any cases in which an application allows a user to specify an arbitrary pathname in a way that crosses a privilege boundary, and then decides to catopen that pathname. - -- 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 iQIcBAEBCAAGBQJWnvVjAAoJEL54rhJi8gl5hXAQAJb94GQ4nmQNvRV/oxuJ8gkP GIjkWpfVAeHLJQZ4wxbFIBFrwexeimaZFICEyRnjsA8Jcw0vfdfKy+WbygpgmVuo jp38VYkreUXH1ZHJTEX+uTx7ySnKClccZ/599VwzYTMA5JI65srqtqMW52EOC0Lp nbqsW7aaQ9rJpXOqcgPNPHf01JIDOgzVMlIkzolWN5dP8YbwIvmWwfOQk0SePJj7 6fhdj6M12Kob0uqytI4zTSnKa0z2qXC0SsoPgcxtWOqQut7oYhMESMD2a9zbhKPj 5X4QdICT9ki86ysvujZV3+QoxkBJwd09nWY2AZm/vVgvTzNdArq2V+BPsNkLK+IJ xt1u385bw2GYjskLnr2UdyrbOQO5lqgcX9O/7+bzRbWhJsW58iIVwiX/a+slB7Bw CvaI565uncU6tR+UNUAT7BTJu2YLfGdqYzMG0G7rKmPVno0+q21cxjyigKpkRKxL yq95x3Ww/Yq4CIN4weGjAsOhtQ7h/5AP1D+aOgYp09KcvoKhV9meORCwmg0qZv5V RDr+7EquBWOuO84O8LnRcDFpiRPT+P1+CtS+YRo/tlLEVVTo5pe50+9t/7v7ey2o xta3mjd8tUdV4GWyItbn1Wzp0rv28/1kttlVJ6oUMpLzAFY8iQHJi+lmVtV+bDT2 Ta6wlakhBjLtTQ7bCWtU =VJ/C -----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