Bug#696234: apt: Signed Debian control block parsing can be fooled
(Disclaimer: I am not arguing that we don't need to fix this – we are working
on it – the following just outlines why I think that it is a "bug" in
gpgv and/or other implementations that we have to fix to use them …)
On Thu, Mar 14, 2013 at 7:31 PM, Guillem Jover <guillem@debian.org> wrote:
> I think you might have been confused by the nomenclature, and my lack
> of more explicit detail, perhaps? Or I missunderstood your comment.
Yeah, I messed up the naming a bit … guilty as pledged.
> 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).
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.
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.
> 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 …
>> (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)
>> 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)
Best regards
David Kalnischkies
Reply to: