Page MenuHome GnuPG

GPG hangs waiting for input decrypting bad file when --batch specified
Closed, ResolvedPublic


I've reproduced this on Solaris 10 and Ubuntu 6 for 64 bit linux.

I'm trying to make a transition option that is compatible with our ancient PGP2
binary. I created the file using the steps indicated here.

Occasionally, the file I create with these steps is slightly corrupted, and when
GPG tries to decrypt it, in batchmode, it hangs, waiting on input from the
command line.

I've attached the keyring and the corrupt file. The command I use to decrypt is:
gpg --decrypt --batch --yes corrupt.gpg



Event Timeline

werner removed a project: Bug Report.
werner added a subscriber: werner.

Please describe exactly what you are doing. Refering to an outdated manual is
not really helpful to see what is going on. I degrade this to nobug for now as
it seems to be a support case; something we usually don't want to have in a bug

The bug I'm reporting is that certain bad-formatted files can cause GPG to hang
in batch mode. It is my understanding that GPG should never hang waiting for
user input when in batch mode. It should process the file and either properly
decrypt or or terminate with an error. Since certain input can make it hang
instead, there is a bug.

I am using GPG to automatically decrypt and check signatures of email messages.
Since this is an automated process, I'm using the --batch and --yes flags (as
described earlier). However, in my testing, certain encrypted files were able
to make my GPG process hang indefinitely waiting for input, even though it it is
being invoked in batch mode. This is bad because it creates a DOS
vulnerability, a flood of emails of these invalid files could quickly tie up all
the processes on my machine.

I created such a bad formatted file one time out of 50 in a test script
(following the instructions in the url I gave), but my bug report isn't about
the corrupt file, it's about GPG's bad response to the file. I've included a
secring, pubring and sample file which can be used to reproduce the bad
decryption behavior.

To reproduce:

unzip the attachment to /tmp/gpg_bug

#run the following command, you will see the output, and then notice that
#it hangs until you hit CTRL-D

GNUPGHOME=/tmp/gpg_bug/gnupg gpg --decrypt --batch --yes /tmp/gpg_bug/corrupt.gpg
gpg: encrypted with 768-bit RSA key, ID 49BB32A3, created 2008-07-14

"CryptFactory Test Key (Old RSA Nopass 2) <>"

testing, encrypt this!
How are you?

Type CTRL-D here

gpg: can't handle this ambiguous signature data
gpg: WARNING: message was not integrity protected

I am sorry, but the sample file is not useful for me. It requires the use of
the IDEA algorithm. I can't use this.

What might be going on here is that after decryption the signature looks like a
detached signature and gpg tries to read the data belonging to the signature
from stdin. The solution is to redirect stdin to /dev/null. You should do this
always in scripts to catch such situations.

Redirect stdin from /dev/null seems to work as a workaround and I will change
my application to call it like that. But it was my understanding that the --
batch flag explicitly means that the program should never expect input on
stdin. Allowing the program to hang waiting for stdin seems to go against the
point of that option.

If you agree this point is valid, then please consider reviewing the places
where the code reads from stdin based on the decrypted file information and
erroring out if the --batch parameter was used.

werner claimed this task.

No, that is not correct. --batch just means that the program is not run
interactivly. Whether stdin is connected to a tty or a pipe does not matter.
All proper Unix tools behave this way. If you call a program which takes input
from stdin, it is always a very good idea to connect stdin to /dev/null.

Agreed, it is not easy to see that gpg takes input from stdin given that there
is already a file argument on the command line. But gpg has to work on two data
sources from time to time (i.e. with detached signatures) and thus it needs stdin.

I'll add a line to the description of --batch.