- To: bugs@gnu.org
- Subject: libc/796: getpass() is not usable for high security applications
- From: ak@muc.de
- Date: 19 Sep 1998 16:13:06 -0000
- Resent-Cc: gnats-admin@gnu.org
- Resent-Reply-To: bugs@gnu.org, ak@muc.de
- Resent-To: libc-gnats@gnu.org
>Number: 796
>Category: libc
>Synopsis: getpass does not allow to pass a buffer in
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: libc-gnats
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Sat Sep 19 12:20:00 EDT 1998
>Last-Modified:
>Originator: Andi Kleen <ak@muc.de>
>Organization:
Unorganized
>Release: libc-2.0.7
>Environment:
Host type: i686-pc-linux-gnu
System: Linux kali 2.1.121 #332 Sat Sep 19 14:35:13 MEST 1998 i686 unknown
Architecture: i686
Addons: crypt linuxthreads localedata
Build CFLAGS: -O2 -m486 -fno-strength-reduce -DNDEBUG=1
Build CC: gcc -B$(common-objpfx)
Build shared: yes
Build profile: yes
Build omitfp: no
Stdio: libio
>Description:
getpass() contains static state and allocates its memory itself. This has
the following problems:
- It is not thread-safe. This is not a big prob because it is unlikely that
two threads want to access /dev/tty at the same time, but still a problem,
because the resulting buffers may not be shared.
- The bigger problem: it is not usable for cryptographic applications.
In such an application it is not wanted when the key data hits the swap
partition, thus all key dependent data must be stored in a mlock()ed area.
This is not possible with getpass and makes it useless.
BTW I personally find the getpass() behaviour change that it always flushes
the input from libc5 annoying, because I can't type su\npassword continuously
now, it always loses characters in this case.
>How-To-Repeat:
RTFS.
>Fix:
Define a __getpass or getpass_r interface that allows to pass a buffer pointer
in.
Make sure that no data from the input is stored outside the buffer.
>Audit-Trail:
>Unformatted: