patch-delta: handle truncated copy parameters
commit9514b0b22624b9a6de80a480ab480d61ce29833b
authorJeff King <peff@peff.net>
Thu, 30 Aug 2018 07:12:52 +0000 (30 03:12 -0400)
committerJunio C Hamano <gitster@pobox.com>
Thu, 30 Aug 2018 17:30:23 +0000 (30 10:30 -0700)
tree7a3928743960beb407c2d8ae13e81d64bfbcd7c0
parentfa72f90e7a5cfbbc32860c6336628c96791b5af3
patch-delta: handle truncated copy parameters

When we see a delta command instructing us to copy bytes
from the base, we have to read the offset and size from the
delta stream. We do this without checking whether we're at
the end of the stream, meaning we may read past the end of
the buffer.

In practice this isn't exploitable in any interesting way
because:

  1. Deltas are always in packfiles, so we have at least a
     20-byte trailer that we'll end up reading.

  2. The worst case is that we try to perform a nonsense
     copy from the base object into the result, based on
     whatever was in the pack stream next. In most cases
     this will simply fail due to our bounds-checks against
     the base or the result.

     But even if you carefully constructed a pack stream for
     which it succeeds, it wouldn't perform any delta
     operation that you couldn't have simply included in a
     non-broken form.

But obviously it's poor form to read past the end of the
buffer we've been given. Unfortunately there's no easy way
to do a single length check, since the number of bytes we
need depends on the number of bits set in the initial
command byte. So we'll just check each byte as we parse. We
can hide the complexity in a macro; it's ugly, but not as
ugly as writing out each individual conditional.

Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
patch-delta.c
t/t5303-pack-corruption-resilience.sh