Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Negative size passed to memcpy resulting in memory corruption (lib/lizard_decompress_liz.h:207) #16

Closed
glen-mac opened this issue May 3, 2018 · 2 comments

Comments

@glen-mac
Copy link

glen-mac commented May 3, 2018

Hey there,

I have come across a vulnerability in the lizard decompressor, whereby a negative size integer is passed to memcpy(). This occurs in lib/lizard_decompress_liz.h:207.

memcpy(op, ctx->literalsPtr, length);

Since memcpy() takes the length and treats it as a size_t, this results in an excessive copy from ctx->literalsPtr into op.

void *memcpy(void *dest, const void *src, size_t n);

This was found while fuzzing commit 6a1ed71 (current latest as of this date).

By controlling the number of bytes passed as length, this results in memory corruption which can lead to execution control.

Find the POC file here: poc.zip.

As follows is the ASAN output:

$ ./lizard_afl -d crash.file /dev/null
=================================================================
==26522==ERROR: AddressSanitizer: negative-size-param: (size=-8)
    #0 0x4ae273 in __asan_memcpy (/root/lizard/lizard_afl+0x4ae273)
    #1 0x51a9b2 in Lizard_decompress_LIZv1 /root/lizard/programs/../lib/lizard_decompress_liz.h:207:5
    #2 0x51a9b2 in Lizard_decompress_generic /root/lizard/programs/../lib/lizard_decompress.c:241
    #3 0x51a9b2 in Lizard_decompress_safe_usingDict /root/lizard/programs/../lib/lizard_decompress.c:362
    #4 0x634386 in LizardF_decompress /root/lizard/programs/../lib/lizard_frame.c:1197:31
    #5 0x645fc1 in LizardIO_decompressLizardF /root/lizard/programs/lizardio.c:676:26
    #6 0x645fc1 in selectDecoder /root/lizard/programs/lizardio.c:767
    #7 0x645fc1 in LizardIO_decompressSrcFile /root/lizard/programs/lizardio.c:803
    #8 0x644379 in LizardIO_decompressDstFile /root/lizard/programs/lizardio.c:831:5
    #9 0x643b80 in LizardIO_decompressFilename /root/lizard/programs/lizardio.c:850:30
    #10 0x64caf8 in main /root/lizard/programs/lizardcli.c:560:32
    #11 0x7f4d32b69f44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287
    #12 0x419cb5 in _start (/root/lizard/lizard_afl+0x419cb5)

0x7f4d33c1e86e is located 110 bytes inside of 131072-byte region [0x7f4d33c1e800,0x7f4d33c3e800)
allocated by thread T0 here:
    #0 0x4c418c in calloc (/root/lizard/lizard_afl+0x4c418c)
    #1 0x636a0b in LizardF_decodeHeader /root/lizard/programs/../lib/lizard_frame.c:840:33

SUMMARY: AddressSanitizer: negative-size-param (/root/lizard/lizard_afl+0x4ae273) in __asan_memcpy
==26522==ABORTING

In the example above, with a memcpy size of -8, this value is interpreted as an unsigned integer and the memcpy continues until there is a page fault due to unmapped memory and the process terminates:

root at s127422 in ~/lizard (lizard●●)
$ ./lizard -d crash.file /dev/null
[1]    17128 segmentation fault  ./lizard -d crash.file /dev/null

To demonstrate that the memcpy size value can be controlled by an attacker, I have attached a series of crashes that result from a differing memcpy size value.
lizard_crashes.zip

@inikep
Copy link
Owner

inikep commented Jun 23, 2018

Thanks for reporting.
It is fixed with 02491c7

@Grossdm
Copy link

Grossdm commented Sep 14, 2018

@inikep, if this is indeed fixed and @glen-mac has no other concerns, perhaps you can close this issue now?

Just trying to help keep your repo tidy.
😆

Thanks,
Doug®

@inikep inikep closed this as completed Oct 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants