Bug 475469 - (CVE-2008-5373) CVE-2008-5373 bacula-common: Insecure temporary file use in autochangers (symlink attack)
CVE-2008-5373 bacula-common: Insecure temporary file use in autochangers (sym...
Status: CLOSED CURRENTRELEASE
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20080811,reported=2...
: Security
Depends On: 665498
Blocks: 841601
  Show dependency treegraph
 
Reported: 2008-12-09 07:03 EST by Jan Lieskovsky
Modified: 2013-02-13 11:55 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-04 07:55:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch for automounters examples (9.16 KB, patch)
2011-10-07 06:57 EDT, Lukáš Nykrýn
no flags Details | Diff
Patch for automounters examples (11.20 KB, patch)
2011-10-24 08:52 EDT, Lukáš Nykrýn
no flags Details | Diff

  None (edit)
Description Jan Lieskovsky 2008-12-09 07:03:38 EST
Common Vulnerabilities and Exposures assigned an identifier CVE-2008-5373 to
the following vulnerability:

mtx-changer.Adic-Scalar-24 in bacula-common 2.4.2 allows local users
to overwrite arbitrary files via a symlink attack on a /tmp/mtx.#####
temporary file, probably a related issue to CVE-2005-2995.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5373
ttp://lists.debian.org/debian-devel/2008/08/msg00347.html
http://uvw.ru/report.sid.txt

Affected files in Fedora's bacula-common package:
/usr/share/doc/bacula-common-2.0.3/examples/autochangers/locking-mtx-changer
/usr/share/doc/bacula-common-2.0.3/examples/autochangers/mtx-changer.Adic-Scalar-100
/usr/share/doc/bacula-common-2.0.3/examples/autochangers/mtx-changer.Adic-Scalar-24
/usr/share/doc/bacula-common-2.0.3/examples/autochangers/mtx-changer.StorageTek-HPA4853
/usr/share/doc/bacula-common-2.0.3/examples/autochangers/solaris-mtx-changer

Sample affected code:

143    loaded)
144       ${MTX} -f $ctl status >/tmp/mtx.$$
145       rtn=$?
146       cat /tmp/mtx.$$ | grep "^Data Transfer Element $drive:Full" | awk "{print \$7}"
147       cat /tmp/mtx.$$ | grep "^Data Transfer Element $drive:Empty" | awk "{print 0}"
148       rm -f /tmp/mtx.$$

Problem: A malicious user could pre-create a symlink with target to any
system file. Running some of the above example autochangers would truncate
the content of this file.

If these files does not needed to be shipped within the bacula-common 
package, remove them, or apply fix via 'mktemp'.
Comment 1 Jan Lieskovsky 2008-12-09 07:06:35 EST
This issue affects the versions of the bacula-common package, as
shipped with Fedora releases of 8, 9 and 10.

This issue affects the version of the bacula-common package, as
shipped with Extra Packages for Enterprise Linux 5 (EPEL 5) project.

Please update.
Comment 2 Jon Ciesla 2008-12-09 09:38:11 EST
locking-mtx-changer contains a comment that it's no longer needed.  Since they're just examples, I have no problem dropping them.  It'd be a relatively easy fix, as well.

Andreas, do you have a preference?
Comment 3 Vincent Danen 2009-06-26 05:32:39 EDT
This has been open for over 6 months.  Is there something that we can do to help deal with this issue so it can get resolved?
Comment 4 Vincent Danen 2009-08-27 12:47:33 EDT
Ping?  Making this use mktemp should be extremely straightforward, and this bug is 9mos old.
Comment 5 Jon Ciesla 2009-08-28 08:23:52 EDT
Still waiting on an answer from Andreas.  I'm a co-maintainer, but if we don't hear soon, I'd be willing to make the change myself.
Comment 6 Vincent Danen 2010-12-23 22:44:42 EST
This still has not been addressed in curent bacula.  The example scripts are still in the package and still unfixed.  I know this is pretty lame issue, but bacula has gone from version 2.4.3 to 5.0.3 and has had numerous builds and fixes since this was initially brought up.

I'm going to file a tracker for this as I suspect the reason this isn't getting picked up is that it's not on anyone's radar of open bacula bugs.
Comment 7 Vincent Danen 2010-12-23 22:45:38 EST
Created bacula tracking bugs for this issue

Affects: fedora-all [bug 665498]
Comment 8 Lukáš Nykrýn 2011-10-07 06:57:00 EDT
Created attachment 526863 [details]
Patch for automounters examples

I have prepared patch file which should correct this issue in all affected files. Because it is quite impossible to test them I would appreciate if somebody can do some quick sanity check.
Comment 9 Tomas Hoger 2011-10-07 07:17:13 EDT
I had a quick look at the attached patch, but not into scripts themselves.  I noticed following:

- mtx-changer.StorageTek-HPA4853 seems to use temp file before it's mktemp created

- mtx-changer.StorageTek-HPA4853 also has:
  cat $tempfile | grep "^Data Transfer Element 0:Full" | awk "{print \$7}" > /tmp/mtxloaded
Writing to /tmp/mtxloaded sound quite as bad as /tmp/mtx.$$.

- I wonder if it's not easier to just:
  mtxoutput=`${MTX} -f ${CHANGER} status -S`
