Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 350744 - <sys-libs/glibc-2.11.3: CVE-2010-3847 patches cleanup
Summary: <sys-libs/glibc-2.11.3: CVE-2010-3847 patches cleanup
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High critical (vote)
Assignee: Gentoo Security
URL:
Whiteboard: A1 [glsa]
Keywords:
Depends on: 357005
Blocks:
  Show dependency tree
 
Reported: 2011-01-05 21:36 UTC by Alex Legler (RETIRED)
Modified: 2013-12-03 04:14 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Legler (RETIRED) archtester gentoo-dev Security 2011-01-05 21:36:04 UTC
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
Comment 1 SpanKY gentoo-dev 2011-01-05 23:04:46 UTC
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.
Comment 2 Alex Legler (RETIRED) archtester gentoo-dev Security 2011-01-06 00:08:41 UTC
(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.
Comment 3 SpanKY gentoo-dev 2011-01-06 01:02:44 UTC
if the PoC involves $ORIGIN, i dont care.  if it doesnt, then something is indeed wrong and needs fixing.
Comment 4 Diego Elio Pettenò (RETIRED) gentoo-dev 2011-01-06 01:12:43 UTC
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.
Comment 5 SpanKY gentoo-dev 2011-01-06 01:37:14 UTC
drop the caps bullshit.  if upstream isnt going to apply the patch, then we arent either.
Comment 6 Diego Elio Pettenò (RETIRED) gentoo-dev 2011-01-06 01:43:01 UTC
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.
Comment 7 SpanKY gentoo-dev 2011-01-06 04:02:24 UTC
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.
Comment 8 Tim Sammut (RETIRED) gentoo-dev 2011-01-06 04:12:56 UTC
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.
Comment 9 SpanKY gentoo-dev 2011-01-06 05:04:17 UTC
there is nothing new here.  we've already discussed the ORIGIN vs set*id issue at great length in multiple other bugs.
Comment 10 Tim Sammut (RETIRED) gentoo-dev 2011-01-06 05:23:08 UTC
(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.
Comment 11 Alex Legler (RETIRED) archtester gentoo-dev Security 2011-01-06 13:45:05 UTC
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.
Comment 12 SpanKY gentoo-dev 2011-01-06 18:59:01 UTC
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) ?
Comment 13 Alex Legler (RETIRED) archtester gentoo-dev Security 2011-01-08 19:33:39 UTC
(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.
Comment 14 SpanKY gentoo-dev 2011-01-08 22:52:06 UTC
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.
Comment 15 Tim Sammut (RETIRED) gentoo-dev 2011-02-27 19:07:52 UTC
(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?
Comment 16 SpanKY gentoo-dev 2011-02-28 17:12:53 UTC
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.
Comment 17 Tim Sammut (RETIRED) gentoo-dev 2011-03-01 03:38:58 UTC
(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.
Comment 18 SpanKY gentoo-dev 2011-03-01 04:18:43 UTC
i dont have a problem stabilizing this now.  should be trivial while the glibc-2.12 will be a bit more of a pain.
Comment 19 Tim Sammut (RETIRED) gentoo-dev 2011-03-01 14:06:33 UTC
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"


Comment 20 Kacper Kowalik (Xarthisius) (RETIRED) gentoo-dev 2011-03-01 16:45:20 UTC
ppc/ppc64 stable
Comment 21 Agostino Sarubbo gentoo-dev 2011-03-01 19:35:33 UTC
amd64 ok
Comment 22 Thomas Kahle (RETIRED) gentoo-dev 2011-03-01 21:54:21 UTC
x86 done. Cheers.
Comment 23 Jeroen Roovers (RETIRED) gentoo-dev 2011-03-03 06:29:09 UTC
Stable for HPPA.
Comment 24 Markos Chandras (RETIRED) gentoo-dev 2011-03-04 19:27:34 UTC
amd64 done. Thanks Agostino
Comment 25 Raúl Porcel (RETIRED) gentoo-dev 2011-03-07 11:26:18 UTC
alpha/arm/ia64/sh/sparc stable, s390 won't do as we use what ibm recommends, which is glibc-2.10.1
Comment 26 SpanKY gentoo-dev 2011-03-07 12:39:20 UTC
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.
Comment 27 Michael Weber (RETIRED) gentoo-dev 2011-03-10 02:52:36 UTC
um, can you please take a look at bug 358127?
Comment 28 SpanKY gentoo-dev 2011-03-10 03:41:02 UTC
it isnt specific to a glibc version
Comment 29 Tim Sammut (RETIRED) gentoo-dev 2011-03-10 13:50:44 UTC
Thanks, folks. GLSA request filed.
Comment 30 SpanKY gentoo-dev 2012-04-13 23:30:04 UTC
time to close this out ?  glibc-2.13 is long stable at this point ...
Comment 31 GLSAMaker/CVETool Bot gentoo-dev 2013-12-03 04:14:21 UTC
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).