Detached signature ambiguity

Peter Lebbing peter at digitalbrains.com
Mon Nov 10 13:25:53 CET 2014


On 10/11/14 13:03, Nicholas Cole wrote:
> But in fact, it is the fact that scripts depend on this that made me
> think that this might be a case where things *should* get broken,
> because this is actually a serious security flaw, and the scripts in
> question need fixing.  In many cases, no one is going to be around to
> read the warning you suggest.

Hmmm, very solid point... unfortunately :(. Not a pretty situation to be
in at all...

It still suggests to me it should only break when normally there would
be a detached signature verified (i.e., without the .sig extension) but
it is not because it is not a detached signature. I suppose these
scripts wouldn't work anyway when files are named as in my problematic
example:

gnupg_2.1.0.tar.bz2
gnupg-2.1.0.tar.bz2.sig

So simply returning error in the case where there /is/ a full match
seems to fix the scripting case. It still leaves the user-driven case,
because the user can still be foiled by a single-character change.

It might be possible for an attacker to force a signature verification
failure of a script if he can name files in the same directory. Suppose
a script is supposed to verify ledger.csv.asc, which is /not/ a detached
signature, but simply has the data embedded. An attacker could create a
file in the same dir with the name ledger.csv and cause the ambiguity
detecting mechanism to trigger falsely, leading to signature
verification failure. Whether this is a real issue, I don't know.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>



More information about the Gnupg-users mailing list