Re: A secure string library?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-07-09 16:15:20

On 7/9/24 19:08, Andrey Semashev wrote:
> On 7/9/24 18:41, Josh Juran wrote:
>> On Jul 9, 2024, at 10:24 AM, Andrey Semashev via Boost <boost_at_[hidden]> wrote:
>>
>>> As far as secure erase functions go, there's no variance about whether
>>> it works or not. It either works as specified in the contract or it has
>>> a bug. And it's fairly easy to make it work as intended anyway.
>>
>> secret_string::~secret_string()
>> {
>> #if HAVE_SECURE_MEMSET
>>
>> 	secure_memset( ptr, ‘\0’, len );
>>
>> #else
>>
>> 	memset( ptr, ‘\0’, len );
>>
>> #endif
>>
>> 	free( ptr );
>> }
>>
>> The above will work most but not all of the time, depending on toolchain, OS, and even build settings.  You might have a compiler that elides the memset() call (perhaps only at certain optimization levels) with an OS or libc that lacks secure_memset(), or you might have neglected to include the header that defines the feature-test macro.
> 
> That would be a bug in secret_string. The correct implementation would
> unconditionally call secure_memset and secure_memset would be
> implemented in a way that prevents the compiler from eliding it. The
> typical implementations either use volatile or a dummy asm statement
> that potentially consume the data to be cleared.

That should say "consume the buffer that was cleared."

>>> The question is rather is the secure erase enough to consider your data
>>> safe from leaks. It definitely is not. But not allowing it to leak into
>>> heap and remain there for extended periods of time is a necessary step
>>> towards better security. Even having just that protection alone is
>>> better than not having anything at all.
>>
>> You might also consider having the sensitive string XORed with a one-time pad (possibly using a different allocator), so it’s never in the clear in its entirety.  But I’m not a security expert and can’t speak to the efficacy of that scheme.  At least it probably won’t be inadvertently undone by a sufficiently “smart” compiler.
> 
> Having XORed data and the XOR seed both in memory at the same time is
> pretty much the same as having the data in clear form.
> 
>> A more important mitigation IMO is a timing-safe memcmp(), as the information otherwise leaked traverses not just process boundaries, but networks.
> 
> memset does not depend on the data, so normally it is not timing sensitive.
> 
> memcmp and similar functions that may return early are timing-sensitive,
> but this is a problem separate from secure data cleanup.
>