and avoid temp file completely.  Is the output expected to be quite long?
Comment 10 Lukáš Nykrýn 2011-10-24 08:52:15 EDT
Created attachment 529861 [details]
Patch for automounters examples

Previous patch was rejected from upstream, because it can't be used on systems without mktemp, so they suggested me to write this similary to src/scripts/mtx-changer.in. 

I believe that writing in /tmp/mtxloaded is not the same issue, because this file is deleted before (maybe this is the second possible way how to fix this).
Comment 11 Tomas Hoger 2011-11-07 06:22:30 EST
(In reply to comment #10)
> Previous patch was rejected from upstream, because it can't be used on systems
> without mktemp, so they suggested me to write this similary to
> src/scripts/mtx-changer.in.

make_temp_file() is racy on systems without mktemp, and seems wrong for couple of other reasons.  First, on systems that do have mktemp, I think it should never fall back to using unsafe temp file.  If mktemp can't make safe temp file, the script is even less likely to be able to do it.  As for the unsafe code path, you can still race against the check (create /tmp/mtx.$$ after test, but before the script writes to it), or overwrite device files with no race (think of mtx.$$ being symlink to e.g. /dev/sda).

> I believe that writing in /tmp/mtxloaded is not the same issue, because this
> file is deleted before (maybe this is the second possible way how to fix this).

It's different in a way that an attacker needs to race against the script and create malicious symlink between rm and re-creation of the file.  The way the file is created is still unsafe, and the race should not be all that hard to win.
Comment 12 Simone Caronni 2012-07-19 09:24:33 EDT
Hello,

I'm doing some housekeeping in Bacula bugs, can you confirm the problem is still relevant with the latest packages in one of el5, f16, f17 or rawhide?

I'm about to push an update into el5 that solves a couple of other bugs:

http://koji.fedoraproject.org/koji/buildinfo?buildID=333271

Thanks,
--Simone
Comment 13 Tomas Hoger 2012-07-19 10:02:01 EDT
(In reply to comment #12)
> I'm doing some housekeeping in Bacula bugs, can you confirm the problem is
> still relevant with the latest packages in one of el5, f16, f17 or rawhide?

You should be easily able to figure out using the info in comment #0.  AFIACS, those affected example files are in 2.4.4 (EPEL-5) and 5.0.3 (F16), but they are not in 5.2.10 (F17+) bacula-common any more (removed completely).

It seems they got removed as part of the 5.0 -> 5.2 upgrade:
http://pkgs.fedoraproject.org/gitweb/?p=bacula.git;a=commitdiff;h=16d9a36e02513f5ca105935ab8f70549b276dc70
Comment 14 Simone Caronni 2012-07-19 10:26:04 EDT
Thanks.

Patch has been applied upstream in 2011-10, between 5.2.0 and 5.2.1:

http://www.bacula.org/git/cgit.cgi/bacula/commit/?id=c7279c05680e0b443dda349af5b567d876a76ba2

I can do the following:

1) Apply the same patch to the el5 and fc16 packages and readd the examples in fc17
2) Delete the examples in the el5 and fc16 packages

I would go for option 2 as those examples are not really useful (as far as I know nobody uses them) and much confusing; plus as stated in comment #11 it should not be the full solution.

If nobody has objections I will proceed into removing the examples in el5 and fc16, the bug has been opened for 3,5 years now.

Thanks,
--Simone
Comment 15 Tomas Hoger 2012-07-19 11:06:38 EDT
(In reply to comment #14)
> Patch has been applied upstream in 2011-10, between 5.2.0 and 5.2.1:
> 
> http://www.bacula.org/git/cgit.cgi/bacula/commit/
> ?id=c7279c05680e0b443dda349af5b567d876a76ba2

That seems to be the same fix as attached above, with the issues pointed out in comment 11.

> I would go for option 2 as those examples are not really useful (as far as I
> know nobody uses them) and much confusing; plus as stated in comment #11 it
> should not be the full solution.

Removing them should be fine if they really are unused.  IIRC, some of them included custom paths to some binaries, so they may not work at all without modification.
Comment 16 Simone Caronni 2012-07-20 04:02:47 EDT
I've applied the required change to el5 and f16 packages; I will push an update in updates-testing soon. I will replace the update for el5 in updates-testing with this one.

I've checked also the other examples, some are really old and relevant to even older Bacula releases (1.3!) and exposing also features never implemented properly and dropped later (volumes on dvds, etc.).
Comment 17 Fedora Update System 2012-07-28 20:51:08 EDT
bacula-5.0.3-31.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2012-08-10 14:38:10 EDT
bacula-2.4.4-7.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 Simone Caronni 2012-09-04 07:55:23 EDT
Closing it, it was not automatically closed by the updates going into stable.
Comment 20 Stefan Cornelius 2013-02-12 04:46:50 EST
Some of the affected files are still shipped with Red Hat Enterprise Linux 6. However, they are only provided as example files with no guarantee for correctness and completeness. Users should only use examples after careful consideration and may have to take precautions relevant to their system and situation.

Statement:

The Red Hat Security Response Team has rated this issue as having low security impact. This issue is not currently planned to be addressed in Red Hat Enterprise Linux 6. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

Note You need to log in before you can comment on or make changes to this bug.