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
Heap buffer overflow in chmd_read_headers() #27
Comments
|
Thank you for reporting this, and the POC file. The issue is that checking for specific system file names does not take name length into consideration. The memcmp() will read past the end of the freshly-allocated |
|
This issue apparently got assigned the CVE-2019-1010305 CVE id. |
|
Thanks for letting me know. I've added the CVE id to the existing entry on the list of libmspack security vulnerabilities |
|
I have run this POC but this was my output. |
|
That's the output that would be expected. The file is not a tight, tiny example PoC. It was discovered by fuzzing, so it is a regular CHM file that has been randomly mutated enough to find the bug. It has a lot of mutations that cause extract errors, and so you see the output you do, but nonetheless chmextract still makes it through the file. The problem is invisible; libmspack reads a few bytes beyond the end of freshly allocated memory. On most systems by default, this is not any kind of error at all. Only if we were very unlucky, and had a system that allocated memory at the end of readable/writable pages, and a few bytes after those pages were unmapped pages that cause a segfault if you try reading them, would we ever see any kind of problem. So the only way you're going to see this problem is to use ASan to force it to be visible. Here is how you could do that: ... and to prove it is fixed in the current version: |
|
Thank you for your explanation. |
|
There's not much to exploit. The description of CVE-2019-1010305 is "Information Disclosure". The disclosure is whether memory starting near the end of and ending just beyond the end of a heap-based buffer matches one of four fixed strings:
The attacker cannot arbitrarily choose the memory address nor can they learn what the memory contains, they can only determine if it matches one of four strings, which it most likely doesn't, and they need some way to see what's in the So it is definitely a correctness bug (libmspack should never read unallocated memory), but the security implications are minimal. Contrast it with Heartbleed, where an attacker can get a verbatim copy of up to 64kb of memory that follows where their message is stored in memory. I can think of a worst-possible-case, but you have to go from normal behaviour, where reading a few bytes beyond allocated memory is wrong does not cause any faults, to pathological behaviour: imagine you've set up a long-running CHM-listing network service, and you've also chosen to instrument all its code with ASan. An attacker can cause the program to crash by sending this PoC file to the service, getting it to read just beyond the end of a buffer and thus trigger your intentional program-crasher. |
Description:
Function chmd_read_headers() in libmspack has a heap buffer overflow problem( Out of Bound Read).
Affected version:
libmspack 0.9.1 alpha
Details:
In function
chmd_read_headers(), line 486,memcmp(&name[33], &content_name[33], 8L)will lead to out of bound read while extracting a crafted chm file.Details with asan output:
poc file
https://github.com/JsHuang/pocs/blob/master/libmspack/chmextract-overflow-chmd-486
Credit: ADLab of Venustech
The text was updated successfully, but these errors were encountered: