A number of flaws have been corrected in upstream libarchive that have not yet been included in a public release of libarchive (latest version is 2.8.4). A buffer overflow at reading bit lengths of huffman code of LZX when reading a broken CAB file (CVE-2010-4666) [1]. Buffer overflows in various functions related to reading archives (in archive_read_support_format_iso9660.c) (CVE-2011-1777) [2]. Buffer overflow in reading tar archives (CVE-2011-1778) [3]. Use-after-free bugs (CVE-2011-1779) [4]. [1] http://code.google.com/p/libarchive/source/detail?r=2842 [2] http://code.google.com/p/libarchive/source/detail?r=3158 [3] http://code.google.com/p/libarchive/source/detail?r=3160 [4] http://code.google.com/p/libarchive/source/detail?r=3038
Created libarchive tracking bugs for this issue Affects: fedora-all [bug 705850]
What about libarchive-2.8.3-2.el6, included in RHEL 6.0 gold?
Yes, libarchive in RHEL6 would be affected by this. We have not yet fully triaged the issue to know how it affects what uses it in RHEL6, which will be the determining factor on when this gets addressed.
(In reply to comment #0) > A buffer overflow at reading bit lengths of huffman code of LZX when reading a > broken CAB file (CVE-2010-4666) [1]. Doesn't apply for libarchive-2.8.4, no CAB support yet > Buffer overflows in various functions related to reading archives (in > archive_read_support_format_iso9660.c) (CVE-2011-1777) [2]. > > Buffer overflow in reading tar archives (CVE-2011-1778) [3]. > > Use-after-free bugs (CVE-2011-1779) [4]. These three patches are way too far from the 2.8.4 release and don't apply; the internal structure of the particular source files have changed a lot and even if we somehow make the patches apply, I don't trust the resulting functionality. We probably can't even rebase to latest snapshot as long as the API has changed in preparation to the 3.x series. I suggest to close this bugreport or make someone to look deep in the sources and come up with working patches.
(In reply to comment #4) > (In reply to comment #0) > > A buffer overflow at reading bit lengths of huffman code of LZX when reading a > > broken CAB file (CVE-2010-4666) [1]. > Doesn't apply for libarchive-2.8.4, no CAB support yet Ok, this works in our favour. > > Buffer overflows in various functions related to reading archives (in > > archive_read_support_format_iso9660.c) (CVE-2011-1777) [2]. > > > > Buffer overflow in reading tar archives (CVE-2011-1778) [3]. > > > > Use-after-free bugs (CVE-2011-1779) [4]. > > These three patches are way too far from the 2.8.4 release and don't apply; the > internal structure of the particular source files have changed a lot and even > if we somehow make the patches apply, I don't trust the resulting > functionality. > > We probably can't even rebase to latest snapshot as long as the API has changed > in preparation to the 3.x series. > > I suggest to close this bugreport or make someone to look deep in the sources > and come up with working patches. I don't see closing this as an option. You are effectively saying that, because it's difficult, we won't do it. Maybe the impact is low enough that it won't matter if we don't fix it, but we need to look into it. At a quick glance, there are a few important packages that link to libarchive: PackageKit, kdeutils, gvfs-archive, and anaconda (the last probably isn't very significant in this context). If none of these packages use the vulnerable functionality, then I have no problem with closing this (once it is corrected in Fedora). If they do, however, then we will need to come up with our own fix and backport what is applicable to close the hole.
Okay, let's keep this open. I'm flooded with work, perhaps somebody else could come up with the patches.
Fair enough. This isn't a high-impact flaw, so we don't need to worry about this right away, but we will probably want to take care of it at some point. Thanks.
(In reply to comment #0) > A number of flaws have been corrected in upstream libarchive that have not yet > been included in a public release of libarchive (latest version is 2.8.4). > > A buffer overflow at reading bit lengths of huffman code of LZX when reading a > broken CAB file (CVE-2010-4666) [1]. > > Buffer overflows in various functions related to reading archives (in > archive_read_support_format_iso9660.c) (CVE-2011-1777) [2]. > > Buffer overflow in reading tar archives (CVE-2011-1778) [3]. > > Use-after-free bugs (CVE-2011-1779) [4]. > > [1] http://code.google.com/p/libarchive/source/detail?r=2842 Ark, PackageKit, and GVFS archive mounter currently don't support cab format. > [2] > http://code.google.com/p/libarchive/source/detail?r=3158&path=/trunk/libarchive/archive_read_support_format_iso9660.c Ark, and PackageKit don't support ISO9660 format. However, GVFS archive mounter do support ISO9660 format. > [3] http://code.google.com/p/libarchive/source/detail?r=3160 Both Ark and PackageKit use libarchive for tar format. > [4] http://code.google.com/p/libarchive/source/detail?r=3038 GVFS archive mounter supports tar format. The GVFS archive mounter can be used to enter and examine iso9660 and tar archives via the file manager by simply right-clicking and choosing ‘Open with Archive mounter.’. Thus, increasing the severity of this.
Created attachment 523601 [details] CVE-2011-1777.patch
Created attachment 523602 [details] CVE-2011-1778.patch
Attached are patches for CVE-2011-1777 and CVE-2011-1778, libarchive 2.8.3 is not affected by CVE-2010-4666 and CVE-2011-1779.
Statement CVE-2010-4666, CVE-2011-1779: Not vulnerable. This issue did not affect the versions of libarchive as shipped with Red Hat Enterprise Linux 4, 5, and 6.
Created attachment 526022 [details] CVE-2011-1778.patch (In reply to comment #11) > Attached are patches for CVE-2011-1777 and CVE-2011-1778, libarchive 2.8.3 is > not affected by CVE-2010-4666 and CVE-2011-1779. Thanks, however F16/rawhide has libarchive 2.8.5 where the patches don't apply and RHEL 6 has libarchive 2.8.3 where the patches don't compile. Also, the CVE-2011-1778.patch is missing corrected function prototypes and some calls are missing the required arguments. I was wondering how did you manage to compile it? Attaching new patch, untested.
Both patches wfm with checked out sources for RHEL 6 from our CVS repository after running "make prep". For the CVE-2011-1778.patch, what are the function calls and function prototypes that were missing and why they also should be patched?
After checking again, I realized that I attached a bad generated patch instead of the correct patch for CVE-2011-1778. Thanks for fixing it.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:1507 https://rhn.redhat.com/errata/RHSA-2011-1507.html
Has this been corrected in Fedora yet?
(In reply to comment #18) > Has this been corrected in Fedora yet? In Rawhide, yes, in released Fedoras, no, patches don't apply cleanly.
(In reply to comment #19) > (In reply to comment #18) > > Has this been corrected in Fedora yet? > > In Rawhide, yes, in released Fedoras, no, patches don't apply cleanly. Do you intend to correct it in Fedora 15 and 16? I'm not sure if it's plausible to rebase in those versions or not, but it would be fantastic if we could get it resolved. Thanks.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > Has this been corrected in Fedora yet? > > > > In Rawhide, yes, in released Fedoras, no, patches don't apply cleanly. > > Do you intend to correct it in Fedora 15 and 16? I'm not sure if it's > plausible to rebase in those versions or not, but it would be fantastic if we > could get it resolved. Thanks. Not anytime in the short term unfortunately, my TODO list is quite long these days with higher-priority things. Last time I checked the patched didn't apply cleanly on 2.8.5 release which would involve further work. I'd be happy to package new patches however.
The RHEL6 update was to patch 2.8.3.. would not the same patch apply to 2.8.4/2.8.5? (I don't know, I've not looked). I don't know what changed between 2.8.5 and 3.0.0, so perhaps rebasing may be out of the question of it introduces some ABI changes. But if we're able to patch 2.8.3, surely that patch should apply to the other releases with minimal fuss? Having said that, this isn't a high impact security flaw, so some delay is not a problem.
The CVE-2011-1777.patch attached to this report (attachment #523601 [details]) is broken and breaks ISO support (found out by Mageia QA, https://bugs.mageia.org/show_bug.cgi?id=3941 ). The upstream commit added braces to several 'if' statements, but in two places those are missing from this patch, causing the execution to enter the parent 'else' code blocks which are now wrongly associated with the added 'if' statements. Additionally, the patch adds a return value to the heap_add_entry() function. However, there is an additional return statement in the function which should also now be changed to return ARCHIVE_OK, but this was missed. For the record, here are the changes I made to the patch: http://svnweb.mageia.org/packages/updates/1/libarchive/current/SOURCES/libarchive-CVE-2011-1777.diff?r1=188950&r2=189404
EPEL5 contains libarchive-2.8.4-3.el5, this package does not contain any patches against the CVE's, can someone confirm it is vulnerable? If it needs fixing, please clone the bug and assign it to me.
Thanks, Anssi! I think we should use the patch Mageia is using for our Fedora/EPEL updates: http://svnweb.mageia.org/packages/updates/1/libarchive/current/SOURCES/libarchive-CVE-2011-1777.diff?revision=189404&view=co Neils, I will file a tracker for you. 2.8.4 should be affected as well.
Created libarchive tracking bugs for this issue Affects: epel-5 [bug 773505]
This regression affects the latest version of libarchive package released via RHSA-2011:1507. I've cloned this to Bug 782008.
libarchive-2.8.4-5.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.