Results 1 to 3 of 3

Thread: New LZ4 vulnerability - to be checked

  1. #1
    Member
    Join Date
    Sep 2008
    Location
    France
    Posts
    889
    Thanks
    483
    Thanked 279 Times in 119 Posts

    New LZ4 vulnerability - to be checked

    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
    Last edited by Cyan; 2nd July 2014 at 06:45.

  2. #2
    Member
    Join Date
    Feb 2013
    Location
    San Diego
    Posts
    1,057
    Thanks
    54
    Thanked 72 Times in 56 Posts
    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:

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

  3. #3
    Member
    Join Date
    Sep 2008
    Location
    France
    Posts
    889
    Thanks
    483
    Thanked 279 Times in 119 Posts
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •