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.

Sign up for GitHub

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

Jump to bottom

The libarchive lib exist a READ memory access Vulnerability #1672

Closed
icycityone opened this issue Feb 25, 2022 · 47 comments
Closed

The libarchive lib exist a READ memory access Vulnerability #1672

icycityone opened this issue Feb 25, 2022 · 47 comments

Comments

@icycityone
Copy link

icycityone commented Feb 25, 2022 •
edited

hello,when i use libfuzzer to write code to call archive_read_data function,i find a READ memory access Vulnerability.see the picture! The lzma_decode function crashed when decode my testcase.
图片
@kientzle
Copy link
Contributor

Can you share the test case? That would help us to identify and fix this issue. It would also help if you could provide other details: What system were you using? What version of libarchive? What version of liblzma?

@icycityone
Copy link
Author

icycityone commented Feb 26, 2022 via email

@icycityone
Copy link
Author

icycityone commented Feb 26, 2022 via email

@mmatuska
Copy link
Member

@icycityone what we need is a sample test file to reproduce the vulnerability

@icycityone
Copy link
Author

icycityone commented Feb 26, 2022 via email

@mmatuska
Copy link
Member

I am sorry, but I don't see any attachments to this issue. If you want you can mail the testcase to me directly at martin@matuska.org

@icycityone
Copy link
Author

I am sorry, but I don't see any attachments to this issue. If you want you can mail the testcase to me directly at martin@matuska.org

you can see the next mail .

@icycityone
Copy link
Author

hello,do you received the message

@mmatuska
Copy link
Member

mmatuska commented Mar 5, 2022

No, I didn't get an e-mail with the sample nor it is attached to this issue.

@icycityone
Copy link
Author

icycityone commented Mar 5, 2022 via email

@mmatuska
Copy link
Member

mmatuska commented Mar 6, 2022

Hi, I got your testcase. I am unable to reproduce the error with contrib/archivetest.
Try to compile contrib/archivetest.c with CFLAGS="-g -fsanitize=address" and test the file.

@icycityone
Copy link
Author

icycityone commented Mar 6, 2022 via email

@mmatuska
Copy link
Member

mmatuska commented Mar 6, 2022

Just to note, the archivetest output from reading your sample looks like this:

$ ./archivetest -f crash-58af2238755ec09600f15fed6e3e606c09638f42 
Data source: filename: crash-58af2238755ec09600f15fed6e3e606c09638f42
Filter: none
Format: ZIP 0.7 (lzma)
Entry 1: ARCHIVE_OK, pathname unreadable, data: OK
Entry 2: ARCHIVE_OK, pathname unreadable, data: OK
Entry 3: ARCHIVE_OK, pathname unreadable, data: OK
Entry 4: ARCHIVE_OK, pathname unreadable, data: OK
Entry 5: fatal error reading header
Last return code: ARCHIVE_FATAL (-30)
Error string: Truncated ZIP file data

I got no errors from ASAN.

@icycityone
Copy link
Author

icycityone commented Mar 6, 2022 via email

@icycityone
Copy link
Author

icycityone commented Mar 7, 2022 via email

@icycityone
Copy link
Author

icycityone commented Mar 9, 2022 via email

@mmatuska
Copy link
Member

mmatuska commented Mar 9, 2022

Yes, I have managed to reproduce the error. I have used contrib/oss-fuzz/libarchive_fuzzer.cc
I currently don't have time to investigate on this issue.

@icycityone
Copy link
Author

icycityone commented Mar 9, 2022 via email

@icycityone
Copy link
Author

icycityone commented Mar 10, 2022 via email

@mmatuska
Copy link
Member

mmatuska commented Mar 10, 2022 via email

@icycityone
Copy link
Author

icycityone commented Mar 10, 2022 via email

@icycityone
Copy link
Author

icycityone commented Mar 11, 2022 via email

@icycityone
Copy link
Author

icycityone commented Mar 14, 2022 via email

@JiaT75
Copy link
Contributor

JiaT75 commented Mar 18, 2022

@mmatuska @icycityone can either of you provide the crashfile in this thread or to my email jiat0218@gmail.com? I have been working with liblzma quite a bit recently and I can help determine if this is a libarchive or liblzma problem

@icycityone
Copy link
Author

icycityone commented Mar 22, 2022 via email

@JiaT75 JiaT75 mentioned this issue Mar 22, 2022
Closed
@kientzle
Copy link
Contributor

The analysis above points to a bug in zipx_lzma_alone_init. In line 1678, we read 9 bytes from the entry

        if((p = __archive_read_ahead(a, 9, NULL)) == NULL) {

At line 1720, after successfully parsing the 9-byte header and initializing the decompressor, we subtract 9 bytes from the entry size:

        __archive_read_consume(a, 9);
        zip->entry_bytes_remaining -= 9;

I believe this is where the -9 is coming from in the trace above. I believe the bug is that in line 1678 above, we read 9 bytes even if there weren't 9 bytes in the entry.

So I believe the correct answer is to change the test in line 1678 to ensure that there are in fact 9 bytes available in the entry before we try to read those 9 bytes:

        /* Read magic1,magic2,lzma_params from the ZIPX stream. */
        if(archive->entry_bytes_remaining < 9 || (p = __archive_read_ahead(a, 9, NULL)) == NULL) {
                archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT,
                    "Truncated lzma data");
                return (ARCHIVE_FATAL);
        }

@icycityone
Copy link
Author

so the bug is certainly caused by libarchive not by liblzma. Can i apply for cve on this subject @kientzle

