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

[Simon Josefsson]

Jeffrey Walton <noloader at gmail.com> writes:

> 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.

Improvements are welcome, it is not easy to do in a portable and easy to
maintain way.

> 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.

The command line tools are not threaded, so I don't believe this is
relevant.  Getpass is not used by the GnuTLS library.

/Simon