xiaoyin0208 / lz4

Automatically exported from code.google.com/p/lz4
0 stars 0 forks source link

Header documentation problem #41

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The comments for LZ4_uncompress() in lz4.h state:

"This function never writes beyond dest + osize, and is therefore protected 
against malicious data packets"

I don't see how can this be true, if it doesn't even take isize as a parameter. 
Surely a malicious attacker could truncate the input data, causing reads beyond 
the end of the input buffer for any given expected osize, not to mention more 
sophisticated attacks "fishing" data past the end of the input buffer.

Is there something I'm missing?

I know there's LZ4_uncompress_unknownOutputSize for safe decoding, but if I'm 
right I think this should be clarified.

Original issue reported on code.google.com by palsto...@gmail.com on 31 Oct 2012 at 2:12

GoogleCodeExporter commented 8 years ago
Well, i guess your statement is correct.

For a more complete picture, here is what kind of protection the function 
provides :
The function indeed never writes outside of output buffer.
It also never writes into, nor outside of input buffer.
it never "reads" outside of output buffer,
and never "reads" before input buffer.

So i guess it remains the risk that it can be instructed to "read" after input 
buffer, especially if the data is hand-crafted for this objective. Not sure if 
it is enough to execute a malicious code (i guess not), but this could 
nonetheless be considered an attack.

Maybe LZ4_uncompress_unknownOutputSize() could be renamed into 
LZ4_uncompress_safe(), or something like that....

Original comment by yann.col...@gmail.com on 31 Oct 2012 at 4:27

GoogleCodeExporter commented 8 years ago
I'll look into it.

Original comment by yann.col...@gmail.com on 31 Oct 2012 at 4:28

GoogleCodeExporter commented 8 years ago
Corrected into r82.

Original comment by yann.col...@gmail.com on 3 Nov 2012 at 9:06