Daniel Kahn Gillmor writes:
My understanding is that OpenPGP's packet grammar is well-defined.
Encountering a new version 20 versions in advance should be no more confusing
than encountering a version 2 versions beyond what is known.
It's not that it's confusing, it's that it's a value that almost certainly
isn't valid. We have endless CVEs for vulnerabilities in "security" software
caused by it blindly accepting anything an attacker cares to throw at it with
no concept of sanity-checking or range-checking the values. Seeing a version
of 5 or 6 when the current one is 4 is valid; seeing a version of 23 when the
current version is 4 is something that should be rejected by any sanity-check.
As for the "corrupted data" interpretation: when encountering a signature, if
a particular signature is corrupt, it should not validate. That doesn't mean
that the stream itself should be rejected.
See above. Once you've hit data that looks wrong, you need to stop processing
it before some of it can be used to trigger a vulnerability in your code.
(I've mostly stopped occasionally filling out fields in security protocols
with valid-according-to-the-spec but otherwise outrageous values after taking
out, among other things, carrier-grade routers, an IBM parallel sysplex, and a
large commercial CA. On the one hand it was a bit naughty, but on the other
hand none of that should ever have been possible if they'd applied the most
basic sanity checks on input values rather than accepting any old rubbish on
the basis that it's bound to be OK).
The packet headers clearly delimit the size of the packets.
Right, but only for individual packets. Unlike CMS which encapsulates data
OpenPGP just concatenates everything together. In other words CMS has, for
the detached signatures in the test data:
message {
signature 1,
signature 2,
signature 3
}
and you can tell as soon as you start processing the message that if you can't
handle signature 1, more signatures will follow. With the OpenPGP format
OTOH you get:
signature 1,
signature 2,
signature 3
and if you can't handle signature 1 and it's a streaming implementation you
can't tell whether more signatures that you may be able to process will turn
up later. With the CMS case you know that more signatures follow #1 and can
return a more-data-required error, with OpenPGP you can't tell whether more
signatures follow #1 so you don't know whether to return a signature-check-
failed error (if none follow) or a more-data-required error (if some follow).
It would be good if the RFC contained some guidance on what to do here, to get
consistency among implementations in terms of how they report this situation.
Peter.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp