Please consider applying https://github.com/libarchive/libarchive/commit/6110e9c82d8ba830c3440f36b990483ceaaea52c which reverts a suspect change made by a now untrusted open source developer. There's no known attacks or direct threat from the commit being reverted but it may part of a long term effort to weaken open source security be enabling attacks elsewhere. Unless I'm mistaken, the suspect commit is present in all libarchive packages in the Gentoo tree right now. Reproducible: Always
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=43c399629fb022b7519d70194cb6c0364809764d commit 43c399629fb022b7519d70194cb6c0364809764d Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-03-31 15:20:09 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-03-31 15:20:09 +0000 app-arch/libarchive: Backport tar error handling fix Closes: https://bugs.gentoo.org/928146 Signed-off-by: Michał Górny <mgorny@gentoo.org> .../files/libarchive-3.7.2-safe-fprintf.patch | 27 ++++++++++++++++++++++ ...-3.7.2-r2.ebuild => libarchive-3.7.2-r3.ebuild} | 2 ++ 2 files changed, 29 insertions(+)
I don't think we can be certain about whether this change was indeed malicious but let's make this a security bug *just in case* as it's getting a lot of attention. We can always reassign later.
Just want to clarify that this change IS VERIFIED MALICIOUS. There are a couple test cases going around that show how using bsdtar to extract a tarball crafted by a bad actor can lead to arbitrary code execution. Unfortunately, further analysis shows there *may* be other ways to perform this attack besides the weakness added by the untrusted developer. See: https://github.com/libarchive/libarchive/issues/2107 Also: https://groups.google.com/g/libarchive-discuss/c/1b5DKylWivY
I share Solar's opinion on this: https://openwall.com/lists/oss-security/2024/03/31/11. >This does look minor indeed - not usable for large-scale attacks, and libarchive is quite unique in that it even bothered to filter control characters, whereas most command-line tools outputting filenames don't bother. The original PR, with lots of new discussion, was https://github.com/libarchive/libarchive/pull/1609. The initial fix for this was https://github.com/libarchive/libarchive/pull/2101 (https://github.com/libarchive/libarchive/commit/6110e9c82d8ba830c3440f36b990483ceaaea52c). https://github.com/libarchive/libarchive/issues/2103 coordinates the general review effort for libarchive in the wake of this. One of the libarchive maintainers has filed https://github.com/libarchive/libarchive/issues/2107 to discuss a better fix as well.
(reposting with fixed quoting) I share Solar's opinion on this: https://openwall.com/lists/oss-security/2024/03/31/11. >This does look minor indeed - not usable for large-scale attacks, and >libarchive is quite unique in that it even bothered to filter control >characters, whereas most command-line tools outputting filenames don't >bother. The original PR, with lots of new discussion, was https://github.com/libarchive/libarchive/pull/1609. The initial fix for this was https://github.com/libarchive/libarchive/pull/2101 (https://github.com/libarchive/libarchive/commit/6110e9c82d8ba830c3440f36b990483ceaaea52c). https://github.com/libarchive/libarchive/issues/2103 coordinates the general review effort for libarchive in the wake of this. One of the libarchive maintainers has filed https://github.com/libarchive/libarchive/issues/2107 to discuss a better fix as well.
