From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by sourceware.org (Postfix) with ESMTPS id AAAB83858D1E for ; Sun, 1 Jan 2023 08:34:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=FQRVAshakm ZbIIDO6VkHgRJIoByLQaO6+VPxx0VNqyk=; h=date:references:in-reply-to: subject:cc:to:from; d=openbsd.org; b=D+RJqzndzSCRO4n8i8/dOotGOuVUXTZnm qCexU23P0QDiFVL3zNnos2zhdDLvxAxMhvnU/dw++/FL+Smrh7tBgy10ECZ8KWnACBe/Pd /9TN+3Gb/jY0mXdrScRg8RvmBCqC1bZlQBsT/crl+Hm0IbwItcnjvyt9mVlvtygPXsVvqd lhnViOQH+nI8wZOgOqUKUQTdCJJimvxWbtY+X8iLP01DW+w4BLZvLcDh34Fhf1POokNffO Ky/iU7EeOZeG6WLkmBWJZRY4TDbff5oKvUqBrYWqu1dlCi9WO54dXpRD3em1Q/5mVmL6mo LvT6K9vK1w1LnDKGEwUFGT5GnndAQ== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id 02099046; Sun, 1 Jan 2023 01:34:26 -0700 (MST) From: "Theo de Raadt" To: Alejandro Colomar cc: Damien Miller , libc-alpha@sourceware.org, Alejandro Colomar , Theo de Raadt , "Todd C . Miller" , "Jason A. Donenfeld" , =?UTF-8?Q?Cristian_Rodr=c3=adguez?= , Adhemerval Zanella , Yann Droneaud , Joseph Myers , otto@cvs.openbsd.org Subject: Re: [PATCH] Give a useful meaning to arc4random_uniform(0); In-reply-to: <55ecb133-a9c4-e36e-7202-69fceaaf49b4@gmail.com> References: <20221231023653.41877-1-alx@kernel.org> <5084.1672476619@cvs.openbsd.org> <55ecb133-a9c4-e36e-7202-69fceaaf49b4@gmail.com> Comments: In-reply-to Alejandro Colomar message dated "Sun, 01 Jan 2023 00:58:01 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48589.1672562066.1@cvs.openbsd.org> Date: Sun, 01 Jan 2023 01:34:26 -0700 Message-ID: <96735.1672562066@cvs.openbsd.org> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Alejandro, Your arguments are childishly wrong. Your API will not be incorporated, and the existing API will not be changed. Please stop. Alejandro Colomar wrote: > Hello Damien, > > On 1/1/23 00:07, Damien Miller wrote: > > On Sat, 31 Dec 2022, Theo de Raadt wrote: > > > >> Also, right now an (incorrect?) call of arc4random_uniform(0) > >> will return 0, but with your proposal it will return a non-zero > >> number. Have you audited the entire universe of software to > >> ensure that your change doesn't introduce a bug in some other > >> piece of software? I doubt you did that. Very unprofessional > >> of you to not study the impact and just wave the issue away. > >> > >> I think Special-casing the value of 0 to mean something new > >> and undocumented behaviour makes no sense. It is even potentially > >> undocumentable. > > I agree - specifying a zero upper-bound is numerically nonsensical, > > and could often be the result of a bug in the caller. > > Changing it is likely to break code like this in a plausibly > > exploitable > > way: > > elem_t *random_elem(elem_t **elems, size_t nelems) { > > return elems[arc4random_uniform(nelems)]; > > } > > The above code is already broken. In case nelems is 0, the array has > exactly 0 elements, so the pointer &elems[0] is a pointer to > one-past-the-last element. It is legal to hold such a pointer, but not > to dereference it (I guess I don't need to quote the standard here). > > Such a pointer dereference *is dangerous*, and *is very-likely exploitable*. > > Having a random 32-bit number instead is likely to be a pointer > addressing an invalid memory address, and result in a crash. And > crashes are good, right? > > > Changing the behavior of arc4random_uniform() wouldn't make this code > more broken, but rather uncover the bug in it. > > > Therefore IMO the only safe return from arc4random_uniform(0) is 0. > > I'd argue it's the opposite. 0 is the most unsafe value it can return > in such a case, since it's the least likely to result in a crash. The > Undefined Behavior is invoked, and in a way that is likely to modify > memory that is available to the process. > > 42 would be a better value. > An even better value would be UINT32_MAX, which would almost-certainly > guarantee a crash everywhere. > However, it makes more sense to just let it be an unbounded random > value, which will likely result in the same crashes as with > UINT32_MAX, but would be more useful for other purposes. > > > That changing make it fractionally simpler to implement one > > particular > > wrapper doesn't IMO justify it. > > -d > > Cheers, > > Alex > > -- >