In order to allow regular users to run xcdroast, it sets 4755 permission bits on /usr/lib/xcdroast-0.98/bin/xcdrwrap, and checks for those exact bits when run by non-root. I suggest changing 4755 to 4711, in light of the recent glibc vulnerabilities, and in accordance with Gentoo policy on suid/sgid bits. ./doc/README.nonroot: chmod 4755 xcdrwrap ./src/io.c: g_snprintf(tmp,MAXLINE,"%s 4755 %s\n", cmd_chmod, bin); ./src/init.c: if (buf.st_mode != 0104755) {
Can this be fixed? There is a new vulnerability that's much easier to exploit with read access to SUID binaries (CVE-2012-0056).
@media-optical: could the suid USE flag be added here? please how we should proceed.
Fedora is compiling it with --disable-nonrootmode and applying this to silence the warnings: http://pkgs.fedoraproject.org/cgit/rpms/xcdroast.git/plain/xcdroast-0.98alpha15-nowarn.patch maybe that could be an option :/
If that is not the solution, we will probably go with treecleaning this as this won't get any fix ever (upstream dead ages ago)
(In reply to Pacho Ramos from comment #4) > If that is not the solution, we will probably go with treecleaning this as > this won't get any fix ever (upstream dead ages ago) No rdeps... sounds good to me.
(In reply to Aaron Bauman from comment #5) > (In reply to Pacho Ramos from comment #4) > > If that is not the solution, we will probably go with treecleaning this as > > this won't get any fix ever (upstream dead ages ago) > > No rdeps... sounds good to me. I use this as it's the only GUI to support RSCSI.
(In reply to Pacho Ramos from comment #4) > If that is not the solution, we will probably go with treecleaning this as > this won't get any fix ever (upstream dead ages ago) I've used this for many years to write CDs & DVDs. It works & is easy to use. The original bug dates from 2010 & was left unresolved after January 2012, ie 4.5 years ago. Suddenly, it has been taken up again by the maintainer. Packages should not be treecleaned, even if upstream is dead, unless they no longer compile or work or there is a serious security problem. Xcdroast compiles & works -- at least as of Oct 2015 -- & if there might be a security problem, it seems not to be serious & has been left unresolved for a very long time. Please leave Xcdroast where it is.
(In reply to Philip Webb from comment #7) > (In reply to Pacho Ramos from comment #4) > > If that is not the solution, we will probably go with treecleaning this as > > this won't get any fix ever (upstream dead ages ago) > > I've used this for many years to write CDs & DVDs. > It works & is easy to use. > The original bug dates from 2010 & was left unresolved after January 2012, > ie 4.5 years ago. Suddenly, it has been taken up again by the maintainer. > > Packages should not be treecleaned, even if upstream is dead, > unless they no longer compile or work or there is a serious security problem. > Xcdroast compiles & works -- at least as of Oct 2015 -- > & if there might be a security problem, it seems not to be serious > & has been left unresolved for a very long time. > > Please leave Xcdroast where it is. Would you like to proxy-maintain it?
(In reply to Aaron Bauman from comment #8) > (In reply to Philip Webb from comment #7) > > (In reply to Pacho Ramos from comment #4) > > > If that is not the solution, we will probably go with treecleaning this as > > > this won't get any fix ever (upstream dead ages ago) > > I've used this for many years to write CDs & DVDs. > > It works & is easy to use. > > The original bug dates from 2010 & was left unresolved after January 2012, > > ie 4.5 years ago. Suddenly, it has been taken up again by the maintainer. > > Xcdroast compiles & works -- at least as of Oct 2015 -- > > & if there might be a security problem, it seems not to be serious > > & has been left unresolved for a very long time. > > Please leave Xcdroast where it is. > Would you like to proxy-maintain it? Sorry for the delay in replying : I expected to receive an e-alert when someone responded to my comment, but none has arrived. Besides my comment above, I notice that the report in 2010 seems to refer to use of Xcdroast on multi-user systems. On a single-user system the user can simply change the permission to 755 himself without risk. This is reminiscent of the recent case of Nethack, where there was a security bug, but only on multi-user systems : Nethack was restored to the tree, where it remains. Most desktop Gentoo systems are single-user. Also, the reason for dropping it seems to have changed from "multiple bugs" -- there was only 1 back in 2010, not "multiple" -- to "maintainer needed". The latter is not usually a justification for tree-cleaning, at least not until there's been a request for help. So the proper course of action seems to be for you to unmask it again and ask on appropriate list(s) for potential maintainers to step forward. I might be willing to be proxy maintainer, but am not sure what's involved ; given that there was no comment for 4 years, it might not be a burden (smile).
(In reply to Philip Webb from comment #9) > (In reply to Aaron Bauman from comment #8) > > (In reply to Philip Webb from comment #7) > > > (In reply to Pacho Ramos from comment #4) > > > > If that is not the solution, we will probably go with treecleaning this as > > > > this won't get any fix ever (upstream dead ages ago) > > > I've used this for many years to write CDs & DVDs. > > > It works & is easy to use. > > > The original bug dates from 2010 & was left unresolved after January 2012, > > > ie 4.5 years ago. Suddenly, it has been taken up again by the maintainer. > > > Xcdroast compiles & works -- at least as of Oct 2015 -- > > > & if there might be a security problem, it seems not to be serious > > > & has been left unresolved for a very long time. > > > Please leave Xcdroast where it is. > > Would you like to proxy-maintain it? > > Sorry for the delay in replying : I expected to receive an e-alert when > someone responded to my comment, but none has arrived. > > Besides my comment above, I notice that the report in 2010 seems to refer > to use of Xcdroast on multi-user systems. On a single-user system > the user can simply change the permission to 755 himself without risk. > This is reminiscent of the recent case of Nethack, where there was > a security bug, but only on multi-user systems : Nethack was restored > to the tree, where it remains. Most desktop Gentoo systems are single-user. > > Also, the reason for dropping it seems to have changed from "multiple bugs" > -- there was only 1 back in 2010, not "multiple" -- to "maintainer needed". > The latter is not usually a justification for tree-cleaning, > at least not until there's been a request for help. > > So the proper course of action seems to be for you to unmask it again > and ask on appropriate list(s) for potential maintainers to step forward. > > I might be willing to be proxy maintainer, but am not sure what's involved ; > given that there was no comment for 4 years, it might not be a burden > (smile). The previous patch could be implemented to disable non-root mode.
> the report in 2010 seems to refer to use of Xcdroast on multi-user systems. > On a single-user system the user can simply change the permission to 755 himself without risk. This doesn't make any sense. The bug deals with read permissions of an SUID executable. The SUID permissions are necessary for accessing the hardware.
(In reply to Faustus from comment #11) > > the report in 2010 seems to refer to use of Xcdroast on multi-user systems. > > On a single-user system the user can simply change the permission to 755 himself without risk. > > This doesn't make any sense. > The bug deals with read permissions of an SUID executable. > The SUID permissions are necessary for accessing the hardware. No problem here : I have the SUID set as installed and Xcdroast is at this moment in the process of writing a DVD for me. There is no security issue on a single-user system. All that is needed is a warning to any sysadmin who plans to install it on a multi-user system. It's the same basic issue as with Nethack, which is still in the tree. Xcdroast has never given me any problem.
Again, the original *security* bug report deals with the vulnerability of a system with world-readable SUID executables to a certain class of libc-related local privilege escalation exploits. There is (or was) a Gentoo policy on the matter because of that, to not make SUID executables world-readable. It has nothing to do with whether the system is single- or multi-user, nothing to do with the ability of the user to copy the executable, or with the usability of the program itself.
(In reply to Faustus from comment #13) > Again, the original *security* bug report deals with the vulnerability of a > system with world-readable SUID executables to a certain class of > libc-related local privilege escalation exploits. There is (or was) a Gentoo > policy on the matter because of that, to not make SUID executables > world-readable. It has nothing to do with whether the system is single- or > multi-user, nothing to do with the ability of the user to copy the > executable, or with the usability of the program itself. Really, you're contradicting yourself (smile). No "local privilege escalation exploit" is of any importance on a single-user system ! If Gentoo did indeed have a policy as you describe, then it's overkill and needs to be changed. This issue is very similar to the one re Nethack some time ago, which was resolved with Nethack being unmasked and remaining in the tree. Earlier today, Joerg Schilling sent a comment to the Users list : "This should not be a problem as long as you use cdrtools that are more recent than from April 2013, when Linux started to support fine grained privileges in the userland. All you need to do is to is to disable the xcdroast suid wrapper". The discussion so far makes it clear that there's no justification for tree-cleaning Xcdroast. It should be unmasked at once.
(In reply to Philip Webb from comment #14) > No "local privilege escalation exploit" is of any importance on a single-user system ! Wrong, as there is a reason why many daemons drop privileges as soon as possible.
(In reply to Faustus from comment #15) > (In reply to Philip Webb from comment #14) >> No "local privilege escalation exploit" is of any importance on a single-user system ! > Wrong, as there is a reason why many daemons drop privileges as soon as > possible. Again, I can't see the relevance to Xcdroast : it doesn't run any daemons. I can amend my statement to "No local privilege escalation exploit is of any importance on a single-user system, unless it involves a daemon" and it still rules Xcdroast out as a possible security threat on a single-user system. The original bug which started this problem arises only when Xcdroast is installed on a multi-user system, surely a small minority of installations. It has no effect on my use of Xcdroast on my single-user system, so there is no justification for preventing me from using it by removing it from the tree.
Your system runs such daemons, which, although running with minimal privileges, in case they are exploited, can lead to a full system compromise via local privilege escalation. This is why FEATURES=sfperms was enabled by default, to protect against this class of libc-related vulnerabilities. https://archives.gentoo.org/gentoo-dev/message/119cf92aa73988a9f39cac2d8088ff08 The problem with xcdroast is that there is a check in the code for the exact 4755 permissions of the executable. The fix is trivial.
Could you two please stop spamming this bug, please? Whether you or 'majority of people you care about' are using a single- or multi-user system, it doesn't matter. Gentoo should provide a sane experience for everyone. People are not expected to check if package is suitable for multi-user systems before installing it. If xcdroast provides some kind of access checks beyond the suid executable, it's fine. If it provides burning access for everyone on the system, it is wrong and needs to be fixed. You can limit it to a specific group of users, use CK/logind/whatever, or just disable suid altogether and force running as root -- doesn't matter to me. But I'm against any program that randomly allows remote users to burn media because of someone's beliefs. If you really want to maintain the package, look at the open bugs, provide fixes as patches/PRs and we'll add you and keep it. If you don't, the package is going to be removed as unmaintained deadware. So either do the needful, or find yourself a maintained burning software. It's not like xcdroast is the only program out there.
(In reply to Michał Górny from comment #18) > Could you two please stop spamming this bug, please? It is not my fault that this bug was open for 6 years, and no one, including you, understands the reason for it anymore. The fault is with insurmountable Gentoo bureaucracy, where instead of occasionally dealing with bugfix conflicts, you have this ridiculous separation of responsibilities, to top the ridiculously complex process for becoming a Gentoo developer. The only reason I reply here is to correct people who misunderstand the issue at hand. It has nothing to do with single- or multi-user system, with having SUID permissions, with ability to use the program, or whatever else. The only issue is vulnerability of world-readable SUID executables to a certain class of attacks, which is why there is a policy against that. If there is no such policy anymore, just close this bug.
(In reply to Michał Górny from comment #18) > Could you two please stop spamming this bug, please? > > Whether you or 'majority of people you care about' are using a single- or > multi-user system, it doesn't matter. Gentoo should provide a sane > experience for everyone. People are not expected to check if package is > suitable for multi-user systems before installing it. > > If xcdroast provides some kind of access checks beyond the suid executable, > it's fine. If it provides burning access for everyone on the system, it is > wrong and needs to be fixed. You can limit it to a specific group of users, > use CK/logind/whatever, or just disable suid altogether and force running as > root -- doesn't matter to me. But I'm against any program that randomly > allows remote users to burn media because of someone's beliefs. > > If you really want to maintain the package, look at the open bugs, provide > fixes as patches/PRs and we'll add you and keep it. If you don't, the > package is going to be removed as unmaintained deadware. > > So either do the needful, or find yourself a maintained burning software. > It's not like xcdroast is the only program out there. Could you please stop threatening people with "may way or the highway" approach as well as acting on the verge of abusing your security hat by enforcing your own vision on everyone with power? It users want to use the package — fine, let them use it. What is the problem with masking package but not removing it? As long as it works, let users be happy by using it on their own risk even if it is vulnerable (though the discussed vulnerability is not that severe). Just warn them properly. When and if package will no longer compile or work, it will be ditched from the tree.
Hi all, I updated xcdroast to fix this and other issues: commit 4755d711c314606043af7c55c0675d89d0c4b618 Author: Andrew Savchenko <bircoph@gentoo.org> Date: Thu Jul 7 21:47:42 2016 +0300 app-cdr/xcdroast: fix for the bug 345337 - Replace suid helper permissions from 4755 to 4711 as suggested by Faustus in comment 1. - Port ebuild to EAPI=6. - Apply upstream patch for progress bar with modern cdrtools. xcdroast users, please test that xcdroast-0.98_alpha16-r2.ebuild works for you (you can burn some CD/DVD as a non-root user after usual setup). I don't have a hardware right now to test it. After confirmation I'll keep p.mask only for older revisions and will request stabilization of this revision. Afterwards all old versions will be dropped.
(In reply to Andrew Savchenko from comment #21) > I updated xcdroast to fix this and other issues: > > commit 4755d711c314606043af7c55c0675d89d0c4b618 > Author: Andrew Savchenko <bircoph@gentoo.org> > Date: Thu Jul 7 21:47:42 2016 +0300 > > app-cdr/xcdroast: fix for the bug 345337 > > - Replace suid helper permissions from 4755 to 4711 as suggested by > Faustus in comment 1. > - Port ebuild to EAPI=6. > - Apply upstream patch for progress bar with modern cdrtools. > > xcdroast users, please test that xcdroast-0.98_alpha16-r2.ebuild works for > you (you can burn some CD/DVD as a non-root user after usual setup). I don't > have a hardware right now to test it. > > After confirmation I'll keep p.mask only for older revisions and will > request stabilization of this revision. Afterwards all old versions will be > dropped. Thanks greatly. I will test -r2 after my regular Saturday system update & report the result to this bug. Let me know if you need it sooner. I will also inform other users via the User list. Sometimes moving a molehill is more difficult that moving a mountain (smile).
Created attachment 440038 [details, diff] Add USE=suid and minor improvements As somebody now seems to take care about the ebuild, let me suggest to make the whole suid wrapper optional (i.e. per USE-flag): With reasonably new (3-4 years old) versions of cdrtools and kernels the SUID-wrapper is not needed at all, and people with older versions might want to prefer running xcdroast as root instead of having a wrapper. In the attached patch, USE="suid" is supported by the ebuild. I also moved the call to "default" so that "eapply_user" is called as late as possible, and I added some EPREFIX love.
(In reply to Martin Väth from comment #23) > Created attachment 440038 [details, diff] [details, diff] > Add USE=suid and minor improvements > > As somebody now seems to take care about the ebuild, let me suggest to make > the whole suid wrapper optional (i.e. per USE-flag): > > With reasonably new (3-4 years old) versions of cdrtools and kernels the > SUID-wrapper is not needed at all, and people with older versions might want > to prefer running xcdroast as root instead of having a wrapper. OK. But just for the record: having a wrapper doesn't remove ability to use this program as root only. Just after installation xcdrwrap have no suid bit and thus is useless, users have to enable it explicitly using xcdroast GUI. > In the attached patch, USE="suid" is supported by the ebuild. > > I also moved the call to "default" so that "eapply_user" is called as late > as possible, Whenever user patches should be applied before or after ebuild-driven modifications is a matter of preference, nothing more. > and I added some EPREFIX love. This package has no prefix arches in KEYWORDS. What is the point of adding EPREFIX support? I don't mind that, but if someone is interested in prefix, package must be properly keyworded.
Comment on attachment 440038 [details, diff] Add USE=suid and minor improvements >--- xcdroast-0.98_alpha16-r2.ebuild >+++ xcdroast-0.98_alpha16-r2.ebuild >@@ -12,7 +12,7 @@ > LICENSE="GPL-2" > SLOT="0" > KEYWORDS="~amd64 ~ppc ~sparc ~x86" >-IUSE="nls" >+IUSE="nls suid" > > RDEPEND=">=x11-libs/gtk+-2:2 > app-cdr/cdrtools" >@@ -31,17 +31,18 @@ > ) > > src_prepare() { >- default >- > # fix Norwegian locales > mv po/{no,nb}.po || die > mv po/{no,nb}.gmo || die > sed -i -e 's/no/nb/' po/LINGUAS || die >+ # eapply_user should be _after_ the above... >+ default > } > > src_configure() { > econf \ > $(use_enable nls) \ >+ $(use_enable suid nonrootmode) \ > --enable-gtk2 \ > --disable-dependency-tracking \ > --mandir=/usr/share/man \ >@@ -49,11 +50,11 @@ > } > > src_compile() { >- emake PREFIX=/usr >+ emake PREFIX="${EPREFIX}"/usr > } > > src_install() { >- emake PREFIX=/usr DESTDIR="${D}" install >+ emake PREFIX="${EPREFIX}"/usr DESTDIR="${ED}" install This is going to get package installed with double EPREFIX. If you use EPREFIX, don't use ED. > > dodoc -r AUTHORS ChangeLog README doc/* >
(In reply to Andrew Savchenko from comment #24) > having a wrapper doesn't remove ability to use this program as root only. Having a SUID wrapper is an unnecessary security risk if it is not needed. > Just after installation xcdrwrap have no suid bit and thus is useless. That's the point: To make the wrapper useless, since it is not needed (on modern systems) and just an unnecessary security risk. If called as a user, one gets a confusing message about non-root-mode not being available, but it seems that one can burn CDs anyway. > Whenever user patches should be applied before or after ebuild-driven > modifications is a matter of preference, nothing more. User patches should be applied as late as possible so that users can undo all ebuild's changes if they want to. This is also the reason why the PATCHES are applied before eapply_user in "default". > What is the point of adding EPREFIX support? Having ERPREFIX support ;) e.g. to make it possible that a non-root user compiles a binary at home and can then install it on his universities debian system for which he hasn't root access. But you are right, I should have tested better: >+ emake PREFIX="${EPREFIX}"/usr DESTDIR="${ED}" install > > This is going to get package installed with double EPREFIX. If you use > EPREFIX, don't use ED. Unfortunately, DESTDIR=$D would install /etc and manpages into /. And emake PREFIX=/usr DESTDIR="$ED" install would collide with the previous make command. That's why I had expected that the above would work, but I hadn't tested. It seems that the build system is too broken to support EPREFIX easily.
(In reply to Martin Väth from comment #26) > > Whenever user patches should be applied before or after ebuild-driven > > modifications is a matter of preference, nothing more. > > User patches should be applied as late as possible so that users can undo > all ebuild's changes if they want to. This is also the reason why the > PATCHES are applied before eapply_user in "default". I see litle point to apply user patches after po fixes. I peeked in other EAPI=6 ebuilds, (almost) all of them call default at the beginnig of src_prepare(), so this is a common practice. Anyway, let us don't mix multiple issues in a single bug. I've taken this package for now, so please feel free to open new bugs for other issues if any. If you want prefix support, please file a keywordreq bug with patches required to implement this. And if by any chance you are willing to fix paths in this package, please also see at bug 285197. Your suggestion for USE=suid is applied in xcdroast-0.98_alpha16-r3 as well as other fixes. @security team, since this package is maintained now and fixed starting from -r2, I updated package.mask to affect older versions only, and removing PMASK/removal from this bug.
Arch teams, please stabilize =xcdroast-0.98_alpha16-r3.
amd64 stable
=app-cdr/xcdroast-0.98_alpha16-r2 has also this issue fixes, though it is no longer in the tree. So I'm updating the summary.
I tested -r3 yesterday and successfully wrote an ISO of data + image files, so it remains a useful app for my purposes. I noticed that 'verify' doesn't work -- not the result of -r3 fixes -- : it doesn't recognise the CD in the drive. It used to work perfectly. This in not important, but if anyone else can confirm it and if anyone cares to look into it, it might be fixed too. Thanks again to all who helped.
Philip, could you please open a separate bug for this issue? And please provide there output of $ emerge --info app-cdr/cdrtools app-cdr/xcdroast Thanks. If I'll find a writable media somewhere, I'll try to test this issue as well.
x86 stable
sparc stable
ppc stable. Maintainer(s), please cleanup.
Vulnerable version removed.
Because there is no attributable vulnerability here and it is purely a policy/best practice fix I am closing this.
