From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6400 Path: news.gmane.org!not-for-mail From: Richard Gorton Newsgroups: gmane.linux.lib.musl.general Subject: Re: magic constants in some startup code Date: Fri, 31 Oct 2014 10:31:45 -0400 Message-ID: <8B3E5DDE-2691-4377-8934-362ACC7BEA69@cognitive-electronics.com> References: <45BFC4C3-FA51-49B5-8C58-1C1FC075BD28@cognitive-electronics.com> <20141031141844.GA22465@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1414765926 15163 80.91.229.3 (31 Oct 2014 14:32:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2014 14:32:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6413-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 31 15:32:00 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XkDF9-00020V-JG for gllmg-musl@m.gmane.org; Fri, 31 Oct 2014 15:31:59 +0100 Original-Received: (qmail 32240 invoked by uid 550); 31 Oct 2014 14:31:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32230 invoked from network); 31 Oct 2014 14:31:57 -0000 In-Reply-To: <20141031141844.GA22465@brightrain.aerifal.cx> X-Mailer: Apple Mail (2.1510) Xref: news.gmane.org gmane.linux.lib.musl.general:6400 Archived-At: Thank you (and a follow up question) - what code looks at this canary? = It is assigned to pthread_self()->canary, but I do not see any code = inside musl itself that checks that value? A work in progress? Or does = other code check this value? Regards, Richard On Oct 31, 2014, at 10:18 AM, Rich Felker wrote: >=20 >> ---- >>=20 >> src/env/__stack_chk_fail.c >> else __stack_chk_guard =3D (uintptr_t)&__stack_chk_guard * = 1103515245; >>=20 >> the number equates to 0x41c64e6d. >> Called from __init_libc as: >> __init_ssp((void *)aux[AT_RANDOM]);=20 >> The kernel is putting a random number into aux[AT_RANDOM] at process = initialization. >> Why not just put a predictable arbitrary number into = __stack_chk_guard? >=20 > The reason you don't want a predictable arbitrary number for the stack > guard canary is that it makes it easy to bypass stack-protector by > including the known number in your overflow payload. >=20 > The idea in the above code, which really deserves a comment, is to > attempt to recover _some_ entropy from the address at which libc is > mapped (which hopefully was affected by ASLR) when AT_RANDOM is not > available. Modern Linux kernels always give you AT_RANDOM, so this > code path would only be taken on an ancient Linux version or a > non-Linux host. >=20 > The magic number 1103515245 is just a LCG, the same as what's used in > musl's rand_r() and in the C standard's sample rand(). It serves to > mix the bits somewhat, accounting for the likelihood that the mapping > address is not very random in some of its bits. >=20 > None of this is really very effective, but I've left it there because > it seems "better than nothing". >=20 > Rich