CVE-2017-15953 (https://nvd.nist.gov/vuln/detail/CVE-2017-15953): bchunk (related to BinChunker) 1.2.0 and 1.2.1 is vulnerable to a heap-based buffer overflow and crash when processing a malformed CUE (.cue) file. References: https://github.com/extramaster/bchunk/issues/2 CVE-2017-15954 (https://nvd.nist.gov/vuln/detail/CVE-2017-15954): bchunk (related to BinChunker) 1.2.0 and 1.2.1 is vulnerable to a heap-based buffer overflow (with a resultant invalid free) and crash when processing a malformed CUE (.cue) file. References: https://github.com/extramaster/bchunk/issues/3 CVE-2017-15955 (https://nvd.nist.gov/vuln/detail/CVE-2017-15955): bchunk (related to BinChunker) 1.2.0 and 1.2.1 is vulnerable to an "Access violation near NULL on destination operand" and crash when processing a malformed CUE (.cue) file. References: https://github.com/extramaster/bchunk/issues/4
Thanks for notifying, I still nominally maintain this ebuild :-) Here are patches: https://github.com/extramaster/bchunk/issues/2#issuecomment-340561560 https://github.com/extramaster/bchunk/issues/4#issuecomment-340554799 I'll open a PR to gentoo ebuild repo on GitHub with ebuild update when these patches are tested by the guy who found these vulnerabilities.
FYI: I pushed the PR in 8c1539b16c078e750713e3e0a073f5f95754d16b
@ Maintainer(s): Thank you for the patches, please state when you're ready for stabilization.
I am ready for stabilization, however note that I don't use Gentoo anymore.
@ Arches: Please stabilize =app-cdr/bchunk-1.2.0-r4.
B2 because it is a write issue.
(In reply to Agostino Sarubbo from comment #6) > B2 because it is a write issue. All 3 CVE's say it can lead to a crash. Please stop over classifying bugs if there is no proof of concept for an ACE/RCE. The security team has enough bugs to handle and assumptions are not helping.
amd64 stable
x86 stable
sparc stable (thanks to Rolf Eike Beer)
ppc stable
I guess you have to start over again... http://he.fi/bchunk/bchunk-1.2.2.tar.gz
@maintainer(s), please clean the vulnerable.
It actually is still vulnerable (patch doesn't fully apply): https://github.com/extramaster/bchunk/issues/2#issuecomment-343890234
(In reply to Yegor Timoshenko from comment #14) > It actually is still vulnerable (patch doesn't fully apply): > https://github.com/extramaster/bchunk/issues/2#issuecomment-343890234 Indeed. It does not apply. @maintainer(s), please bump to >=1.2.2 as discussed. I imagine a PR is needed as you are a proxy maintainer.
(In reply to Aaron Bauman from comment #15) > (In reply to Yegor Timoshenko from comment #14) > > It actually is still vulnerable (patch doesn't fully apply): > > https://github.com/extramaster/bchunk/issues/2#issuecomment-343890234 > > Indeed. It does not apply. > > @maintainer(s), please bump to >=1.2.2 as discussed. I imagine a PR is > needed as you are a proxy maintainer. We're essentially there, as far as I can tell at the moment. New git repo: https://github.com/hessu/bchunk/ (linked from package url: http://he.fi/bchunk/) Patches: https://github.com/hessu/bchunk/commit/6a053c13ad79c49a801656d6d313a186847ccb66 https://github.com/hessu/bchunk/commit/c021dcddd07fa78d95217373c83f9caa74a1ced4 The patches for these (things since 1.2.0) are the same as what we're already using in the ebuild, but currently, these warnings(?) show up: >* Applying CVE-2017-15953.patch ... [ ok ] >* Applying CVE-2017-15955.patch ... >patching file bchunk.c >Hunk #1 succeeded at 426 with fuzz 1. >patch unexpectedly ends in middle of line >[ ok ] >>>> Source prepared. I've bumped the ebuild and generated fresh patches with their origin in a PR shortly.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8b72a896d777319bbd9308cf2735a4b2510ca998 commit 8b72a896d777319bbd9308cf2735a4b2510ca998 Author: Sam James (sam_c) <sam@cmpct.info> AuthorDate: 2020-03-17 20:49:05 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-03-18 08:35:29 +0000 app-cdr/bchunk: Security bump (to 1.2.2) See bug for context. Previous patches weren't applying cleanly and upstream have made a new release with the fixes. Bug: https://bugs.gentoo.org/635898 Signed-off-by: Sam James (sam_c) <sam@cmpct.info> Closes: https://github.com/gentoo/gentoo/pull/14998 Signed-off-by: Joonas Niilola <juippis@gentoo.org> app-cdr/bchunk/Manifest | 1 + app-cdr/bchunk/bchunk-1.2.2.ebuild | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+)
@maintainer(s), please advise if ready for stabilisation, or call yourself.
Resetting sanity check; keywords are not fully specified and arches are not CC-ed.
Been in tree for a month, maintainer-needed, no bugs reported. Let's stabilise.
dropped to ~sparc
ppc/ppc64 stable
sparc stable
needs cleanup
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2b37e13e97088aac336cda009d18e69de116337c commit 2b37e13e97088aac336cda009d18e69de116337c Author: Aaron Bauman <bman@gentoo.org> AuthorDate: 2020-06-18 02:39:47 +0000 Commit: Aaron Bauman <bman@gentoo.org> CommitDate: 2020-06-18 02:40:15 +0000 app-cdr/bchunk: drop vulnerable Bug: https://bugs.gentoo.org/635898 Signed-off-by: Aaron Bauman <bman@gentoo.org> app-cdr/bchunk/Manifest | 1 - app-cdr/bchunk/bchunk-1.2.2.ebuild | 20 -------------------- 2 files changed, 21 deletions(-)
Why was bchunk-v1.2.2 just dropped from the portage tree causing a downgrade to the vulnerable v1.2.0 ?!? Those patches are not required for v1.2.2 as per the release notes from the upstream. See http://he.fi/bchunk/ <snip> 1.2.2 (14 Nov 2017): SECURITY UPDATE Fixes CVE-2017-15953 and CVE-2017-15954, a heap-based buffer overflow. Fix provided by Yegor Timoshenko. Fixes CVE-2017-15955, Access violation near NULL on destination operand and crash when processing a malformed CUE (.cue) file. Fix provided by Yegor Timoshenko. Fix wrong track size calculation when having multiple tracks in one image (debian bug: #261274). Fix provided by Piotr Kaczuba. Clarified manual page for input/output file types. Improvement from Reuben Thomas (debian bug: #503151). 1.2.0 (29 Jun 2004): Man page patch from the openbsd port -r option for MODE2/2352 MPEG/VCD support </snip> Can we please get v1.2.2 as the latest upstream release restored to the portage tree, even if marked as unstable?
(In reply to David Turner from comment #28) > Why was bchunk-v1.2.2 just dropped from the portage tree causing a downgrade > to the vulnerable v1.2.0 ?!? > This is clearly a mistake. Please remember we're human and we're in challenging times right now, sometimes people do slip up. Thank you for pointing this out, I'll get it resolved now.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4c49af6fe414f41fc3e98375ecdf152b06204793 commit 4c49af6fe414f41fc3e98375ecdf152b06204793 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-06-18 23:32:54 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-06-18 23:32:54 +0000 app-cdr/bchunk: security cleanup Bug: https://bugs.gentoo.org/635898 Package-Manager: Portage-2.3.101, Repoman-2.3.22 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> app-cdr/bchunk/Manifest | 1 - app-cdr/bchunk/bchunk-1.2.0-r4.ebuild | 21 -------------------- app-cdr/bchunk/files/CVE-2017-15953.patch | 25 ------------------------ app-cdr/bchunk/files/CVE-2017-15955.patch | 32 ------------------------------- 4 files changed, 79 deletions(-)
(In reply to Sam James (sec padawan) from comment #29) > (In reply to David Turner from comment #28) > > Why was bchunk-v1.2.2 just dropped from the portage tree causing a downgrade > > to the vulnerable v1.2.0 ?!? > > > > This is clearly a mistake. Please remember we're human and we're in > challenging times right now, sometimes people do slip up. > > Thank you for pointing this out, I'll get it resolved now. Thanks for resolving this so quickly. I understand, though still concerning.
(In reply to David Turner from comment #31) > Thanks for resolving this so quickly. > > I understand, though still concerning. Definitely. I will keep an eye to make sure it doesn't happen again. Please feel free to ping us (or me) in #gentoo-security if you ever have any queries too.
