New LZ4 vulnerability - to be checked

[Cyan]

donb is at it again,
but this time with a vulnerability which could very well prove exploitable.

Here is the article :
http://blog.securitymouse.com/2014/0...ploitable.html

The trick to this vulnerability is to get the 32-bits OS allocate a memory block beyond address 0x80000000.

This situation never happened in my tests (even though I've got 4 GB of mem to play with).
As a result, it became a key assumption in the border checking algorithm.

It could be that this possibility is limited to some platforms.
The article states specifically that it is possible on some type of ARM processors, but I'm not totally convinced it is related to hardware.
It may related to OS instead.
Anyway, if it's not possible to trigger on PC, then it may be more difficult to debug it. On Smartphone Platforms typically, dedicated tools (SDK, cable set, etc.) may be required.

Anyway, since it's not exactly my world, I'm looking for some help in order to find some platform able to trigger that situation.
- 32-bits system & OS
- memory allocated beyond address 0x80000000

The main driver is, it's much better to complete a fix when it's also possible to test it....

A first fix is available, for testing, on the issue tracker :
https://code.google.com/p/lz4/issues/detail?id=134


Regards

[nburns]

Something like this should work in Linux:

#include <stdlib.h>

#include <stdio.h>

#include <malloc.h>



int main()

{

	// tell glibc not to malloc using mmap; this makes the outcome more predictable

	int rc = mallopt(M_MMAP_MAX, 0);



	void *p0 = malloc(2UL * 1024 * 1024 * 1024);

	void *p1 = malloc(1024);



	printf("rc = %d (%s); p0 = %p; p1 = %p\n", rc, rc?"success":"failure", p0, p1);



	return 0;

}

I don't have a 32-bit OS handy to test with, but this is what came out in a 64-bit Ubuntu VM with a 32-bit binary:

~/src$ gcc -m32 -o highalloc highalloc.c 
~/src$ ./highalloc 
rc = 1 (success); p0 = 0x77534008; p1 = 0xf7534010
~/src$

[Cyan]

Yep, indeed,
in latest r119 release,
the fuzzer test tool is now able to actively look for and trigger this condition, to test the new fix on it.

In contrast with what said the initial article, the problem is not hardware related, it is OS related.

Anyway, if you are deploying 32-bits systems, updating to r119 is recommended.