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
segmentation fault in lzo_decompress_buf, stream.c 589, incomplete fix of CVE-2017-8845 and CVE-2019-10654 #163
Comments
|
I'm sorry. What you did was convoluted. test.tar.zip is a zip of an lrz file. This is why the zip file had 0 compression benefit. You lrzip file, then zip it, then lrzip it again? To prove what? And in any event, I do not see your error. unzip test.tar.zip --> test.tar and to lrzip the testorig.tar file |
|
Oh, the reason why I zip these files is that GitHub does not allow uploading a tar file in the issue (but zip is ok). To reproduce this segmentation fault, you should unzip these two files first, especially the seg-stream589.zip. seg-stream589 is what you get from unzipping the seg-stream589.zip, which is the exploitable input. Specifically, the reproducing command is |
|
Well, intentionally stripping an lrzip file is certainly not recommended. Interestingly, using The routine to unpack a stream should test for a bad file like |
|
As a longtime contributor to this project, I have to say that since this is a manufactured event, I have it as a low priority. If you feel so inclined, you can examine the code of And, defending from intentional corruption of a file would mean many different types of checks all throughout the program.The magic header could be changed, stream headers could be changed, invalid stream pointers could be inserted, and if the lrzip file is encrypted, there are even more issues to check for. Good luck. |
|
Well, this malicious input is made by my new fuzzing tool for automatically detecting/verifying incomplete fix in the program. Since this segmentation fault is related to two CVEs that lasts for more than three years, which are caused by a series of incomplete fixes for the initial issue, I think it could cause some severe impacts if some adversaries already know the methods to exploit this bug. Still, I appreciate the developers' efforts in making the tools better. |
|
I read the CVE's and they are specific to As I said, this is not a dangerous error, no malicious code can be executed since it is a read only process. I'm disinclined to pursue this. |
|
FYI, This has nothing to do with LZO decompression. This error will occur with any mode, lzma, zpaq, gzip, bz2, etc. The bug is misplaced and tyhe CVEs incorrect, pointing to the wrong function. If you're really motivated, you can take a look here: stream.c This block checks for bad data in a number of ways. Because the header chain is broken, the last_head and s->last_head values are bad. But figuring out how to check on that is tough. Tough, because you don't want to exclude valid data in the checks. We've modified this in the past. Maybe it needs another look. |
|
Intentionally breaking a file can always lead to failures. Here, the fix was to check that the stream pointer did not point past the end of the current chunk. This may not catch everything, because some wacko could decide to push extraneous data anywhere in the file. Try the patch and see. This really needs to be tested thoroughly because there may be unintended consequences. I uncompressed small files and a 20GB compressed file. All seemed to work. Addresses #68 Here's some annotation. Also changed the |
|
Thanks for the update! Unfortunately, I applied this patch, and the problem still exists. This is the reproduced input (unzip first). |
|
You found another way to break the file. This is my point. No matter what I devise, you can still come up with a way to break this. Since stream offsets are zeroed on each chunk, even checking against compressed filesize is not foolproof. I don't have more time for this. Happy coding. |
|
Fixed in git master. |
|
This is assigned with CVE-2020-25467. |
Why are you commenting on this issue? It was closed. |
|
|
That doesn't answer my question as they're all referring to an older version and all those CVEs have been fixed. |
Beats me. Boredom? @5hadowblad3 |
The id is just assigned after I have submitted the application for almost a year. They told me to update the id in the related links for public reference and ensure it is well-fixed before the full details publicized in their database. This is also the reason why it cannot be found in this link yet. |
|
For cross-reference the fixing commit should be e74a11c |
- Document Viewer 2.8.2 uses MuPDF 1.11 from 2017-04-11 Has ~27 known security issues +4 patches: SufficientlySecure/document-viewer@0bfb13b https://github.com/SufficientlySecure/document-viewer/commits/c9bcd30849bb6648bbbe247229e9639c43cf61b8/document-viewer/jni/mupdf https://mupdf.com/releases/history.html https://www.cvedetails.com/vulnerability-list/vendor_id-10846/product_id-20840/Artifex-Mupdf.html - Book Reader 1.15.2 uses PDFium@dc397e0 from 2020-02-01 Has ~12 known security issues https://pdfium.googlesource.com/pdfium/+log/dc397e0 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=PDFium - LibreOffice Viewer 6.1.0 is from 2018-01-26 Has ~15 known security issues https://cgit.freedesktop.org/libreoffice/core/commit/?id=484d0ea842da https://www.cvedetails.com/vulnerability-list/vendor_id-11439/product_id-21008/Libreoffice-Libreoffice.html - PDF Converter 8.8.1 uses iText 5.5.10 Has ~5 known security issues https://github.com/Swati4star/Images-to-PDF/blob/e4440d73bae7ca018ffb41532275ea89d3fc2733/app/build.gradle#L101 https://github.com/itext/itextpdf/releases - Tinc 0.33 uses lzo-2.10 Has 1 security issue? https://github.com/pacien/tincapp/blob/234b97c14fa8df899291b760602b9bfc7abdad36/app/CMakeLists.txt ckolivas/lrzip#163 Signed-off-by: Tad <tad@spotco.us>
Hi, there.
There is invalid memory access in lzo_decompress_buf, stream.c 589 in the newest branch 597be1f.
According to the trace, it seems to be an incomplete fix of CVE-2017-8845 and CVE-2019-10654.
System:
To reproduce, run:
POC:
seg-stream589.zip
which is made from this original tar file compressed by lrzip
test.tar.zip
This is the output from the terminal:
This is the trace reported by ASAN:
The text was updated successfully, but these errors were encountered: