Cited from $URL: The vulnerability can be exploited by using the unsquashfs command to unpack a malicious squashfs image that causes a stack overflow in an unchecked variable length array. Thereafter, a function that copies data from the squashfs image to the overflown array is executed. I’m requesting a CVE number for this vulnerability, per project. Title: Stack overflows in squash-fs Products: squash-fs Affects: All versions Type: Stack overflow First CVE ID Request: Yes Title: Stack overflows in sasquatch Products: sasquatch Affects: All versions Type: Stack overflow First CVE ID Request: Yes Fore information about the stack overflow, please visit: https://github.com/devttys0/sasquatch/pull/5 Reproducible: Always
looks like i fixed this in 4.3-r1 when i pulled in the debian patchset
Let's stabilize =sys-fs/squashfs-tools-4.3-r2 but we wait for bug 600934 first.
pretty sure bug 600934 isn't a regression which means it doesn't block stabilization
You are the maintainer, you decide. So ok, let's start the stabilization: @ Arches, please test and mark stable: =sys-fs/squashfs-tools-4.3-r2
Stable on alpha.
amd64 stable
x86 stable
arm stable
sparc stable
Stable for HPPA.
ppc stable
ia64 stable
ppc64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
GLSA request filed.
This issue was resolved and addressed in GLSA 201701-73 at https://security.gentoo.org/glsa/201701-73 by GLSA coordinator Thomas Deutschmann (whissi).
Re-opening for cleanup. @ Maintainer(s): Please cleanup and drop <sys-fs/squashfs-tools-4.3-r1!
Why wasn't livecd@ CC'd to begin with? (In reply to Thomas Deutschmann from comment #16) > @ Maintainer(s): Please cleanup and drop <sys-fs/squashfs-tools-4.3-r1! I have no idea if the 3.0 and 3.1 SLOTs are vulnerable.
> > @ Maintainer(s): Please cleanup and drop <sys-fs/squashfs-tools-4.3-r1! > > I have no idea if the 3.0 and 3.1 SLOTs are vulnerable. Can we just cleanup or do you want to keep 3.0 or 3.1 for some reasons? If you want to keep we would have to investigate but I am not sure if it is worth to do...
(In reply to Thomas Deutschmann from comment #18) > do you want to keep 3.0 or 3.1 for some reasons? Well, obviously, or I wouldn't bring it up.
Ping: No update on the report since 02/17. Security Team Padawan ChrisADR
(In reply to Jeroen Roovers from comment #19) > (In reply to Thomas Deutschmann from comment #18) > > do you want to keep 3.0 or 3.1 for some reasons? > > Well, obviously, or I wouldn't bring it up. Jer, are these still needed?
(In reply to Aaron Bauman from comment #21) > (In reply to Jeroen Roovers from comment #19) > > (In reply to Thomas Deutschmann from comment #18) > > > do you want to keep 3.0 or 3.1 for some reasons? > > > > Well, obviously, or I wouldn't bring it up. > > Jer, are these still needed? That's not my name. Yes. Do not that only the latest stable ebuild installs /usr/bin/unsquashfs. The other SLOTted ebuilds append their major.minor version to the filename.
(In reply to Jeroen Roovers from comment #22) > Yes. Do not * note
(In reply to Jeroen Roovers from comment #22) > (In reply to Aaron Bauman from comment #21) > > (In reply to Jeroen Roovers from comment #19) > > > (In reply to Thomas Deutschmann from comment #18) > > > > do you want to keep 3.0 or 3.1 for some reasons? > > > > > > Well, obviously, or I wouldn't bring it up. > > > > Jer, are these still needed? > > That's not my name. > > Yes. Do not that only the latest stable ebuild installs /usr/bin/unsquashfs. > The other SLOTted ebuilds append their major.minor version to the filename. That is your nick though, right? Not sure what your point is here. Thanks for the information.
(In reply to Aaron Bauman from comment #24) > > > Jer, are these still needed? > > That's not my name. > That is your nick though, right? Not sure what your point is here. The point is that "jer" is my nick and not "Jer".
(In reply to Jeroen Roovers from comment #25) > (In reply to Aaron Bauman from comment #24) > > > > Jer, are these still needed? > > > That's not my name. > > That is your nick though, right? Not sure what your point is here. > > The point is that "jer" is my nick and not "Jer". English capitalization rules. Maybe you can redefine the whole language to suite your desires?
(In reply to Aaron Bauman from comment #26) > English capitalization rules. Maybe you can redefine the whole language to > suite your desires? I am very case sensitive. Why does that need explaining? And then why don't you simply accept the explanation you were given instead of throwing your "suite" (or "suit") of capitalisation rules at me?
Can the following be dropped, or are they secure? 3.4 : 3.1 / 3.2_p2 : 3.0
tree is clean.
FYI: commit ca69e5aeffc594a0c34edf2de59d75fc719ce8f2 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: Thu Mar 14 15:46:59 2019 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: Thu Mar 14 15:47:30 2019 Revert "sys-fs/squashfs-tools: drop vulnerable wrt bug #552484" This reverts commit 9f732c236cf298e463539a60e94060d5903209f9. Signed-off-by: Jeroen Roovers <jer@gentoo.org>
(In reply to Michał Górny from comment #30) > FYI: Looks like you have been misinformed.
Jeroen. I would like to request an official explanation: 1. Why did you revert the removal made by Aaron? 2. What effort did you do in order to communicate this to Aaron and/or the Security team? 3. Why is there no information on this neither in the commit message, nor on this particular bug?
See for instance these: https://bugs.gentoo.org/285709 https://bugs.gentoo.org/395201 mksquashfs and unsquashfs in the lower SLOTs are suffixed with -${PV} and should therefore never be called directly, unless you go out of your way to call them. Since over time various people have expressed an interest in keeping the older versions around, it certainly isn't up to bman to decide when or where they should go. Also, what is qa@ suddenly doing here? I would think security@ issues are no concern for qa@, and we can discuss this entirely without qa@ involvement.
QA is involved since you apparently knowingly introduced security issues. Please answer my questions.
Security team, do we have any *proof* that slots 3.0 and 3.1 are vulnerable?
if they are vulnerable, maybe one option could be to keep the old slots hardmasked :/
(In reply to Jeroen Roovers from comment #33) [snip] >Since over time various people have expressed an interest in > keeping the older versions around, it certainly isn't up to bman to decide > when or where they should go. These slots either have to be removed or hardmasked, there is no other way.
Jeroen, Given no satisfactory explanation, I'm going to reapply Aaron's commit with my QA hat on. If you believe this should be reverted, please follow the proper procedure. Include full explanation why you believe this should be reverted in the commit message, and especially clearly indicate whether those versions are affected by the vulnerability or not. Furthermore, if they are affected, then you are responsible for either applying appropriate patches or keeping the ebuilds masked as to prevent users from installing them unknowingly. And no, renaming executables does not change the fact that user can run them not expecting vulnerabilities. FTR, Security team has full authority to remove vulnerable (or even potentially vulnerable) ebuilds in order to fulfill their task of keeping Gentoo secure. While it is preferable to work with maintainer on this, if maintainer neglects his job for over 2 years, I don't see anything wrong with Security stepping up to do it, and doing it the way involving least work for them. If the maintainer disagrees with the decision of Security team, it is *his* responsibility to provide proper justification and/or solve the issue another way. However, the key point is that the issue needs to be solved (and if there is no issue, this needs to be documented), and not merely deferred forever. In lack of any solid evidence either way, the safe way is to assume all versions that are not fixed are vulnerable. If you disagree with that, feel free to appeal the action to Security team in general. However, until the Security issues a decision, the (potentially) vulnerable ebuilds must remain removed or masked. For completeness, I also point out that you are free to appeal Security team's decision further, up to the Council and then General Resolution.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4600db3d6bf1b83fe97517caec6c8f57d150db7 commit d4600db3d6bf1b83fe97517caec6c8f57d150db7 Author: Aaron Bauman <bman@gentoo.org> AuthorDate: 2019-03-11 02:38:08 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2019-03-24 15:56:37 +0000 sys-fs/squashfs-tools: [QA] drop vulnerable wrt bug #552484 Signed-off-by: Aaron Bauman <bman@gentoo.org> Bug: https://bugs.gentoo.org/552484 Signed-off-by: Michał Górny <mgorny@gentoo.org> sys-fs/squashfs-tools/Manifest | 2 -- sys-fs/squashfs-tools/squashfs-tools-3.2_p2.ebuild | 39 ---------------------- sys-fs/squashfs-tools/squashfs-tools-3.4.ebuild | 39 ---------------------- 3 files changed, 80 deletions(-)
Hi! (In reply to Michał Górny from comment #38) > FTR, Security team has full authority to remove vulnerable (or even > potentially vulnerable) ebuilds in order to fulfill their task of keeping > Gentoo secure. Could you please explain on what premises this statement is made. I found no GLEP giving such power to the Security project, neither an established security policy mandating such actions [1]. Furthermore most software is potentially vulnerable, but removing it without the evidence of a vulnerability present will result into havoc. Good examples are recent openssl-1.1.1 and kernel-5.0.x versions. Judging from prior history of such projects these versions likely contain vulnerabilities which will be announced later. Based on "even potentially vulnerable" logic they must be purged from the Gentoo tree immediately. But of course that would be absurd. [1] https://wiki.gentoo.org/wiki/Project:Security
(In reply to Andrew Savchenko from comment #40) > Hi! > > (In reply to Michał Górny from comment #38) > > FTR, Security team has full authority to remove vulnerable (or even > > potentially vulnerable) ebuilds in order to fulfill their task of keeping > > Gentoo secure. > > Could you please explain on what premises this statement is made. I found no > GLEP giving such power to the Security project, neither an established > security policy mandating such actions [1]. It is made on premises of sanity. If you prevent a project from doing its job, there's no point in having the project in the first place. Last I checked, we're not some insane bureaucracy where you can't fart without written permission stamped by the Council. > Furthermore most software is potentially vulnerable, but removing it without > the evidence of a vulnerability present will result into havoc. Good > examples are recent openssl-1.1.1 and kernel-5.0.x versions. Judging from > prior history of such projects these versions likely contain vulnerabilities > which will be announced later. Based on "even potentially vulnerable" logic > they must be purged from the Gentoo tree immediately. But of course that > would be absurd. Yes, what you're saying is absurd. However, that's not what I'm saying, so I would be appreciate if you didn't put words in my mouth to prove your point. There is a fair difference between killing software because 'all software is buggy', and presuming that a vulnerability discovered in the current version of software may be present in older versions as well. Otherwise, we'd end up doing such insane things as removing the newest version of software and telling people to downgrade because nobody convinced you that the old version has the same bug yet!
