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

[David Shaw]

On Thu, Sep 30, 2004 at 11:06:22AM -0400, Yaron Minsky wrote:
> On Wed, 29 Sep 2004 22:58:00 -0400, David Shaw <address@hidden> wrote:
> >
> > Like I've been saying, it is very difficult to filter out bad packets
> > since once you establish a packet is bad, the whole stream needs to be
> > called into question.  In this particular case, the packets are being
> > corrupted in a very particular way.  Sure, I could code something to
> > detect this exact case, and may well do so in the future, but
> > regardless, SKS should not accept things that are completely invalid
> > according to the standard.
> 
> 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.  We assume
that the packet is bad because the MPI length field extends beyond the
bounds of the packet.  In fact, the MPI could be just fine and the
packet length field could be short.  In that case, following the
supposedly valid packet is data that can easily appear as a new
packet, but is really the end of the previous packet.

Example 400-byte stream:

  Packet of length 100
   {
    MPI of 50 bytes
    MPI of 350 bytes
   }

  Packet of length X
   {
    etc.
   }

  Packet of length Y
   {
    etc.
   }

  Packet of length Z
   {
    etc.
   }

You cannot assume because the first packet has a MPI that runs beyond
the end of the packet that the first packet is invalid, but the
following ones are valid.  The reason is that there is only one packet
in that stream:

  Packet of length 400
   {
    MPI of 50 bytes
    MPI of 350 bytes
   }

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.  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.

> 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.

David