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'.
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.
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?
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?
Ping? Making this use mktemp should be extremely straightforward, and this bug is 9mos old.
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.
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.
Created bacula tracking bugs for this issue Affects: fedora-all [bug 665498]
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.
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?
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).
(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.
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
(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
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
(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.
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.).
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.
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.
Closing it, it was not automatically closed by the updates going into stable.
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/.