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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8811 invoked from network); 3 Dec 2020 19:17:00 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Dec 2020 19:17:00 -0000 Received: (qmail 26156 invoked by uid 550); 3 Dec 2020 19:16:57 -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 26131 invoked from network); 3 Dec 2020 19:16:56 -0000 Date: Thu, 3 Dec 2020 14:16:44 -0500 From: Rich Felker To: Matthew Maurer Cc: musl@lists.openwall.com Message-ID: <20201203191644.GC534@brightrain.aerifal.cx> References: <20201202005539.6418-1-ariadne@dereferenced.org> <20201202013707.GU534@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] harden against unauthorized writes to the atexit function lists On Thu, Dec 03, 2020 at 09:55:02AM -0800, Matthew Maurer wrote: > 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. Discussion on IRC and subsequently on Twitter seems to have established that there are no direct paths for a reasonable program following libc interface contracts to clobber libc .data/.bss memory via attacker-controlled offset from a pointer valid for writing. So (assuming dynamic linking; otherwise it may be possible via offset from application .data/.bss) attacks on atexit array seem to require already having achieved significant control over the victim process. Rich