[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: common.c and getpass.c and thread safety, zeroization
From: |
Simon Josefsson |
Subject: |
Re: common.c and getpass.c and thread safety, zeroization |
Date: |
Mon, 06 Dec 2010 15:42:03 +0100 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) |
Jeffrey Walton <address@hidden> 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