From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6AB3F3851C1F; Fri, 8 May 2020 19:18:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6AB3F3851C1F From: "dj at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug malloc/25945] ASLR information leak via Safe-Linking and tcache or fastbin chunks. Date: Fri, 08 May 2020 19:18:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: malloc X-Bugzilla-Version: 2.26 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dj at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 19:18:21 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25945 dj at redhat dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dj at redhat dot com --- Comment #6 from dj at redhat dot com --- In the grand scheme of things, the big question is, "what can an attacker l= earn that the attacker doesn't already know?" Memory returned by malloc() has ALWAYS had dirty data in it, and in our case, has always had some form of pointer in it. However, if you have the address of the memory itself, you already know the base address of the heap and the address of the data in ea= ch chunk. Since the Safe-Linking feature uses the address of the data as the "randomness", a malicious actor already has everything they need. Safe-Lin= king reduces the ease of using that information, and protects against accidental corruption, but our implementation in no way hides information. If we had = used real random bits from the system, I would conclude differently. I have no objection to clearing internal data before giving memory to the application, but we must be careful about performance - we don't want to tu= rn malloc into calloc, but clearing a few words that are likely already in cac= he should be fine. So do we want to clear such data systematically, such as t= he proposed patch? Or in bulk, in malloc() itself, for all chunks? Note also that these chunks do NOT protect against an attacker calling free= () and using the free'd chunk to access the safe-linking data anyway. So IMHO this type of patch is a good idea if it protects against accidental corruption and/or helps us detect such cases (which is what Safe-Linking do= es), but if the goal is to protect against malice we should consider a more blan= ket solution, one which hides smallbin and largebin pointers as well. As for the proposed patch, LGTM otherwise ;-) --=20 You are receiving this mail because: You are on the CC list for the bug.=