| Summary: | app-cdr/{cdrtools|cdrecord-prodvd?): tmpfile vuln with DEBUG active | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Thierry Carrez (RETIRED) <koon> |
| Component: | Default Configs | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | pylon |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://bugs.debian.org/291376 | ||
| Whiteboard: | [done] jaervosz | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 90211 | ||
| Bug Blocks: | |||
|
Description
Thierry Carrez (RETIRED)
2005-03-25 06:02:01 UTC
From Ubuntu USN-100-1 : ====================== Javier Fernández-Sanguino Peña noticed that cdrecord created temporary files in an insecure manner if DEBUG was enabled in /etc/cdrecord/rscsi. If the default value was used (which stored the debug output file in /tmp), this could allow a symbolic link attack to create or overwrite arbitrary files with the privileges of the user invoking cdrecord. Please note that DEBUG is not enabled by default in Ubuntu, so if you did not explicitly enable it, this does not affect you. ====================== Lars please advise. The /etc/defaults/rsci get installed with the following lines about DEBUG: # The file where debug info should go to. # If you don't like debugging (e.g. for speed) comment out # the this line. # #DEBUG=/tmp/RSCSI So, we are not affected by that bug. But we should inform the users about it. I guess there are only a few users who still use the cdrtool's rscsi abilities. Patching the config-file with a warning should help in that case. Proposed text: "Enabling DEBUG is a security risc! It could allow a symbolic link attack to create or overwrite arbitrary files with the privileges of the user invoking cdrecord." Agreed, the risk should just be documented. Switching to "Default Configs". Pylon, your text looks fine to me (maybe s/risc/risk/ ?) Pylon, you should revbump the ebuild with the proposed warning text. I think that text is a little harsh, it isnt a security risk so long as you dont set it to output in a world writable directory, something like "Set this to a safe place to write output, such as your home directory" Pylon: let us know when we can close this one Pylon is this ready to be closed now? Sorry for the long delay. All versions of cdrtools are patched, but I didn't bumped the versions. Pylon, unless there is good reason please bump the affected packages. Do we want users to recompile a complete application for one further notification line in a config-file that >99% of users will never touch? I think users should have the chance to pick it up, if they don't want to recompile for a small configuration update nobody forces them to do it. But if it's not bumped, users won't notice anything changed. Version bumped. You can close this bug now. Thanks Lars. alpha, mips, ppc64 : please test and mark cdrtools-2.01-r3 stable so that users pick up the security improvement while normally upgrading. ppc-macos : please mark cdrtools-2.01-r3 ~ppc-macos if you can. I cannot mark stable (or even testing) on ppc64 as bug #90211 is not yet fixed. (In reply to comment #13) > alpha, mips, ppc64 : please test and mark cdrtools-2.01-r3 stable so that users > pick up the security improvement while normally upgrading. > > ppc-macos : please mark cdrtools-2.01-r3 ~ppc-macos if you can. cdrtools-2.01-r1 is the previous cdrtools-2.01 and cdrtools-2.01-r3 the previous cdrtools-2.01-r2. I had to do it this way due to Bug #90211 as corsair already stated. But you are right that the goal is to use one version of cdrtools on every platform, as some other applications like gnome-2.10 need the -r3 version (utf8-fix). Ah OK, then no more stable is needed, closing. |