Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 572416 (CVE-2015-8776, CVE-2015-8778, CVE-2015-8779)

Summary: <sys-libs/glibc-2.22-r2: multiple vulnerabilities (CVE-2015-{8776,8778,8779})
Product: Gentoo Security Reporter: Agostino Sarubbo <ago>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Status: RESOLVED FIXED    
Severity: major CC: toolchain
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
URL: http://www.openwall.com/lists/oss-security/2016/01/19/11
Whiteboard: A2 [glsa cve]
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 560420    

Description Agostino Sarubbo gentoo-dev 2016-01-20 08:20:53 UTC
From ${URL} :

we are preparing the glibc 2.23 release upstream and have fixed the
following security bugs which, to my best knowledge, lack public CVE
assignment so far:

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.

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.

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.

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.

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.





@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 SpanKY gentoo-dev 2016-01-20 16:24:21 UTC
at least LD_POINTER_GUARD is already fixed in our 2.22-r1 ebuild, but some of those are most likely not
Comment 2 SpanKY gentoo-dev 2016-01-24 08:33:53 UTC
CVE-2015-8776 (strftime) is fixed for glibc-2.23 and cherry picked to 2.22

CVE-2015-8778 (hcreate) is still not fixed but is under discussion

CVE-2014-9761 (nan) is fixed for glibc-2.23 and cherry picked to 2.22

CVE-2015-8779 (catopen) is fixed for glibc-2.23 and cherry picked to 2.22

once the hcreate issue is sorted out upstream, i'll roll a glibc-2.22-r2
Comment 3 SpanKY gentoo-dev 2016-01-26 18:30:09 UTC
i've got all the fixes queued for a 2.22-r2, but am waiting on CVE-2015-8778 to be resolved.  they're blocking the 2.23 release on it, so it should be soon.
Comment 4 SpanKY gentoo-dev 2016-02-16 20:52:35 UTC
i've backported most of the fixes to 2.21-r2 and all of them to 2.22-r2

2.21-r2 will go stable via bug 574880, and 2.22-r2 will take time to bake
Comment 5 Thomas Deutschmann gentoo-dev Security 2016-12-13 14:09:48 UTC
(In reply to SpanKY from comment #4)
>> [...]
>> CVE-2014-9761 (nan) is fixed for glibc-2.23 and cherry picked to 2.22
>> [...]
> 
> i've backported most of the fixes to 2.21-r2 and all of them to 2.22-r2
> 
> 2.21-r2 will go stable via bug 574880, and 2.22-r2 will take time to bake

Mike, according to your comment #4 the fix for CVE-2014-9761 (nan) should be included in -2.22-r4. Can you please help me identifying the patch? I failed to find it by name or grep. So from my view, we have _no_ fix for CVE-2014-9761 in stable.
Comment 6 SpanKY gentoo-dev 2016-12-14 16:26:50 UTC
maybe it didn't land in the glibc-2.22 patchset, so it's fixed in glibc-2.23+.  i'm not going to backport it now.

for future reference, don't file more than one issue in one bug.  this was a pita to track, and now it'll be even more of a pain.
Comment 7 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-12-14 20:57:20 UTC
(In reply to SpanKY from comment #6)
> maybe it didn't land in the glibc-2.22 patchset, so it's fixed in
> glibc-2.23+.  i'm not going to backport it now.
> 
> for future reference, don't file more than one issue in one bug.  this was a
> pita to track, and now it'll be even more of a pain.

Seriously? You explicitly stated you cherry picked the fix in a previous comment.  You even elaborated on what fix you were waiting for.  Now someone checks it and you complain?

Yes, the bugs should can and will be dealt with in a cleaner manner.
Comment 8 SpanKY gentoo-dev 2016-12-15 15:17:13 UTC
(In reply to Aaron Bauman from comment #7)

i have no idea wtf your problem is.  i missed a patch out of many across multiple versions of glibc.  i'm not complaining, i'm stating a fact.

the fix i was tracking/waiting for earlier was not strtod/nan, it was hcreate, and that is in the 2.22 patchset.

another set of facts are:
 - glibc-2.22-r4 is already in stable
 - glibc-2.23-r3 is already in unstable
 - adding any patches to 2.22 now won't see any testing before it goes stable
 - glibc-2.23 is most likely going to go stable in that time frame anyways
 - this particular issue does not appear to be serious

you need to step back, chill out, and evaluate reality before yelling at people.
Comment 9 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-12-16 01:06:37 UTC
(In reply to SpanKY from comment #8)
> (In reply to Aaron Bauman from comment #7)
> 
> i have no idea wtf your problem is.  i missed a patch out of many across
> multiple versions of glibc.  i'm not complaining, i'm stating a fact.
> 
> the fix i was tracking/waiting for earlier was not strtod/nan, it was
> hcreate, and that is in the 2.22 patchset.
> 
> another set of facts are:
>  - glibc-2.22-r4 is already in stable
>  - glibc-2.23-r3 is already in unstable
>  - adding any patches to 2.22 now won't see any testing before it goes stable
>  - glibc-2.23 is most likely going to go stable in that time frame anyways
>  - this particular issue does not appear to be serious
> 
> you need to step back, chill out, and evaluate reality before yelling at
> people.

I am not yelling at anyone. I don't do that. If you missed a patch that is fine, but don't tell us it was due to the bug report.  You were clearly tracking it and said it was cherry picked.

I agree, it can be painful with multiple vulnerabilities listed in one bug report.  We will make sure it is done properly for future bugs. Although, what @ago does is up to him. I try and make sure we lay it out simply so the maintainers are not overwhelmed trying to find the appropriate patches.

We will open a new bug considering latest stable does not have the patch.  Once 2.23 goes stable we can address it then considering upstream included the patch.

Again, not yelling at anyone and I would never do that. Missing a patch is not the end of the world. Thanks for your work and all that you do with base system.
Comment 10 GLSAMaker/CVETool Bot gentoo-dev 2017-02-19 12:39:54 UTC
This issue was resolved and addressed in
 GLSA 201702-11 at https://security.gentoo.org/glsa/201702-11
by GLSA coordinator Thomas Deutschmann (whissi).