Bug 1535667

Summary: glibc: Information leak via glibc finished thread cache
Product: [Other] Security Response Reporter: Pedro Sampaio <psampaio>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: aoliva, arjun, ashankar, codonell, dj, fweimer, glibc-bugzilla, law, mfabian, mnewsome, pfrankli, rth, security-response-team, siddhesh, tcallawa
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-20 07:45:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1535668, 1535669, 1546604, 1546605    
Bug Blocks: 1535681    

Description Pedro Sampaio 2018-01-17 20:56:34 UTC
A flaw was found in glibc. GNU Libc have special caches to keep stacks and heaps of finished threads. This behavior may break ASRL by leaking addresses of ended thread stack or heap.

Comment 5 Huzaifa S. Sidhpurwala 2018-01-30 07:00:42 UTC
Statement:

This flaw can be used to leak addresses of data objects allocated on the stack or the heap. Since ASLR (Address Space Layout Randomization) is a post exploitation mitigation measure, Red Hat Product Security does not consider this as a security flaw, but rather a security hardening.

Comment 6 Doran Moppert 2018-02-19 01:47:49 UTC
Upstream bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=22852

Comment 7 Doran Moppert 2018-02-19 01:48:17 UTC
Created glibc tracking bugs for this issue:

Affects: fedora-all [bug 1546605]


Created glibc-arm-linux-gnu tracking bugs for this issue:

Affects: fedora-all [bug 1546604]

Comment 8 Adam Mariš 2018-03-01 11:00:26 UTC
Reference:

http://www.openwall.com/lists/oss-security/2018/02/27/5