From ${URL} : == Overview == LHA for UNIX (https://osdn.jp/projects/lha/) is an open source implementation of the LHA compression utility and associated file format. == Version == All tests were performed using the latest 20b6ba8 commit of the master branch from https://osdn.jp/projects/lha/scm/git/lha/ == Details == Using the afl fuzzer, two cases which triggered a buffer overflow where discovered. The problem existed in header.c:797-800 and header.c:913-916 while parsing level0 and level1 headers accordingly. =797-800= hdr->header_size = header_size = get_byte(); checksum = get_byte(); if (fread(data + COMMON_HEADER_SIZE, header_size + 2 - COMMON_HEADER_SIZE, 1, fp) == 0) { error("Invalid header (LHarc file ?)"); return FALSE; /* finish */ } =913-916= hdr->header_size = header_size = get_byte(); checksum = get_byte(); if (fread(data + COMMON_HEADER_SIZE, header_size + 2 - COMMON_HEADER_SIZE, 1, fp) == 0) { error("Invalid header (LHarc file ?)"); return FALSE; /* finish */ } The header_size variable is determined from the first byte of the lha archive header, which is read by the get_byte function. The returned value is used in: header_size + 2 - COMMON_HEADER_SIZE to determine the elements' size used in fread() . If the header_size is less than abs(2 - COMMON_HEADER_SIZE) = abs(2 - 21) = 19 then the size parameter is overflowed and a buffer overflow occurs in fread. == Timeline == 2016-01-13 - Bug report submitted 2016-01-16 - Bug fix pushed to master (commit bf2471f) @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
@ Maintainer(s): Please consider doing a snapshot release or at least cherry-pick https://de.osdn.net/projects/lha/scm/git/lha/commits/bf2471f to address this vulnerability.
Created attachment 459882 [details, diff] lha-114i-fix-CVE-2016-1925.patch This is the patch from upstream that fixes the bug.
Scratch that, it fails. I'll work some more on it.
@Maintainers ping. Fix is already in master branch on git's repo, you may want to use it since there are no tags nor versions in the repository and the official web page says to use the repo because of vulnerabilities in the last release. Thank you. Gentoo Security Padawan ChrisADR
Hello. Apologies for the extreme tardiness on this, but at Michał's prompting in bug 633010 I realized this was still pending and wanted to take a crack at it. I thought it made the most sense to do a full snapshot rather than backporting the specific patch in question as there's been a number of newer commits and bugfixes. That being said, I'm not sure how that's typically handled by Gentoo devs, so if my approach below is wrong I'd appreciate some guidance and I'll happily update as suggested. I cloned the repo from the last commit and created a snapshot available here: https://www.legroom.net/public/lha-114i_p20190124.txz I used the following SRC_URI since there's no upstream-provided snapshot. SRC_URI="mirror://gentoo/lha-114i_p20190124.txz" Other differences, for reference: * Both patches still seemed to apply, so I simply updated them * The PROTOTYPES bits discussed in bug 423125 no longer seem to apply, so I removed those lines. * The man page is (now?) in English, so I removed the line sending it to the Japanese directory. Compiled and tested on amd64. Seems to work as expected. Feedback welcome.
Created attachment 590626 [details] app-arch/lha-114i_p20190124.ebuild
Created attachment 590628 [details, diff] lha-114i-file-list-from-stdin.patch Note: the other patch (lha-114i-fix-getopt_long-declaration.patch) didn't need to be modified
If you're talking about the GitHub repo, you can just use the 'archive/' URL for a specific commit in SRC_URI. Take their 'download ZIP' URI, replace .zip with .tar.gz, 'master' with commit ID and it will work.
(In reply to Michał Górny from comment #8) > Take their 'download ZIP' URI, replace > .zip with .tar.gz, 'master' with commit ID and it will work. Nice, I didn't realize you could download a specific commit like that via HTTP. Thanks for the tip. Attaching updated ebuild using that method.
Created attachment 590630 [details] app-arch/lha-114i_p20190124.ebuild
Comment on attachment 590630 [details] app-arch/lha-114i_p20190124.ebuild ># Copyright 1999-2018 Gentoo Authors Please update your calendar. ># Distributed under the terms of the GNU General Public License v2 > >EAPI=7 > >inherit autotools flag-o-matic > >MY_P="${P/_p*}" Remove this, see below. >MY_COMMIT="e73199781397156be57866688a18d522d43c78ef" > >DESCRIPTION="Utility for creating and opening lzh archives" >HOMEPAGE="https://github.com/jca02266/lha https://lha.osdn.jp" >SRC_URI="https://github.com/jca02266/lha/archive/${MY_COMMIT}.tar.gz -> ${P}.tar.gz" > >LICENSE="lha" >SLOT="0" >KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~m68k-mint" > >S="${WORKDIR}/${PN}-${MY_COMMIT}" > >PATCHES=( > "${FILESDIR}"/${MY_P}-file-list-from-stdin.patch > "${FILESDIR}"/${MY_P}-fix-getopt_long-declaration.patch Just inline MY_P here. There is no real relation between snapshot version and the filename of those patches (they would probably still apply if upstream changed version number). Also, as a side request, could you consider submitting them to that GitHub repo? It looks silly to still have to apply patches when we're apparently switching to a patched snapshot. >) > >src_prepare() { > default > > sed -e 's/^AM_CONFIG_HEADER/AC_CONFIG_HEADERS/' \ > -i configure.ac || die #467544 Likewise (submit upstream). > > eautoreconf >} > >src_configure() { ># append-cppflags -DPROTOTYPES #423125 This is no longer necessary? Remove it then; flag-o-matic inherit too. > > if [[ ${CHOST} == *-interix* ]]; then > export ac_cv_header_inttypes_h=no > export ac_cv_func_iconv=no > fi > > econf or 'default'. >} > >src_install() { > emake \ > DESTDIR="${D}" \ > install or 'default'? ;-) > > dodoc ChangeLog Hacking_of_LHa >}
Created attachment 590844 [details] app-arch/lha-114i_p20190124.ebuild Thank you for the additional suggestions. Updated accordingly. I also submitted an upstream bug report as suggested. Took me a while to figure out the mingw32 patch, but I found an old (very old) discussion about it in bug 184911. Upstream bug here if interested: https://github.com/jca02266/lha/issues/15
(In reply to Jared B. from comment #12) > Created attachment 590844 [details] > app-arch/lha-114i_p20190124.ebuild > > Thank you for the additional suggestions. Updated accordingly. > Please submit that as a 'git format-patch', with appropriate sign-off on copyright policy and a nice commit message.
Ping.
@maintainer(s), please create an appropriate ebuild, or if you have already (which may be the case here), please contact proxy maintainers team to get it reviewed.
Hello. I believe the ebuild itself is in an appropriate format, but I'm not sure how to submit a git format-patch as previously requested. I'm not experienced with git outside of basic cloning and updating. I hadn't replied initially because I planned to research the matter and develop those skills, but I haven't been able to devote the time and lost track of this. Honestly, I'm not likely to find the time to sharpen those skills anytime soon due to other obligations, so I don't think I'm a good fit to be a proxy maintainer today. My development experience is too dated. I think it'd be better for someone else to take over maintenance of this and the couple other packages I (loosly) maintain: app-arch/unarj and media-gfx/iscan-plugin-gt-x820. Is there anything in particular I should do to formally step down? FYI, the LHA maintainer merged the following two patches after the last snapshot: fix-config_headers.patch fix-getopt_long-delaration.patch If you an updated snapshot from commit 7c3cd95fdf0d2f9198bb779561724cd314bc39a6, you can drop the local patches. It looks like he's also considering the stdin patch, but implemented slightly differently (using syntax similar to tar's -T option) due to concerns about potential unintended behavior.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5fd34b6c421e0e5a88e92c303d6e0a67fc90b33c commit 5fd34b6c421e0e5a88e92c303d6e0a67fc90b33c Author: John Helmert III <jchelmert3@posteo.net> AuthorDate: 2020-06-09 21:45:27 +0000 Commit: Aaron Bauman <bman@gentoo.org> CommitDate: 2020-06-13 02:05:56 +0000 app-arch/lha: Security bump Bug: https://bugs.gentoo.org/572418 Package-Manager: Portage-2.3.100, Repoman-2.3.22 Signed-off-by: John Helmert III <jchelmert3@posteo.net> Closes: https://github.com/gentoo/gentoo/pull/16155 Signed-off-by: Aaron Bauman <bman@gentoo.org> app-arch/lha/Manifest | 1 + app-arch/lha/lha-114i_p20201004.ebuild | 41 ++++++++++++++++++++++++++++++++++ 2 files changed, 42 insertions(+)
@maintainer(s), please call for stable when ready.
(In reply to Jared B. from comment #16) > fit to be a proxy maintainer today. My development experience is too dated. > > I think it'd be better for someone else to take over maintenance of this and > the couple other packages I (loosly) maintain: app-arch/unarj and > media-gfx/iscan-plugin-gt-x820. Is there anything in particular I should do > to formally step down? > To prevent huge text wall in this bug, I sent you an e-mail. Please check your inbox. For anyone else wondering, https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide#How_to_step_down_as_a_proxied_maintainer is a starting point.
x86 stable
arm stable
ppc stable
ppc64 stable
s390 stable
amd64 stable
hppa/sparc stable
@maintainer(s), please cleanup
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=10d6772384ac8f19f6cdc3803ea2de7a380765eb commit 10d6772384ac8f19f6cdc3803ea2de7a380765eb Author: Sam James <sam@gentoo.org> AuthorDate: 2020-07-16 00:27:16 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-07-16 01:01:33 +0000 app-arch/lha: security cleanup Bug: https://bugs.gentoo.org/572418 Package-Manager: Portage-2.3.99, Repoman-2.3.23 Signed-off-by: Sam James <sam@gentoo.org> app-arch/lha/Manifest | 1 - .../lha-114i-fix-getopt_long-declaration.patch | 11 ----- app-arch/lha/lha-114i-r9.ebuild | 54 ---------------------- 3 files changed, 66 deletions(-)
This issue was resolved and addressed in GLSA 202007-42 at https://security.gentoo.org/glsa/202007-42 by GLSA coordinator Sam James (sam_c).
