The symbol alphabet used for encoding ranges of backward distances in
a Deflate compressed block contains 32 symbol values, but two of them
(symbols 30 and 31) have no meaning, and hence it is an encoding error
for them to appear in a compressed block. If a compressed file did so
anyway, this decompressor would index past the end of the distcodes[]
array. Oops.
This is clearly a bug, but I don't believe it's a vulnerability. The
nonsense record we load from distcodes[] in this situation contains an
indeterminate bogus value for 'extrabits' (how many more bits to read
from the input stream to complete the backward distance) and also for
the offset to add to the backward distance after that. But neither of
these can lead to a buffer overflow: if extrabits is so big that
dctx->nbits (which is capped at 32) never exceeds it, then the
decompressor will simply swallow all further data without producing
any output, and otherwise the decompressor will consume _some_ number
of spare bits from the input, work out a backward distance and an
offset in the sliding window which will be utter nonsense and probably
out of bounds, but fortunately will then AND the offset with 0x7FFF at
the last minute, which makes it safe again. So I think the worst that
a malicious compressor can do is to cause the decompressor to generate
strange data, which of course it could do anyway if it wanted to by
sending that same data legally compressed.
[originally from svn r10278]
gcc 4.8 compiling with -O3 gives a new warning about the access to
st->pending at the top of lz77_compress, because for some reason it
thinks there's an out-of-bounds array access there (or perhaps just a
potential one, I'm not really sure which side -Warray-bounds is erring
on). Add an assertion reassuring it that st->npending can't get bigger
than the size of st->pending at the site it's complaining about, and a
second one at the site where st->npending is increased (just in case
my analysis of why it can't happen was wrong!). Also add a comment
explaining the assertions.
[originally from svn r10144]
(Since we choose to compile with -Werror, this is particularly important.)
I haven't yet checked that the resulting source actually compiles cleanly with
GCC 4, hence not marking `gcc4-warnings' as fixed just yet.
[originally from svn r7041]
middle of a PDF. So here's a modification to sshzlib.c which enables
it to be compiled into a standalone Zlib decoder if you define
ZLIB_STANDALONE. As an added bonus, it (both standalone and in
PuTTY) also validates the Zlib header, just to make sure someone
hasn't defined a new compression format.
[originally from svn r4657]
reading) in the zlib code when fed certain kinds of invalid data. As
a result, ssh.c now needs to be prepared for zlib_decompress_block
to return failure.
[originally from svn r3306]
malloc functions, which automatically cast to the same type they're
allocating the size of. Should prevent any future errors involving
mallocing the size of the wrong structure type, and will also make
life easier if we ever need to turn the PuTTY core code from real C
into C++-friendly C. I haven't touched the Mac frontend in this
checkin because I couldn't compile or test it.
[originally from svn r3014]
absent, and also (I think) all the frontend request functions (such
as request_resize) take a context pointer, so that multiple windows
can be handled sensibly. I wouldn't swear to this, but I _think_
that only leaves the Unicode stuff as the last stubborn holdout.
[originally from svn r2147]
uncompressed block at the end of each compressed packet) which we
were embarrassingly unable to deal with because we assumed every
uncompressed block contained at least one byte. Particularly silly
because I _knew_ about the existence of sync flush when I coded this
module. Arrgh. Still, now fixed.
[originally from svn r1824]
compression. This involves introducing an option to disable Zlib
compression (that is, continue to work within the Zlib format but
output an uncompressed block) for the duration of a single packet.
[originally from svn r982]
smalloc() macros and thence to the safemalloc() functions in misc.c.
This should allow me to plug in a debugging allocator and track
memory leaks and segfaults and things.
[originally from svn r818]
Simon Tatham
Jacob Nevins
Ben Harris