From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-10.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28362 invoked from network); 3 Dec 2020 17:55:34 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Dec 2020 17:55:34 -0000 Received: (qmail 14224 invoked by uid 550); 3 Dec 2020 17:55:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14202 invoked from network); 3 Dec 2020 17:55:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ew6oqxT7oKVWDhqAbXnHpCIZ3rdfEQBZRwSc+0pMh7Q=; b=oTZvfz08cHhYiafK2hYCmddtRLPethIDKjs0+We3Sjq0qHtS/1AlHPfj9v7j1ylx1R +Owm9b5nolYRNLfrfL8Y2GRECgJVJ39E3/avUpO6YOjIIrkEd96yDf8giv/joucR685y 7aY/d7U+QIuQonadoPzV5lyz3qcamRM+9ZVe/8NI+LF0sFpPi1CuezRj4NG8gX6IwrCA tCrbqtCiqUR7gNrWG379HbefVrvtlojgr0G5NltYfNwyw31z05SRG+c3IkPK5WRLnVFt 8LeQRxx/41nDmjeHI2TRycWuJ+C8W6OB69Gen7I6A6YWzpD+E827Cq5Jaquhhzpcukv5 FNXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ew6oqxT7oKVWDhqAbXnHpCIZ3rdfEQBZRwSc+0pMh7Q=; b=KC8Cv5K3TAGJViiZytPaRm4s5MCgfDiYgMNXhu/303/OWr5ZN2mxArYtaTIeXbV+2U O2XHco3MNLZy+vgKQ/MTNST1vcPsvtoM8ZomgUxKXoc0p1SI4foCL/04PGkYNEuaZ6t3 vh9l+l/9zvjYwuqQHJjLMUmItyFz65t8w7gS19cxkQDMVwGZIGpapcnPan4HTUawH927 sC6qhFMrOCottcvuBwMgq05BvOeXGRNPG/BejqM4tR1yskjErdwwzkqDCHaJUyRcJ1fT od8PKBmtynoOEdl4ApBfE7xT8hGG1qwealT6N22Epu/0e8ccVVUC4LKfCtyPjUwcdLDP WFQg== X-Gm-Message-State: AOAM530MlAXYGklQiIxjc2PeVPNAw+JifonJMWrJNf0bHyh1TvvMCxVx OPAj4f6o+MUz8TE/bKMNhrUgLjT6UvCse9iuIW5J1JTHtlmR0Q== X-Google-Smtp-Source: ABdhPJxngmlZ6HgupTEOqr1PkDTjeRZFksdzZsrQ1XgEUEeVnTwA80n8I1ftgEn885lrOQQzt4crucdREDRECdNnED8= X-Received: by 2002:a4a:95e6:: with SMTP id p35mr215242ooi.38.1607018114364; Thu, 03 Dec 2020 09:55:14 -0800 (PST) MIME-Version: 1.0 References: <20201202005539.6418-1-ariadne@dereferenced.org> <20201202013707.GU534@brightrain.aerifal.cx> In-Reply-To: <20201202013707.GU534@brightrain.aerifal.cx> From: Matthew Maurer Date: Thu, 3 Dec 2020 09:55:02 -0800 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000db22b005b5930f19" Subject: Re: [musl] [PATCH] harden against unauthorized writes to the atexit function lists --000000000000db22b005b5930f19 Content-Type: text/plain; charset="UTF-8" While we are not a supported system, I would also note that I work on a project which *does* expect `atexit` to work properly, but does not have a working anonymous mmap system due to how resource management works for us. If ASLR is enabled, that should already mitigate the ability of an attacker to write to this location. While placing these in anonymous pages would be a further defense against cases where a pointer is leaked *and* an arbitrary overwrite is present, this would be an argument for a more complete form of randomization (see also pagerando, https://lists.llvm.org/pipermail/llvm-dev/2017-June/113794.html ) rather than trying to randomize the location of individual chunks of sensitive data. On Tue, Dec 1, 2020 at 5:37 PM Rich Felker wrote: > On Tue, Dec 01, 2020 at 05:55:39PM -0700, Ariadne Conill wrote: > > previously, the first atexit list block was stored in BSS, which means an > > attacker could potentially ascertain its location and modify it, allowing > > for its abuse as a code execution mechanism. > > > > by moving the atexit list into a series of anonymous mmaped pages, we can > > use mprotect to protect the atexit lists by keeping them readonly when > they > > are not being mutated by the __cxa_atexit() function. > > This is a non-starter. atexit is specifically required by the standard > to succeed when called no more than 32 times, which is why we have 32 > built-in slots that always exist. If you really want to pursue > something here it should probably just be protecting the pointers with > some secret... > > Rich > --000000000000db22b005b5930f19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While we are not a supported system, I would also note tha= t I work on a project which *does* expect `atexit` to work properly, but do= es not have a working anonymous mmap system due to how resource management = works for us.

If ASLR is enabled, that should already mi= tigate the ability of an attacker to write to this location. While placing = these in anonymous pages would be a further defense against cases where a p= ointer is leaked *and* an arbitrary overwrite is present, this would be an = argument for a more complete form of randomization (see also pagerando, ht= tps://lists.llvm.org/pipermail/llvm-dev/2017-June/113794.html ) rather = than trying to randomize the location of individual chunks of sensitive dat= a.

On Tue, Dec 1, 2020 at 5:37 PM Rich Felker <dalias@libc.org> wrote:
On Tue, Dec 01, 2020 at 05:55:39PM -0700, Ari= adne Conill wrote:
> previously, the first atexit list block was stored in BSS, which means= an
> attacker could potentially ascertain its location and modify it, allow= ing
> for its abuse as a code execution mechanism.
>
> by moving the atexit list into a series of anonymous mmaped pages, we = can
> use mprotect to protect the atexit lists by keeping them readonly when= they
> are not being mutated by the __cxa_atexit() function.

This is a non-starter. atexit is specifically required by the standard
to succeed when called no more than 32 times, which is why we have 32
built-in slots that always exist. If you really want to pursue
something here it should probably just be protecting the pointers with
some secret...

Rich
--000000000000db22b005b5930f19--