From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bumble.maple.relay.mailchannels.net (bumble.maple.relay.mailchannels.net [23.83.214.25]) by sourceware.org (Postfix) with ESMTPS id 6FED43858004 for ; Thu, 29 Oct 2020 08:04:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6FED43858004 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 40387640F7D; Thu, 29 Oct 2020 08:04:50 +0000 (UTC) Received: from pdx1-sub0-mail-a59.g.dreamhost.com (100-100-138-5.trex.outbound.svc.cluster.local [100.100.138.5]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id CEB31640E33; Thu, 29 Oct 2020 08:04:49 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a59.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.10); Thu, 29 Oct 2020 08:04:50 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Industry-Industry: 68b99e8754104435_1603958690084_3983579193 X-MC-Loop-Signature: 1603958690084:3577468858 X-MC-Ingress-Time: 1603958690084 Received: from pdx1-sub0-mail-a59.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a59.g.dreamhost.com (Postfix) with ESMTP id 949247F04D; Thu, 29 Oct 2020 01:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gotplt.org; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=gotplt.org; bh=FNoxfo MA15G/OzZ17R54oCWecXU=; b=E8KL7gtqFrRBRtryoCHscmi1uZupApRYr5RX3c /WBqynvvs3l8cdQxYMIL9fmZmmJpDM5+QOfQf/J8oulITZ4bSOb4SooEp2TbQsUM +0hXNHuEY2YqLyChsxyxj3CDTmrcZQ9bmEYltz++Ktwlm4NMTLk4drFhYj433zzM k6GPY= Received: from [192.168.1.111] (unknown [123.252.202.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a59.g.dreamhost.com (Postfix) with ESMTPSA id 99CF17F00D; Thu, 29 Oct 2020 01:04:48 -0700 (PDT) Subject: Re: Randomize offset between program segments? To: Topi Miettinen , libc-alpha@sourceware.org References: <412c5a60-fbaf-d53b-3be9-32efe496509a@gmail.com> X-DH-BACKEND: pdx1-sub0-mail-a59 From: Siddhesh Poyarekar Message-ID: <7e9c9068-917b-5bb6-1500-f2be9786bd1b@gotplt.org> Date: Thu, 29 Oct 2020 13:34:37 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 08:04:53 -0000 On 10/21/20 4:14 PM, Topi Miettinen wrote: >> The alternative (which is what PIC does for global variables) is to ha= ve >> a GOT-like indirection, where instead of the single pc-relative load, >> the compiler emits a load from that table and a subsequent load from t= he >> address in GOT.=C2=A0 Here, patching by the dynamic linker is safe sin= ce the >> offset table is rw, but you will have doubled the number of instructio= ns >> needed to access your data. >=20 > Also size of GOT will increase. Otherwise this seems a better approach. You shouldn't use GOT (because it's the *global* offset table) but a similar idea. A rose by another name... > I don't know. What would be the method to quantify such benefits? This > applies to a specific case where the attacker is able to determine an > address in one segment but needs to find an address in another segment > in order to win, and without ASLR the offset between the addresses woul= d First build evidence for this possibility, i.e. how easy is it to determine the address of one segment in a binary and how much *incremental* effort does it take to determine the address of other segments? > be always known by the attacker (for example, because the distro and th= e > version for the program or library is known). Without ASLR, chance of > winning is 100%. With ASLR, this could be related to number of bits in > randomization. In the 32 bit offset case this would be 20 bits (assumin= g > 12 bits page size), so the chances of guessing would be 2^-20 and brute > forcing the offset would be expected to take 2^20/2 attempts. Question is, would it really be an additional 2^20 tries at all times? For example, the offset table has to be at a known offset from the code and hence could be computed once you know the address of the code segment. From there, the final address for the data access is just an indirection away. Siddhesh