First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 86649
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Security <security@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Thierry Carrez (RETIRED) <koon@gentoo.org>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:
Flags: Requestee:
 
 
  ()

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 86649 depends on: 90211 Show dependency tree
Show dependency graph
Bug 86649 blocks:

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2005-03-25 06:02 0000
From Ubuntu USN-100-1 :

======================
Javier Fern

------- Comment #1 From Thierry Carrez (RETIRED) 2005-03-25 06:02:01 0000 -------
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.
======================

------- Comment #2 From Sune Kloppenborg Jeppesen 2005-03-27 01:38:14 0000 -------
Lars please advise.

------- Comment #3 From Lars Weiler (RETIRED) 2005-03-29 15:02:18 0000 -------
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."

------- Comment #4 From Thierry Carrez (RETIRED) 2005-03-29 23:37:37 0000 -------
Agreed, the risk should just be documented. Switching to "Default Configs".
Pylon, your text looks fine to me (maybe s/risc/risk/ ?)

------- Comment #5 From Thierry Carrez (RETIRED) 2005-04-10 10:01:59 0000 -------
Pylon, you should revbump the ebuild with the proposed warning text.

------- Comment #6 From Tavis Ormandy (RETIRED) 2005-04-10 10:10:34 0000 -------
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"

------- Comment #7 From Thierry Carrez (RETIRED) 2005-04-21 07:08:15 0000 -------
Pylon: let us know when we can close this one

------- Comment #8 From Sune Kloppenborg Jeppesen 2005-05-02 22:57:38 0000 -------
Pylon is this ready to be closed now?

------- Comment #9 From Lars Weiler (RETIRED) 2005-05-07 11:39:01 0000 -------
Sorry for the long delay.

All versions of cdrtools are patched, but I didn't bumped the versions.

------- Comment #10 From Sune Kloppenborg Jeppesen 2005-05-08 00:15:00 0000 -------
Pylon, unless there is good reason please bump the affected packages.

------- Comment #11 From Lars Weiler (RETIRED) 2005-05-08 05:36:12 0000 -------
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?

------- Comment #12 From Sune Kloppenborg Jeppesen 2005-05-15 22:12:37 0000 -------
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.

------- Comment #13 From Lars Weiler (RETIRED) 2005-05-30 14:02:37 0000 -------
Version bumped.  You can close this bug now.

------- Comment #14 From Thierry Carrez (RETIRED) 2005-05-31 00:33:49 0000 -------
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.

------- Comment #15 From Markus Rothe 2005-05-31 00:39:47 0000 -------
I cannot mark stable (or even testing) on ppc64 as bug #90211 is not yet fixed.

------- Comment #16 From Lars Weiler (RETIRED) 2005-05-31 03:11:29 0000 -------
(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).

------- Comment #17 From Thierry Carrez (RETIRED) 2005-05-31 05:09:09 0000 -------
Ah OK, then no more stable is needed, closing.

First Last Prev Next    No search results available      Search page      Enter new bug