Re: [Sks-devel] another bounds problem in SKS

[Yaron Minsky]

On Thu, 30 Sep 2004 12:05:10 -0400, David Shaw <address@hidden> wrote:
> On Thu, Sep 30, 2004 at 11:06:22AM -0400, Yaron Minsky wrote:
> > Well, that's not quite true.  It's actually quite easy to filter out
> > the bad packets.  The packet-level structure is quite intact --- just
> > the inside of the packets is broken.
> 
> You can only hope the packet-level structure is intact.  

You don't have to hope.  You can assume.  Because it the packet-level
structure is broken, the key is toast under all circumstances. 
Whereas, if the packet structure is right, then you can recover
against lower-level errors.

SKS religiously maintains packet structure.  What that means is that
every key accepted by SKS has to have a plausible packet structure. 
As a result, even if a key with bogus data is merged in with a good
key, the good parts of the key will always be salvageable.  The
resulting key will have broken pieces, but the packet-level structure
is maintained, and so bad packets (and the packets that depend on
them) can simply be dropped to obtain a well-formed key.

> [ much sensible discussion of bad-packet example deleted]

> The corruption was that the first packet had a bad length.  The
> additional packets were "created" from the last 300 bytes of the
> second MPI.  It is unfortunately easy for this to happen, since the
> packet header is just a byte like any other.  

Well, there are some contrains.  I believe the 7th bit of the header
has to be 1, and the 6th bit has to be 0 or 1.  Also, if the packet is
bogus, the packet length is likely to be longer than the length of the
total stream.  But your point is well taken:  it's certainly not
overwhlemingly unlikely that the packet structure will spuriously look
intact.

> To be sure, it is
> unlikely these packets will be meaningful (say, a encrypted data
> packet inside a stream of key packets), and unlikely they will have
> sane lengths.  The last packet in the stream is especially unlikely to
> have a sane length field.
> 
> My point is that packetizing is not enough, and just because a stream
> is packetable does not mean that what you are parsing is the actual
> packet structure.  Once you see corruption, you need to have at least
> some suspicion about what follows.  What to do about that suspicion
> will vary depending on the immediate application.

Agreed.  I guess that all I'm arguing is that in this case, GPG should
be trying to clean up the key and make it usable.  The true
verification lies in the cryptography anyway.  And I do think that
assuming the correctness of the packet structure is the right first
step, since without the packet structure, you have no hope of decoding
the stream anyway.

> > I do think GPG is wrong to drop the whole stream, it should (and
> > could) just drop the packet in question.  But we've already beaten
> > this argument to death, especially considering the fact that the
> > existence of an installed base of GPG and PGP products pretty much
> > dictates the way SKS should behave.
> 
> Yes.  I may change GnuPG to try and work around this, but it is
> important that the problem is clearly stated.
> 

Agreed.  And you've certainly clarified my understanding of this
problem a fair bit.  I'm hoping to have the necessary patches out in
the next few days.

y