GitHub PushEvent at 2014-10-02 03:04:20
Repository: putty
Actor: svn2github
Payload: {"shas":[["5d8b8424c107192d7729236b5b2cff537a9da4db","088e16a1019277b15d58faf0541e11910eb756f6@cda61777-01e9-0310-a592-d414129be87e","Add a missing bounds check in the Deflate decompressor.\n\nThe symbol alphabet used for encoding ranges of backward distances in\na Deflate compressed block contains 32 symbol values, but two of them\n(symbols 30 and 31) have no meaning, and hence it is an encoding error\nfor them to appear in a compressed block. If a compressed file did so\nanyway, this decompressor would index past the end of the distcodes[]\narray. Oops.\n\nThis is clearly a bug, but I don't believe it's a vulnerability. The\nnonsense record we load from distcodes[] in this situation contains an\nindeterminate bogus value for 'extrabits' (how many more bits to read\nfrom the input stream to complete the backward distance) and also for\nthe offset to add to the backward distance after that. But neither of\nthese can lead to a buffer overflow: if extrabits is so big that\ndctx->nbits (which is capped at 32) never exceeds it, then the\ndecompressor will simply swallow all further data without producing\nany output, and otherwise the decompressor will consume _some_ number\nof spare bits from the input, work out a backward distance and an\noffset in the sliding window which will be utter nonsense and probably\nout of bounds, but fortunately will then AND the offset with 0x7FFF at\nthe last minute, which makes it safe again. So I think the worst that\na malicious compressor can do is to cause the decompressor to generate\nstrange data, which of course it could do anyway if it wanted to by\nsending that same data legally compressed.\n\n\ngit-svn-id: svn://svn.tartarus.org/sgt/putty@10278 cda61777-01e9-0310-a592-d414129be87e","simon",true],["3cbb37edaf9d889fe3cd6d4bce6191dbfc83c274","088e16a1019277b15d58faf0541e11910eb756f6@cda61777-01e9-0310-a592-d414129be87e","Turn mkunxarc.sh back into an ordinary sh script.\n\nIt became bash-dependent in r9229 because I used a bashism to remove\nthe 'r' from the front of $SVN_REV, but that's not needed any more.\n\n\ngit-svn-id: svn://svn.tartarus.org/sgt/putty@10281 cda61777-01e9-0310-a592-d414129be87e","simon",true]],"size":2,"ref":"refs/heads/master","head":"3cbb37edaf9d889fe3cd6d4bce6191dbfc83c274"}