gpg,common: Make sure that all fd given are valid.
authorJustus Winter <justus@g10code.com>
Wed, 8 Feb 2017 12:49:41 +0000 (13:49 +0100)
committerJustus Winter <justus@g10code.com>
Wed, 8 Feb 2017 13:28:49 +0000 (14:28 +0100)
commit6823ed46584e753de3aba48a00ab738ab009a860
tree6fa13c04f89a665f0364e14d17e711df6f755520
parent56aa85f88f6b35fb03a2dc1a95882d49a74290e3
gpg,common: Make sure that all fd given are valid.

* common/sysutils.c (gnupg_fd_valid): New function.
* common/sysutils.h (gnupg_fd_valid): New declaration.
* common/logging.c (log_set_file): Use the new function.
* g10/cpr.c (set_status_fd): Likewise.
* g10/gpg.c (main): Likewise.
* g10/keylist.c (read_sessionkey_from_fd): Likewise.
* g10/passphrase.c (set_attrib_fd): Likewise.
* tests/openpgp/Makefile.am (XTESTS): Add the new test.
* tests/openpgp/issue2941.scm: New file.
--

Consider a situation where the user passes "--status-fd 3" but file
descriptor 3 is not open.

During the course of executing the rest of the commands, it's possible
that gpg itself will open some files, and file descriptor 3 will get
allocated.

In this situation, the status information will be appended directly to
whatever file happens to have landed on fd 3 (the trustdb? the
keyring?).

This is a potential data destruction issue for all writable file
descriptor options:

   --status-fd
   --attribute-fd
   --logger-fd

It's also a potential issue for readable file descriptor options, but
the risk is merely weird behavior, and not data corruption:

   --override-session-key-fd
   --passphrase-fd
   --command-fd

Fixes this by checking whether the fd is valid early on before using
it.

GnuPG-bug-id: 2941
Signed-off-by: Justus Winter <justus@g10code.com>
common/logging.c
common/sysutils.c
common/sysutils.h
g10/cpr.c
g10/gpg.c
g10/keylist.c
g10/passphrase.c
tests/openpgp/Makefile.am
tests/openpgp/issue2941.scm [new file with mode: 0755]