common.c and getpass.c and thread safety, zeroization

[Nikos Mavrogiannopoulos]

On 12/02/2010 08:31 PM, Jeffrey Walton wrote:
> The caching that is occurring -  via static data declaration - with
> respect to passwords in common.c and getpass.c appears to leak
> sensitive material. At minimum, routines are not following best
> practices regarding sensitive data such as passwords and PINs.
> 
> For example, if a password is only needed once, its unclear how to
> zeroize the memory in a static buffer from an invoked function after
> its use. Its also unclear how to specify that sensitive material, such
> as a password or PIN, *not* be cached.
> In addition, a static buffer in used in getpass.c. getline(3) states
> it will realloc if the required buffer for the password is too small.
> How does GnuTLS zeroize the memory in calls to getpass.c when the
> static buffer needs to grow? getline(3) makes no guarantees the data
> will be sanitized.
> Finally, the static buffers are not thread safe in its current
> implementation. stdin and stout out might be serialized, but threads
> which are concurrently executing routines such as getpass.c will leave
> the shared buffer in an unknown state since the buffer might change
> before the caller can copy out the correct [expected?] password.

getpass() is an old interface to read a password from keyboard. It is
not the best out there but there isn't any alternative I know of. If you
know some we would be interested to know.

regards,
Nikos