Summary of a v-s conversation: Colin Watson and Kees Cook reported that the early patch for CVE-2010-3847 [1] was not sufficient to fix the issue. The official patch [2] needs to be used instead. Thomas Hoger then noted that the early patch needs to be reverted, and another patch [3] has to be applied for the issue to be completely fixed. I have checked the patchset in our latest stable glibc, we still have [1] but do not have [3]. [2] is in our patches and fine. Kees also provided another PoC which worked with our current patches, but failed with the proper configuration of +[2] +[3] -[1] So, what would be the update path? I guess 2.12 is not yet ready for stable. [1] http://sourceware.org/ml/libc-hacker/2010-10/msg00007.html [2] http://sourceware.org/ml/libc-hacker/2010-10/msg00010.html [3] http://sourceware.org/ml/libc-hacker/2010-12/msg00001.html
ive already punted [1] and outlined that it has no bearing on us, and was never actually merged upstream. if the only thing [3] is doing is basically what [1] is doing (ignoring $ORIGIN for set*id binaries), then i dont think we need to bother with a refresh. i outlined too how (1) this has long been a known issue and (2) portage prevents installing set*id binaries with $ORIGIN in it.
(In reply to comment #1) > ive already punted [1] and outlined that it has no bearing on us, and was never > actually merged upstream. if the only thing [3] is doing is basically what [1] > is doing (ignoring $ORIGIN for set*id binaries), then i dont think we need to > bother with a refresh. I'll try -[1] -[3] +[2] tomorrow. If the PoC still fails, we can skip that one. But Thomas (RedHat) and Kees (Ubuntu) seem to agree that both (2 and 3) are needed.
if the PoC involves $ORIGIN, i dont care. if it doesnt, then something is indeed wrong and needs fixing.
So what if it involves $ORIGIN ? I care of security even for stuff that doesn't come out of portage, if the fix is in ONE SIMPLE PATCH THAT ONE UPSTREAM REJECTED AND OTHER DISTRIBUTIONS APPLY.
drop the caps bullshit. if upstream isnt going to apply the patch, then we arent either.
You're not going to just be the one deciding here, it's a security issue, upstream has less to say than any general issue.
it really isnt. and yes, by virtue of being the glibc maintainer, i do get to veto it. there is no security issue for packages installed via the tree as i've pointed out multiple times. people installing binary packages with set*id is their problem. ive looked at the upstream git tree and neither [1] nor [3] have been merged which means there's nothing to do.
I have no intention of entering the debate, but please do not make this information public. I politely ask that we leave disclosing this information to or Alex or Tobias. Thank you.
there is nothing new here. we've already discussed the ORIGIN vs set*id issue at great length in multiple other bugs.
(In reply to comment #9) > there is nothing new here. we've already discussed the ORIGIN vs set*id issue > at great length in multiple other bugs. > That may very well be the case; I do not know. I do believe however, that this bug contains information shared with us carrying some expectation of confidentiality. If it was--regardless of the actual sensitivity of the contents--we need to respect that. Hopefully I am just wasting our time. But if not, I am asking that we wait a few hours for Alex or Tobias to chime in as I believe they were the only ones to witness the original conversation. Thanks again.
I hope we're done now with the open/close game. (In reply to comment #1) > ive already punted [1] and outlined that it has no bearing on us, and was never > actually merged upstream. From the CVS yes, but it is still in the patchset version 6 as 0062_all_glibc-no-ORIGIN-setuid.patch which afaics is used in the latest stable. This patch makes things actually worse, so we'll need a revbump at least removing that patch. I'll be asking about the other patch and inclusion in the master branch.
i know it's in the patchset because i didnt want to force a revbump to remove a useless patch. in what ways exactly is it "harmful" (and thus would necessitate a bump) ?
(In reply to comment #12) > i know it's in the patchset because i didnt want to force a revbump to remove a > useless patch. in what ways exactly is it "harmful" (and thus would > necessitate a bump) ? > It disables expanding $ORIGIN in such a way that it loads libraries from $pwd. Combine with a suid binary and a crafted directory. Granted, it's a complicated scenario, but given the little effort needed to remove the vector, it's worth updating. (I can email you the PoC with the original description if needed). Now about the other patch upstream did not include in the master branch. It seems that they won't be applying it, and having the new patch *as well as* removing the older patch is sufficient to fix CVE-2010-3847. This other patch should actually address another issue: "What remains unfixed is handling of privileged programs with $ORIGIN in R*PATH." Maybe you have some thoughts on that.
i'll bump to glibc-2.11.3 which would include an updated patchset with 0062_all_glibc-no-ORIGIN-setuid.patch dropped. afaict, there's nothing else necessary here.
(In reply to comment #14) > i'll bump to glibc-2.11.3 which would include an updated patchset with > 0062_all_glibc-no-ORIGIN-setuid.patch dropped. afaict, there's nothing else > necessary here. > Alex and Mike, thanks for this. Should we move to stabilize =sys-libs/glibc-2.11.3?
i havent seen any complaints about glibc-2.11.3, but i dont know how much coverage we've seen. shouldnt be too much of a problem though to stabilize it.
(In reply to comment #16) > i havent seen any complaints about glibc-2.11.3, but i dont know how much > coverage we've seen. shouldnt be too much of a problem though to stabilize it. > Ok, thanks. Now we have bug 356913 to stabilize 2.12.2 which doesn't contain 0062_all_glibc-no-ORIGIN-setuid.patch. Let's keep an eye on that bug instead of stabilizing 2.11.3, just to be immediately replaced by 2.12.2. Let me know if you disagree. Thanks.
i dont have a problem stabilizing this now. should be trivial while the glibc-2.12 will be a bit more of a pain.
This issue is now public. For our reference: https://bugzilla.redhat.com/show_bug.cgi?id=667974 http://lists.debian.org/debian-security-announce/2011/msg00005.html https://lists.ubuntu.com/archives/ubuntu-security-announce/2011-January/001226.html (In reply to comment #18) > i dont have a problem stabilizing this now. should be trivial while the > glibc-2.12 will be a bit more of a pain. > Ok, thank you. Arches, please test and mark stable: =sys-libs/glibc-2.11.3 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
ppc/ppc64 stable
amd64 ok
x86 done. Cheers.
Stable for HPPA.
amd64 done. Thanks Agostino
alpha/arm/ia64/sh/sparc stable, s390 won't do as we use what ibm recommends, which is glibc-2.10.1
the ibm stream recommendations only go so far ... if there are security issues in newer glibc versions, then i dont have a problem updating. and iirc, there are multiple security issues we've addressed by stabilizing glibc-2.11.x over glibc-2.10.x rather than back ported. so we probably want to update s390 now.
um, can you please take a look at bug 358127?
it isnt specific to a glibc version
Thanks, folks. GLSA request filed.
time to close this out ? glibc-2.13 is long stable at this point ...
This issue was resolved and addressed in GLSA 201312-01 at http://security.gentoo.org/glsa/glsa-201312-01.xml by GLSA coordinator Chris Reffett (creffett).