From ${URL} : A quoting issue was found in chkrootkit which would lead to a file in /tmp/ being executed, if /tmp/ was mounted without the noexec option. chkrootkit is typically run as the root user. A local attacker could use this flaw to escalate their privileges. The problematic part was: file_port=$file_port $i Which is changed to file_port="$file_port $i" to fix the issue. From the Debian diff: --- chkrootkit-0.49.orig/debian/patches/CVE-2014-0476.patch +++ chkrootkit-0.49/debian/patches/CVE-2014-0476.patch @@ -0,0 +1,13 @@ +Index: chkrootkit/chkrootkit +=================================================================== +--- chkrootkit.orig/chkrootkit ++++ chkrootkit/chkrootkit +@@ -117,7 +117,7 @@ slapper (){ + fi + for i in ${SLAPPER_FILES}; do + if [ -f ${i} ]; then +- file_port=$file_port $i ++ file_port="$file_port $i" + STATUS=1 + fi + done @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.
*** Bug 512620 has been marked as a duplicate of this bug. ***
fixed in 0.50
*If* there is a problem with the version bump, maybe the fix could be backported.
*** Bug 516132 has been marked as a duplicate of this bug. ***
CVE-2014-0476 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-0476): The slapper function in chkrootkit before 0.50 does not properly quote file paths, which allows local users to execute arbitrary code via a Trojan horse executable. NOTE: this is only a vulnerability when /tmp is not mounted with the noexec option.
Time to PMASK... # Aaron Bauman <bman@gentoo.org> (19 Mar 2016) # Unpatched security vulnerability per bug #512356. # Masked for removal in 30 days. app-forensics/chkrootkit
eh... there is a 0.50 available that PATCHES this problem..?? (already for a few years)...
(In reply to Nico Baggus from comment #7) > eh... there is a 0.50 available that PATCHES this problem..?? > (already for a few years)... Nico, if you are interested in proxy maintaining[0] please let us know. [0]: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
I've bumped the fixed/unaffected 0.50 version, so can you please change the ban to 0.49 only? Thanks commit ae6d6ffd8eed52b9ee9c484c6674b8e2e1d236ca Author: Michael Weber <xmw@gentoo.org> Date: Mon Mar 21 12:38:27 2016 +0100 app-forensics/chkrootkit: Version bump (bug 529308, thanks Paolo Pedroni).
(In reply to Michael Weber from comment #9) > I've bumped the fixed/unaffected 0.50 version, so can you please change the > ban to 0.49 only? Thanks > > commit ae6d6ffd8eed52b9ee9c484c6674b8e2e1d236ca > Author: Michael Weber <xmw@gentoo.org> > Date: Mon Mar 21 12:38:27 2016 +0100 > > app-forensics/chkrootkit: Version bump (bug 529308, thanks Paolo > Pedroni). Michael, please just remove 0.49 and the PMASK (or I can remove the PMASK). We can call for a rapid stabilization here from the arches due to the current 0.49 already being stabilized.
@arches, please stabilize on the following arches: TARGET KEYWORDS = alpha, amd64, arm, hppa, ia64, ppc, ppc64, s390, sh, sparc, x86
PMASK adjusted to app-forensics/chkrootkit-0.49
amd64 stable
*** Bug 529308 has been marked as a duplicate of this bug. ***
ppc stable
arm stable
x86 stable
Stable on alpha.
@arches, ping.
(removing arch teams for non-stable arches)
sparc stable
ppc64 stable
ia64 stable
(In reply to Aaron Bauman from comment #19) > @arches, ping. Bug #578208. I can't believe how people are stabilising this.
Can we finish the stabilization on this please? If the depends bug is not causing any issues we can stabilize at a future time.
Any status for hppa (this is a B1 vulnerability)?
@hppa any issues still here?
Cleanup done.
Arches, please finish stabilizing hppa Gentoo Security Padawan ChrisADR
(In reply to Christopher Díaz from comment #29) > Arches, please finish stabilizing hppa > > Gentoo Security Padawan > ChrisADR HPPA is no longer a stable arch for this package per https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs Vulnerable versions have been cleaned up, security team can proceed.
Security please add to an existing glsa or file a new one thanks, Gentoo Security Padawan ChrisADR
New GLSA Request filed.
This issue was resolved and addressed in GLSA 201709-05 at https://security.gentoo.org/glsa/201709-05 by GLSA coordinator Aaron Bauman (b-man).