Summary: | app-cdr/cdrtools: fix local root vulnerability | ||||||
---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Alin Năstac (RETIRED) <mrness> | ||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | major | CC: | pylon | ||||
Priority: | High | Keywords: | InVCS | ||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
URL: | http://www.mandrakesoft.com/security/advisories?name=MDKSA-2004:091 | ||||||
Whiteboard: | B1 [glsa] koon | ||||||
Package list: | Runtime testing required: | --- | |||||
Attachments: |
|
Description
Alin Năstac (RETIRED)
2004-09-07 22:05:59 UTC
Created attachment 39179 [details, diff]
scsi-remote.c.diff
Resolve MDKSA-2004:091 issue.
Pylon please verify and apply. Mandrake advisory: Max Vozeler found that the cdrecord program, which is suid root, fails to drop euid=0 when it exec()s a program specified by the user through the $RSH environment variable. This can be abused by a local attacker to obtain root privileges. This has been assigned CAN-2004-0806 We don't install cdrecord suid root by default. The user has to act to change it's state. E.g. k3b's setup utility allows to change the state, but we warn about it during installation of k3b. I don't think that we need to apply the patch. Security-team, you have the last word. My 2 eurocents: I think it would be best to apply this patch, even if security don't issue a glsa. Prolly there are gentooers who choosed to suid their cdrecord. Why not secure their cdrecord? I would say the patch should be applied. It's not the first time that we issue a GLSA on a non-by-default setup. And cdrecord must be SUID on a lot of machines. I would add the patch and skip the GLSA process. agreed, theres no reason not to add the patch although people would have to +s cdrecord themselves i'd imagine people do since k3b supports it as such Pylon please apply the patch. The maintainer took to long so I added the patch to the following ebuilds. cdrtools-2.01_alpha28-r2.ebuild cdrtools-2.01_alpha37-r1.ebuild We should still probably have the arches mark these stable. Perferably 2.01_alpha37-r1 and then remove the old ebuilds. cdrtools-2.01_alpha28-r2 KEYWORDS="~x86 ~ppc ~sparc ~alpha ~hppa ~amd64 ~ia64 ~ppc64 ~mips" cdrtools-2.01_alpha37-r1 KEYWORDS="~x86 ~ppc ~sparc ~alpha ~hppa ~amd64 ~ia64 ~ppc64 ~mips" Arches please test and mark stable. Preferably 2.01_alpha37-r1 otherwise 2.01_alpha28-r2. jaervosz, don't forget about cdrecord-prodvd cdrrecord-prodvd does not compile cdrtools by itself. thanks jaervosz for observing that. sorry folks, my mistake. Sorry, I was not around the last days. One sidenote: cdrtools-2.01_alpha37 could have some problems with kernel <2.6.8 and audio-cd-writing. Furthermore I'm about to add cdrtools-2.01 (the stable version) to the tree. Thx Pylon. Arches please test and mark stable. Preferably 2.01 (just added) otherwise 2.01_alpha37-r1 or 2.01_alpha28-r2. 2.01 stable on sparc, tested audio on 2.4 with -v -dao -pad just fine, also iso. Stable on hppa. 2.01 stable on amd64 2.01 stable on x86 and ppc. GLSA drafted, security please review GLSA 200409-18 alpha,ia64,mips,ppc64 don't forget to mark stable to benifit from GLSA. mips stable. thanks, stable on ppc64 |