Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Thu, 21 Mar 2024 16:13:54 +0100
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <uthirj$29aoc$1@dont-email.me>
References: <bug-20240320191736@ram.dialup.fu-berlin.de>
 <20240320114218.151@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 21 Mar 2024 15:13:55 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="9083fc13632a11f6b0fc246dd1fa196c";
	logging-data="2403084"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180k+29a8qKSF+SmmUIfNye8keaWQFqIUk="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:VKhQPVSA+91Z4bjBp9coiPmtKWY=
Content-Language: en-GB
In-Reply-To: <20240320114218.151@kylheku.com>
Bytes: 3384

On 20/03/2024 19:54, Kaz Kylheku wrote:
> On 2024-03-20, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>    A "famous security bug":
>>
>> void f( void )
>> { char buffer[ MAX ];
>>    /* . . . */
>>    memset( buffer, 0, sizeof( buffer )); }
>>
>>    . Can you see what the bug is?
> 
> I don't know about "the bug", but conditions can be identified under
> which that would have a problem executing, like MAX being in excess
> of available automatic storage.
> 
> If the /*...*/ comment represents the elision of some security sensitive
> code, where the memset is intended to obliterate secret information,
> of course, that obliteration is not required to work.
> 
> After the memset, the buffer has no next use, so the all the assignments
> performed by memset to the bytes of buffer are dead assignments that can
> be elided.
> 
> To securely clear memory, you have to use a function for that purpose
> that is not susceptible to optimization.
> 
> If you're not doing anything stupid, like link time optimization, an
> external function in another translation unit (a function that the
> compiler doesn't recognize as being an alias or wrapper for memset)
> ought to suffice.
> 

Using LTO is not "stupid".  Relying on people /not/ using LTO, or not 
using other valid optimisations, is "stupid".

/Really/ dealing with this kind of potential data leakage is a 
multi-faceted problem.  Does it matter if you zero out this buffer, if 
that is just in the cache and the original password data is still in the 
ram ready to be read with a Rowhammer attack?   Or if there is a copy 
somewhere else in code that used it?

Of course it is important to deal with possible security issues at every 
practical point, so zeroing out this buffer is part of the solution - as 
long as no one thinks that using C23's memset_explicit(), or similar 
functions, are somehow complete fixes.

Calling an external function in another translation unit, however, is 
not a way to guarantee particular effects.  Using volatile accesses is 
better (if you don't have a suitable function with the right guarantees 
for your target OS and/or C version).  There are also compiler-specific 
ways, such as adding "__asm__("" : "+m" (buffer));" after the memset.