From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A4012393F059; Wed, 13 May 2020 15:22:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A4012393F059 From: "carlos 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: Wed, 13 May 2020 15:22:55 +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: carlos 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: 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: Wed, 13 May 2020 15:22:55 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25945 --- Comment #9 from Carlos O'Donell --- (In reply to wangxu from comment #7) > Thanks for patient reply. > I'm considering whether there's a more blanket solution. Thanks again. >=20 > BTW, is it better to give a change to perturb pointers returned by > tcache_get(), using alloc_perturb (p, bytes) ? This is a *distinct* issue. Should M_PERTURB effect tcache? I think it shou= ld, so please file another bug for this. The issue we are talking about today is the prevention of ASLR bits leaking from known locations in the chunk metadata. If we can reduce this leakage w= ith minimal performance loss, because the data is already in the cache and the write is cheap, then that has value. I haven't seen any more responses on OSS Security regarding the issue of allocating a CVE. Our current policy is that "Information disclosure can be security bugs, especially if exposure through applications can be determine= d." and in this case we have no direct exposure through applications that we kn= ow about, so I think allocating a CVE, particularly for an unreleased version = of glibc, is premature. In which case we should continue working on this as a patch to fix the ASLR leakage. Could you please review my comments in https://sourceware.org/bugzilla/show_bug.cgi?id=3D25945#c3 and review that = we need to clear the pointers for tcache *and* fastbin? After such review, please post a patch to libc-alpha for review. It would be good if you run `make bench` before and after your patch and review the mal= loc performance doesn't show any unexpected problems (bench-malloc-simple, bench-malloc-thread). Likewise confirm no regressions on x86_64. Thanks. --=20 You are receiving this mail because: You are on the CC list for the bug.=