trietptm / lz4

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

High Address allocation in 32-bits mode #134

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Some specific 32-bits architecture are susceptible to allocate memory block 
beyond the 0x80000000h memory address.

If confirmed, since it was a key assumption in the overflow check methodology 
up to now, it will require to implement some new border checks.

PS : the discoverer selected to disclose the potential vulnerability directly 
to the public at large 
(http://blog.securitymouse.com/2014/07/i-was-wrong-proving-lz4-exploitable.html)
 without bothering to get in touch with upstream library developer.
As a consequence, the issue ticket is opened directly by upstream developer.

Original issue reported on code.google.com by yann.col...@gmail.com on 2 Jul 2014 at 12:03

GoogleCodeExporter commented 9 years ago
A quickfix is proposed on the "Dev" branch on github :
https://github.com/Cyan4973/lz4/tree/dev

Note : current test tool are unable to reproduce the target condition for 
vulnerability. So this quickfix is not considered tested, even though it passes 
the fuzzer and automated travis test suite.

You are welcomed to provide your own results on your test system, notably if it 
can produce the specific conditions required to trigger this issue :
- 32 bits OS
- allocated memory segment above address 0x80000000h

Original comment by yann.col...@gmail.com on 2 Jul 2014 at 3:41

GoogleCodeExporter commented 9 years ago
Fuzzer tool is updated to fabricate address space overflow conditions and test 
them :
https://github.com/Cyan4973/lz4/tree/dev

Original comment by yann.col...@gmail.com on 2 Jul 2014 at 5:37

GoogleCodeExporter commented 9 years ago
Fixed into r119

Original comment by yann.col...@gmail.com on 2 Jul 2014 at 9:39