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

Vulnerable code, CVE-2016-1541 #656

Closed
rstevens70 opened this issue Feb 8, 2016 · 5 comments
Closed

Vulnerable code, CVE-2016-1541 #656

rstevens70 opened this issue Feb 8, 2016 · 5 comments
Assignees
Milestone

Comments

@rstevens70
Copy link

Looking to responsibly disclose a vulnerability in libarchive that could permit arbitrary code execution. We have samples to support our discovery.

@rstevens70
Copy link
Author

Notified lead dev. Patch within a month.

@xorgy
Copy link

xorgy commented Feb 28, 2016

@rstevens70 Does this look like it'll be resolved?

@kientzle kientzle added this to the 3.2 milestone Feb 28, 2016
@kientzle kientzle self-assigned this Apr 11, 2016
@kientzle
Copy link
Contributor

A patch for this issue has been shared with the original reporter.

@kientzle
Copy link
Contributor

The same issue has also been reported as TALOS-CAN-155

kientzle added a commit that referenced this issue May 1, 2016
When reading OS X metadata entries in Zip archives that were stored
without compression, libarchive would use the uncompressed entry size
to allocate a buffer but would use the compressed entry size to limit
the amount of data copied into that buffer.  Since the compressed
and uncompressed sizes are provided by data in the archive itself,
an attacker could manipulate these values to write data beyond
the end of the allocated buffer.

This fix provides three new checks to guard against such
manipulation and to make libarchive generally more robust when
handling this type of entry:
 1. If an OS X metadata entry is stored without compression,
    abort the entire archive if the compressed and uncompressed
    data sizes do not match.
 2. When sanity-checking the size of an OS X metadata entry,
    abort this entry if either the compressed or uncompressed
    size is larger than 4MB.
 3. When copying data into the allocated buffer, check the copy
    size against both the compressed entry size and uncompressed
    entry size.
@kientzle
Copy link
Contributor

Fixed in libarchive 3.2

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