From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ouvsmtp1.octopuce.fr (ouvsmtp1.octopuce.fr [194.36.166.50]) by sourceware.org (Postfix) with ESMTPS id 70B723858D32 for ; Tue, 26 Jul 2022 14:27:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 70B723858D32 Received: from panel.vitry.ouvaton.coop (unknown [194.36.166.20]) by ouvsmtp1.octopuce.fr (Postfix) with ESMTPS id 69556AC4; Tue, 26 Jul 2022 16:27:26 +0200 (CEST) Received: from [192.168.0.20] (unknown [83.159.33.34]) by panel.vitry.ouvaton.coop (Postfix) with ESMTPSA id B1A7B5E26E6; Tue, 26 Jul 2022 16:27:25 +0200 (CEST) Message-ID: Date: Tue, 26 Jul 2022 16:27:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Overwrittting AT_RANDOM after use (was Re: arc4random - are you sure we want these?) Content-Language: fr-FR To: Florian Weimer , "Jason A. Donenfeld via Libc-alpha" Cc: "Jason A. Donenfeld" , Yann Droneaud , Michael@phoronix.com, linux-crypto@vger.kernel.org, jann@thejh.net, dalias@libc.org References: <87bktdsdrk.fsf@oldenburg.str.redhat.com> <87v8rlqscj.fsf@oldenburg.str.redhat.com> From: Yann Droneaud In-Reply-To: <87v8rlqscj.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 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 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: Tue, 26 Jul 2022 14:27:31 -0000 Hi, Le 25/07/2022 à 14:39, Florian Weimer a écrit : > * Jason A. Donenfeld via Libc-alpha: >> (After all, I didn't see any wild-n-crazy fallback >> to AT_RANDOM like what systemd does with random-util.c: >> https://github.com/systemd/systemd/blob/main/src/basic/random-util.c ) > I had some patches with AT_RANDOM fallback, including overwriting > AT_RANDOM with output from the seeded PRNG. It's certainly messy. I > probably didn't bother to post these patches given how bizarre the whole > thing was. It's not that bizarre as I have some patches too: I tried to harden the way stack_chk_guard and pointer_chk_guard were computed. Those values are currently generated from slices of AT_RANDOM by the loader. But I've seen in the wild program reusing AT_RANDOM, thus possibily leaking stack_chk_guard and pointer_chk_guard values. Having a proper (CS)PRNG in the loader, initialized from AT_RANDOM, that overwrites AT_RANDOM (with fresh entropy if possible) after initialization, would improve programs abusing AT_RANDOM purpose. Regards. -- Yann Droneaud OPTEYA