Bug#696234: apt: Signed Debian control block parsing can be fooled
Hi!
On Fri, 2013-03-15 at 17:28:31 +0100, David Kalnischkies wrote:
> On Thu, Mar 14, 2013 at 7:31 PM, Guillem Jover wrote:
> > So (from what I wrote on the initial bug report) SigVerify::RunGPGV()
> > would not be able to parse something like:
> >
> > "-----BEGIN PGP SIGNATURE----- \t \n"
>
> For the signature, this might to be a problem, for the message
> (which I thought you are referring to) I still think §7 is the authority
> as it not an amored header (line) but a "cleartext header" (line).
The way I see it, §6.2 describes the general format of an Armored
Message, and even refers (implicitly) to §7 for the specifics of
"cleartext signatures" and "cleartext signed messages". So the latter
is just a particular instance of the former, and all format details
described there apply.
> Yet, as §7.1 says that "any trailing whitespace […] at the end of
> any line is removed when the cleartext signature is generated."
> I question even why I should expect to see such a signature.
This refers to the "cleartext signature" generation, i.e. that any
spaces in the "cleartext message" will get discarded when computing
the signature, not that they will get removed from the output file
(they could though, as they are irrelevant for signature verification
purposes anyway, and §7 is very clear that this framework might not
be reversible).
And this is pretty easy to test, just sign something like the
following text («gpg --clearsign test.txt»), edit test.txt.asc
and remove the trailing whitespace, and verify the signature
(«gpg --verify test.txt.asc»).
,--- test.txt.asc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Test lines with
trailing whitespace
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlFJJHEACgkQuW9ciZ2SjJsTwgCeOCXz/bhD9T+/PThUhI+VjHd3
350An2ysqI+SpYEYg7EtH4+/R66e4lf7
=b7L8
-----END PGP SIGNATURE-----
`---
> And given that paragraph §6.2 is referring to formatting ASCII Amor
> which a clear-text message is not as §7 is so quick to outline I
> question if §6.2 should have relevance in §7 at all without special
> invocation by name, but this might destroy everything.
As I've written above it describes the general format, and yes also how
to ASCII Armor the message part too. The "cleartext signed message"
(not the cleartext itself) is still in Armored form, and §7 has this
to say:
,---
It is desirable to be able to sign a textual octet stream without
ASCII armoring the stream itself, [...]
`---
which to me seems like confirmation enough. It even goes on to mention
“"Hash" Armor Headers” and “ASCII armored signature(s)” only by
reference, which were described before in detail in §6.2, and not in
this section.
> > And in additiona SourcesWriter::DoPackage() should not be able to
> > handle an OpenPGP message starting with stuff like:
> >
> > "-----BEGIN PGP MESSAGE----- \t \n"
> > "Hash: SHA1\n"
> > " \n"
> > "<SIGNED MESSAGE>\n"
>
> Beside again invoking §7.1 and repeating that "cleartext header" isn't
> mentioned as a possible Amored Header line, §7 also says about
> the line following the Hash Armor Header(s):
> "Exactly one empty line not included into the message digest,"
>
> For me an empty line is in fact empty and not just a short way of
> saying "doesn't contain printable characters". gpgv obviously
> has a more relaxed interpretation …
See above, the way I interpret it is as just a shorthand for
“- A blank (zero-length, or containing only whitespace) line”.
The RFC could probably do with some rewording to make that very
clear. I'll try to get in contact with the authors to see to this.
> >> (I wonder now how someone is supposed to sign a message
> >> containing whitespace sourcecode …)
> >
> > I don't think trailing whitespace is in this context usually (ever?)
> > significant anyway?
>
> https://en.wikipedia.org/wiki/Whitespace_%28programming_language%29
> (the remark was a joke)
Ah sorry I missed it. :)
In any case, in those situations I guess one can always use Armored
Signatures («gpg --armor --sign»).
> >> APT code also doesn't support dash-escaped text so far.
> >
> > Neither does dpkg, but that should be fine because they only accept
> > deb822 (?) which only allows message lines starting with fields names
> > or spaces, and field names cannot start with a dash.
>
> I agree in theory, its just that §7.1 says:
> "An implementation MAY dash-escape any line"
> and an attacker might use this to disable fields, but if my testing is
> correct gpgv doesn't allows at least this currently …
> (which would be a bug if I am right, but I am not complaining)
Both gpgv and gpg allow any (non-dash-escaped) arbitrary line (in the
cleartext part of a cleartext signed message) being dash-escaped, even
after the fact, because the signature is computed before dash-escaping;
just prepend «- » to any signed line, and the message will verify as
good. But as I mentioned before this does not matter, because any deb822
parser will (should) choke on those as field names are not allowed to
start with «- » and continuation lines should start with a space anyway.
Thanks,
Guillem
Reply to: