Detached signature ambiguity

[Nicholas Cole]

On Mon, Nov 10, 2014 at 12:25 PM, Peter Lebbing <peter at digitalbrains.com> wrote:
> 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.

In my view, the long experience of bugs like this suggests that it is
better to live with the short-term pain of breaking things in order to
get a robust solution, than to fix a solution in various ingenious
ways that themselves introduce a whole series of corner-cases and
opportunities for exploitation.  I hate breaking backwards
compatibility normally, but this seems like such a fundamental problem
I don't know what to do about it.

I *suppose* a fix would be to:

- introduce two new commands along the lines I suggested.

- make the old verify command:

1. Refuse to verify a detached signature without a .sig extension
2. Refuse to verify a non-detached-signature contained in a file with
a .sig extension.

But I don't like the solution, really. It introduces code that has to
be maintained, and sill leaves users vulnerable to tricks involving
unicode etc., so that the security it provides is itself an illusion.

In my view it is much better just to break the old --verify command
completely.  Scripts that are maintained will have a simple fix, and
scripts that are not will no longer give a completely false sense of
security.


Nicholas