mmatuska pushed a commit to mmatuska/libarchive that referenced this issue Mar 24, 2022
@kientzle @mmatuska
ZIP reader: fix out-of-bounds read in zipx_lzma_alone_init()
855f83c 
Fixes libarchive#1672
@kientzle
Copy link
Contributor

@icycityone Yes, please go ahead and apply for a CVE.

Has anyone verified that my suggested change above fixes this issue?

@icycityone
Copy link
Author

hello,thanks for your reply.Is it possible to pass this commit by https://cveform.mitre.org/ or submit by other means. And how long will it take to get the reply. Look forward to your reply. @kientzle

@mmatuska
Copy link
Member

I have submitted the patch. Btw. is a out-of-bounds read that does nothing actually eligible for a CVE? The application will read some bytes beyond the boundary but it will always die and stop processing.

@icycityone
Copy link
Author

icycityone commented Mar 25, 2022 via email

@mmatuska
Copy link
Member

Linking with OSS-Fuzz issue 38766 that got resolved by the fix:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38766#c4

@risicle
Copy link

risicle commented Apr 2, 2022

@mmatuska the process will only be killed if the read is off the edge of a page boundary and the next page is not readable. That still leaves up to 4095 bytes that could be read unimpeded, even if the next page is unreadable. OOB reads can still be very serious if, for example, the process also has credentials in its address space.

@mmatuska
Copy link
Member

mmatuska commented Apr 3, 2022

@risicle the data read here is treated in libarchive as "external data", so libarchive will erroneously consider the data to be from the archive and interpret the rest of the 9-byte header. All subsequent reads (based or not based on the header data received) will fail on the empty entry_bytes_remaining.

@mcandre
Copy link

mcandre commented Apr 7, 2022

When can we tag and release a new, patched version?

Will fixes be backported to earlier libarchive release series, too?

jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/poky that referenced this issue Apr 8, 2022
@Hiten1412 @jpuhlman
CVE-2022-26280 libarchive: out of bounds in zipx_lzma_alone_init
48f1f5c 
Source: libarchive/libarchive#1672
MR: 117047
Type: Security Fix
Disposition: Backport from libarchive/libarchive@cfaa281
ChangeID: 4cbeb941b705104ced195a01f6bf93871f0db4e7
Description:
	         CVE-2022-26280
	         libarchive: out of bounds in zipx_lzma_alone_init.

Signed-off-by: Hitendra Prajapati <hprajapati@mvista.com>
Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
@CamberLoid CamberLoid mentioned this issue Apr 14, 2022
Merged
10 tasks
praharsh23 pushed a commit to praharsh23/libarchive that referenced this issue May 3, 2022
Verify fix for libarchive#1672
0f4b585
@carnil
Copy link

carnil commented May 6, 2022

CVE-2022-28066 appers to have been assigned to this issue.

@Cristian-Bejan
Copy link

Any reason as to why 2 CVE (CVE-2022-26280 CVE-2022-28066) have been assigned to this issue?

@carnil
Copy link

carnil commented May 9, 2022 via email

@icycityone
Copy link
Author

icycityone commented May 9, 2022 via email

@icycityone
Copy link
Author

icycityone commented May 9, 2022 via email

@Cristian-Bejan
Copy link

@carnil Thank you! My understanding is that these are both OOB with a DoS impact and 37d6aff fixes them. Is the root cause the thing that makes them apart?

@Cristian-Bejan
Copy link

@icycityone That might be the case. You submitted different descriptions so I'm assuming they thought it's a different vulnerability.

@icycityone
Copy link
Author

i have not noticed this since i received the reply from MITRE.I recived the cve numbers is 28260.

@icycityone
Copy link
Author

@icycityone That might be the case. You submitted different descriptions so I'm assuming they thought it's a different vulnerability.

maybe,because this is my first time to submit,so to ensure they recevied,i have sumbmited twice

@srccn
Copy link

srccn commented May 11, 2022

@icycityone: regarding to CVE reporting,

  1. could you please give detailed affected previous release versions in report? something like from version 3.4.0 to 3.6.0? that will help NVD to populate CPE list. It will be even better if providing enumerated all affected released versions.
  2. Definitely suggest to keep one CVE open, suggest to close CVE-2022-28066 and keep CVE-2022-26280, because CVE-2022-26280 already have CVSS score assigned.

@icycityone
Copy link
Author

icycityone commented May 12, 2022 via email

@carnil
Copy link

carnil commented May 12, 2022 via email

@mfrw mfrw mentioned this issue Jun 13, 2022
Merged
12 tasks
rpurdie pushed a commit to yoctoproject/poky that referenced this issue Mar 25, 2023
@rpurdie
libarchive: fix CVE-2022-26280
51a742e 
Backport fix from libarchive/libarchive#1672

(From OE-Core rev: b23482f9ea1cc930a3d5ecfe5fc465e2f720a949)

Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kraj pushed a commit to YoeDistro/openembedded-core that referenced this issue Mar 26, 2023
@sakoman
libarchive: fix CVE-2022-26280
b23482f 
Backport fix from libarchive/libarchive#1672

Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/poky that referenced this issue Mar 27, 2023
@jpuhlman
libarchive: fix CVE-2022-26280
4039495 
Source: poky
MR: 125004, 117047
Type: Security Fix
Disposition: Merged from poky
ChangeID: 51a742eab1a8b2f84aee82b8ad77cd5a237c6283
Description:

Backport fix from libarchive/libarchive#1672

(From OE-Core rev: b23482f9ea1cc930a3d5ecfe5fc465e2f720a949)

Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Moved negative check for input byte count to after min calculation JiaT75/libarchive
9 participants
@mcandre @carnil @risicle @mmatuska @kientzle @srccn @icycityone @Cristian-Bejan @JiaT75