On Thu, 22 January 2009 02:48:43 +0000, Phillip Lougher wrote: > > My guess > is either zlib_inflate is getting confused with corrupt data Which is easy enough. As one would expect of a decent compressor, there is little redundancy in the zlib stream that can be used for error checking. The 2-byte header has some, literal blocks have the length field twice and compressed blocks contain a couple of illegal symbols. The best way to protect oneself against accidental errors is checksums. And the zlib decision to checksum the _un_compressed data clearly doesn't help in this case, as the experienced problem occurs before the check. Also explains the "small .gz expands to gigabytes of data" attack, btw. Given a malicious attacker with enough time and resources, checksums obviously don't help. They will simply match the corrupt data. Jörn -- Joern's library part 3: http://inst.eecs.berkeley.edu/~cs152/fa05/handouts/clark-test.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
