######################################################### mondo-rescue insecure temporary file creation Vendor: http://www.mondorescue.org/ Advisory: http://www.zataz.net/adviso/mondo-rescue-09192005.txt Vendor informed: yes Exploit available: yes Impact : low Exploitation : low ######################################################### The vulnerabilities are due to insecure temporary files creation. They are symlink attacks to create arbitrary files with the privileges of the user running the affected script. ########## Versions: ########## mondo-rescue <= 1.65 ########## Solution: ########## ######### Timeline: ######### Discovered : 2005-09-19 Vendor notified : Vendor response : Vendor fix : Vendor Sec report (vendor-sec@lst.de) : Disclosure : ##################### Technical details : ##################### Vulnerable code : ----------------- Take a look on the installed script (Gentoo distro) * /usr/share/mondo/restore-scripts/mondo/hack-lilo 4 LogIt() { 5 echo "$1" >> /tmp/mondo-restore.log 6 } 116 LogIt "hack-lilo --- starting" 142 LogIt "hack-lilo --- leaving" This script is world executable * A lot off unused script are installed into /usr/share/mondo/restore-scripts/mondo/ The LogIt function is not declared into this scripts. All this scripts should be removed. ######### Related : ######### Bug report : CVE : ##################### Credits : ##################### Eric Romang (eromang@zataz.net - ZATAZ Audit) - Gentoo Security Scout Thxs to Gentoo Security Team.
tigger/taviso/vapier/solar please advise.
why dont we ask the maintainer :)
Please advise.
CC'ing Wolfram instead of group which doesn't play well with restricted bugs. Please advise.
Well, since I had really bad experiences dealing with the Mondo developer regarding some weird problems, I stopped using it, as well as caring for the ebuilds. Also the stuff hasn't been updated for a year now (except some CVS snapshots from 05/2005) -- see http://www.mondorescue.org/download/MondoCD/TGZS/ anyway, as to the vulnerability, I guess we need to remove all Mondo 1.x versions from the tree. also, those older versions aren't listed on the Mondo website anymore and the SRC_URI in the 1.x ebuilds doesn't work either :(
Thx for the info, Wolfram. If possible please CC another possible maintainer from app-backup herd.
metadata.xml lists Jay Pfeifer, CCing... Jay, please have a look at this :-)
i certainly did help with these a while back and have been named as a maintainer. but just like Wolfram, upstream is not a lot of fun. I would be all for removing 1.x and 2.x as I don't see it being easily supported in the future. Plus they seem to be dead upstream. I get tired of the upstream using the same file name for new revisions (ie. making several 2.1.0 versions and telling no one).
I agree with Jay here -- let's have it removed (maybe until upstream changes the behaviour).
Package.mask notice sent to -core.
No new maintainer. Wolfram/Jay please mask.
When masking app-backup/mondo-rescue, does it make sense to keep app-backup/mindi and app-backup/mindi-kernel? I believe those are only used by mondo-rescue...
app-backup/mondo-rescue masked.
Hello, Vendor notified and vendor-sec also. Regards.
Keeping this bug open until the package is completely removed.
Jay and Wolfram any reason to keep mondo-rescue any longer?
Any news on this one?
Ok, we have a reason to keep and unmask it: Upstream has a new maintainer: Bruno Cornec. He just sent me a mail stating he is willing to produce mondo and mindi packages for Gentoo and to care about all issues. That sounds good to me, as there seems to be someone actually caring about the project. Comments?
Wolfram if you want to maintain it or has found a maintainer for it. Feel free to unmask it once the outstanding issues are fixed.
This bug should not be restricted.
So with the new upstream developer how does this stand? I'm just coming into the app-backup herd and trying to sort some bugs (namely bug 79262). http://www.zataz.net/adviso/mondo-rescue-09192005.txt is offline. What exactly does this effect? mondo-rescue-1.47? (That is the only one <=1.6) 2.x series?
Hello, I've produced 2.0.8-3 (upstream version recently). I have a gento qemu VM running. But I still had not enough time to play with it, understand how to test my preliminary e-build script, ... Of course, now everything is under SVN, so if some of you are wanting to have a look, that would be great :-) Anyway, I'm working on producing ebuilds asap, but I'm quite busy on various topics right now, so don't expect it for tomorrow :-( Also, the security issues I've seen reported here, are not yet fixed. I'm interested to fix them, so again will do as time permits. Patches welcome ;-) Thanks for you rpatience on this. Bruno.
Hello, I've just published a new version of mondo/mindi which fixes some bugs, and could begin to provide solutions for gentoo issues reported here. I've also tried to work on a ebuild version updated, which I attach here for comment. Let me know how to procede now.
This script is not world writable anymore in the latest 2.0.9 version. Please refer to ftp://ftp.mondorescue.org/gentoo/1.6 for ebuild files and packges built with them which correct this bug.
This bug should now be closed and a new version of mondo and mindi should be added from upstream (which I maintain) using the latest 2.2.0 (mondo) and 1.2.0 (mindi) available from ftp://ftp.mondorescue.org/gentoo/1.6 I will shortly add the new required mindi-busybox package as well there.
*** Bug 155092 has been marked as a duplicate of this bug. ***
I haven't tried a restore yet, but I was able to successfully create a pair of backup DVDs with the latest version of mondo and mindi (2.2.0 and 1.2.0) on an amd64 dual-core system. Ignore mindi-kernel, and use the command switch '-k /boot/kernel-2.6.17-gentoo-r8', replacing the kernel path with whatever kernel you're actually booting from. I had to mess around a little with the ebuild files to get it to build (though only to correct a couple of minor differences between file naming conventions). Looks like it is ready to add back into portage. Jeff
A newer version (2.2.1) with ebuild packages is available at ftp://ftp.mondorescue.org/gentoo/1.6 Please provide feedback and info for return back in gentoo's tree.
@Bruno, you might want to post to gentoo-dev to find a maintainer for this package. Unless one is found it will stay masked.
I thought that the package already had a maintainer. If it's not the case, I'll post to gentoo-dev. Thanks for the advise.
According to metadata.xml pfeifer@gentoo.org is primary maintainer and wschlich@gentoo.org secondary. Both are CC'ed on this bug as is the app-backup herd, so let's see wether they respond. We need an active maintainer to unmask this one.
What's the status on mondo-rescue? Why is it still hard masked? Looks to me it's time to return it back in Gentoo's tree.Bruno has posted his version 4 months ago!
It's seems the problem is that there is no maintainer anymore for it in gentoo. I can publish myself ebuilds, if I can find someone to tst them and report. A new version is available since last friday, and has even some updates for the ebuild. Let me know how to proceed.
(In reply to comment #33) > It's seems the problem is that there is no maintainer anymore for it in gentoo. > I can publish myself ebuilds, if I can find someone to tst them and report. A > new version is available since last friday, and has even some updates for the > ebuild. > Let me know how to proceed. > First off all thank you for your patience and persistence. I suspect the problem is lack of manpower on the Gentoo side. I think it is best to attach your ebuild to this bugreport so we can test the ebuild.
Source available at: ftp://ftp.mondorescue.org/gentoo/1.6/mindi-1.2.2.ebuild ftp://ftp.mondorescue.org/gentoo/1.6/mindi-1.2.2.tbz2 ftp://ftp.mondorescue.org/gentoo/1.6/mindi-busybox-1.2.2.ebuild ftp://ftp.mondorescue.org/gentoo/1.6/mindi-busybox-1.2.2.tbz2 ftp://ftp.mondorescue.org/gentoo/1.6/mondo-2.2.2.ebuild ftp://ftp.mondorescue.org/gentoo/1.6/mondo-2.2.2.tbz2
Thanks Bruno. I will test them asap.What do you think about posting a 'maintainer wanted' message to gentoo-dev list?
Or you could file a new bug assigned to maintainer-wanted and reference this bug.
Is that what you meant: http://bugs.gentoo.org/show_bug.cgi?id=176738 (I was unable to assign to maintainer-wanted, so I put them in Cc: Hope that's ok)
How are things going here? Have you found a maintainer?
Well on the mailing I have a gentoo tester of the x86_64 version who has some issues we're resolving right now. As soon as it's OK, I think he will come back for a formal request. I don't know what is the rule for gentoo my self, but I can provide updates of packages with upstream updates, I have the process in place to do that easily. Just let me know how to propagatethem then to gentoo upstream. Best regards, Bruno.
Good to hear thing are moving forward :). I don't know the answers to your question (I am not a Gentoo dev). Thanks for your input!
Hi people, it's me. We are testing mindi and mondo on 64 bit arch. I'd like to make our work public in order to find someone else help too. Maybe mindi an mondo related bus are today a little messy and outdated. IMHO it's time to close all bugs depending on surpassed versions, leave one only report open to make public work progression.
When will this bug be solved? New mondo ebuild are available for a while now: ftp://ftp.mondorescue.org/gentoo
# Wolfram Schlich <wschlich@gentoo.org> (26 Nov 2005) # has security issues and will be removed from portage # due to upstream behaviour, see bug #106497 app-backup/mondo-rescue Enough is enough. Treecleaners, please remove this. Masked for over two years.
I think it would be interesting you wait a couple of days more as Wolfram accepted to work on this as mentioned in http://bugs.gentoo.org/show_bug.cgi?id=176738
(In reply to comment #45) > I think it would be interesting you wait a couple of days more as Wolfram > accepted to work on this as mentioned in > http://bugs.gentoo.org/show_bug.cgi?id=176738 I've seen this so many times with mondo-rescue that I don't take it very seriously, frankly. Unless it's in usable state by the end of February, it *really* should be just wiped, once and for all. The current ebuilds are useless bitrot.
I'd like to point out that mondo-rescue completely fails with slang-2 which is the default slang in ~arch now, going stable in about 30 days
Could you elaborate more on what you mean by "completely fails" ? Any log ? As for "The current ebuilds are useless bitrot", I'd like to have more info on why and how to improve them from your point of view.
I've been actively trying to get in touch with Bruno Cornec since 2008-02-18 to sort out some questions I have regarding the mondo/mindi ebuilds he provided -- I need answers until I can add anything to Portage. Unfortunately, this was unsuccessful so far, but I keep trying. Just wanted to post a status update for Jakub who will probably remove the packages in 5 days.
(In reply to comment #48) > Could you elaborate more on what you mean by "completely fails" ? > Any log ? As in the tarballs for the current ebuilds *in* *the* *tree* are garbage that doesn't even unpack properly. Unusable. (In reply to comment #49) Well, I'm just pointing out that this thing has been dragging for quite some time, it's been masked for over two years... so it'd really be nice to resolve this fast and push something usable into the tree, or get rid of the package once and for all.
(In reply to comment #48) > Could you elaborate more on what you mean by "completely fails" ? Means it's not compatible with API/ABI provided by >=slang-2 and it fails to build due to invalid or missing code > Any log ? Had one, but didn't save it because this one is package.masked & getting removed..
(In reply to comment #50) > (In reply to comment #48) > > Could you elaborate more on what you mean by "completely fails" ? > > Any log ? > > As in the tarballs for the current ebuilds *in* *the* *tree* are garbage that > doesn't even unpack properly. Unusable. > > (In reply to comment #49) > > Well, I'm just pointing out that this thing has been dragging for quite some > time, it's been masked for over two years... so it'd really be nice to resolve > this fast and push something usable into the tree, or get rid of the package > once and for all. So, I tried to contact Bruno more than once again. Nothing more than a 'Yes' via Jabber tonight. I'm not very happy with the situation. If this keeps on going like this, I don't see a point in proxy-maintaining stuff for someone how doesn't respond. But I'd like to give it 2 more weeks. Jakub, if nothing happens until 23rd of March, go on with the removal. Thanks!
Can we last-rite this now already? This will give the non-responsive maintainer another four weeks to push an update, otherwise have it removed in april.
(In reply to comment #52) > (In reply to comment #50) > > (In reply to comment #48) > > > Could you elaborate more on what you mean by "completely fails" ? > > > Any log ? > > > > As in the tarballs for the current ebuilds *in* *the* *tree* are garbage that > > doesn't even unpack properly. Unusable. > > > > (In reply to comment #49) > > > > Well, I'm just pointing out that this thing has been dragging for quite some > > time, it's been masked for over two years... so it'd really be nice to resolve > > this fast and push something usable into the tree, or get rid of the package > > once and for all. > > So, I tried to contact Bruno more than once again. > Nothing more than a 'Yes' via Jabber tonight. > I'm not very happy with the situation. > If this keeps on going like this, I don't see a point in > proxy-maintaining stuff for someone how doesn't respond. > But I'd like to give it 2 more weeks. > Jakub, if nothing happens until 23rd of March, go on with the removal. > Thanks! > Well I'm sorry, I'm not in front of my computer every minute to tal via jabber. I'm a mail person. And I copied my responses to your jabber questions via e-mail, hope you got them. I'm also a bit concerned that people speak about "garbage", "completely fails". Hey guys, this is a science here. I need logfiles, log reports, comands passed, ... I'm ready to integrate what you want, but be precise please. Latest ebuild is here: ftp://ftp.mondorescue.org/gentoo/nover/test
The latest version in tree, 2.10, fails like this: >>> Unpacking source... >>> Unpacking mondo-2.10.tgz to /var/tmp/portage/app-backup/mondo-rescue-2.10/work gzip: stdin: decompression OK, trailing garbage ignored tar: Child returned status 2 tar: Error exit delayed from previous errors * * ERROR: app-backup/mondo-rescue-2.10 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 527: Called unpack 'src_unpack' * ebuild.sh, line 337: Called die * The specific snippet of code: * tar xozf "${srcdir}${x}" ${tar_opts} || die "$myfail" * The die message: * failure unpacking mondo-2.10.tgz This is with a freshly downloaded mondo-2.10.tgz.
2.10 IS NOT the version to look at: It's obsolete and completely abandonned. Please look at 2.2.5: ftp://ftp.mondorescue.org/gentoo/nover/test And read that thread.
I just wanted to clarify why Jakub was using terms like 'garbage' and 'completely fails' in relation to the ebuilds in the Gentoo tree, since you asked for the evidence of this. I'd also like to point out that generally version 2.10 is considered to be newer than 2.2.5, and this may have added to the confusion that caused delays in updating the ebuilds in portage. In any case, now that things are more clear, the next step seems to be for Wolfram to test the 2.2.5 ebuild and include it in the tree.
(In reply to comment #57) > In any case, now that things are more clear, the next step seems to be for > Wolfram to test the 2.2.5 ebuild and include it in the tree. > New 2.2.8 version released in Feb [1]. [1] http://freshmeat.net/projects/mondorescue/
(In reply to comment #58) > (In reply to comment #57) > > In any case, now that things are more clear, the next step seems to be for > > Wolfram to test the 2.2.5 ebuild and include it in the tree. > > > New 2.2.8 version released in Feb [1]. > [1] http://freshmeat.net/projects/mondorescue/ And I continue to provide ebuilds available at ftp://ftp.mondorescue.org/gentoo/nover/
Please note that it should be named "mondo-rescue-2.2.8.ebuild" to avoid clash with another program (sys-apps/mondo). Anyway it is working well in my amd64 Portage 2.1.6.7 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.8_p20080602-r1, 2.6.29-gentoo-r1 x86_64)
(In reply to comment #60) > Please note that it should be named "mondo-rescue-2.2.8.ebuild" > to avoid clash with another program (sys-apps/mondo). In fact it's named mondo-rescue.ebuild which then redirects to the right content. Is it ok like that ? > Anyway it is working well in my amd64 > Portage 2.1.6.7 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.8_p20080602-r1, 2.6.29-gentoo-r1 x86_64) Good to know ! Any way to reactivate now in gentoo ?
Yeah! reactivate!
As far as I am concerned, not before you fix the handling of temporary files in there. The tool heavily relies on usage of the /tmp directory for both creation and recovery of the system. Recovery is not a problem, since this is usually done on single-user systems such as a live cd. However, handling temporary files insecurely when creating regular backups is not an option. This issue is not nearly resolved in the latest version. Just do a grep and see for yourself.
(In reply to comment #63) > As far as I am concerned, not before you fix the handling of temporary files in there. The tool heavily relies on usage of the /tmp directory for both creation and recovery of the system. Recovery is not a problem, since this is usually done on single-user systems such as a live cd. However, handling temporary files insecurely when creating regular backups is not an option. I agree, but don't see what still need to be done here. there was a Debian bug aroud that, that I fixed long ago, and now people always seem to think there is an issue, where IMO there is no. > This issue is not nearly resolved in the latest version. Just do a grep and see for yourself. Well could you be a bit more precise ? I did that myself, and the /tmp reference I see are either for restore or below it another dir with the PID is created. I found one for parted2fdisk which indeed cause problem that I'll fix in SVN ASAP. I may have miss some other when I fixed it globally, but again, I'd like to have precise points to look at rather than just the grep stuff (I do it myself but it's not providing the level of info you need - Is there a better tool BTW ?)
(In reply to comment #64) > I agree, but don't see what still need to be done here. there was a Debian bug > aroud that, that I fixed long ago, and now people always seem to think there is > an issue, where IMO there is no. I downloaded mondo-rescue-latest.tar.gz and looked at the source. ./mondo-rescue-2.2.7$ find src/ -type f -print0 | xargs -0 grep -A2 'LogIt()' src/restore-scripts/mondo/format-and-kludge-vfat:LogIt() { src/restore-scripts/mondo/format-and-kludge-vfat- echo "$1" >> /dev/stderr src/restore-scripts/mondo/format-and-kludge-vfat-} -- src/restore-scripts/mondo/hack-fstab:LogIt() { src/restore-scripts/mondo/hack-fstab- echo "$1" >> /dev/stderr src/restore-scripts/mondo/hack-fstab-} So the LogIt() function is defined in those two files. However, it's also used elsewhere, where it is not declared: ./mondo-rescue-2.2.7$ find src/ -type f -print0 | xargs -0 grep 'LogIt' \ > | grep -v 'format-and-kludge-vfat' | grep -v 'hack-fstab' \ > | wc -l 166 I believe this is what Eric Romang was referring to originally when he said: (In reply to comment #0) > The LogIt function is not declared into this scripts. > All this scripts should be removed. I may be wrong, as the original advisory is no longer up and I've only just begun to look at this bug, but I will look into it further and maybe come up with a patch.
(In reply to comment #65) > I downloaded mondo-rescue-latest.tar.gz and looked at the source. > > ./mondo-rescue-2.2.7$ find src/ -type f -print0 | xargs -0 grep -A2 'LogIt()' > src/restore-scripts/mondo/format-and-kludge-vfat:LogIt() { > src/restore-scripts/mondo/format-and-kludge-vfat- echo "$1" >> /dev/stderr > src/restore-scripts/mondo/format-and-kludge-vfat-} > -- > src/restore-scripts/mondo/hack-fstab:LogIt() { > src/restore-scripts/mondo/hack-fstab- echo "$1" >> /dev/stderr > src/restore-scripts/mondo/hack-fstab-} > > So the LogIt() function is defined in those two files. However, it's also used > elsewhere, where it is not declared: > > ./mondo-rescue-2.2.7$ find src/ -type f -print0 | xargs -0 grep 'LogIt' \ > > | grep -v 'format-and-kludge-vfat' | grep -v 'hack-fstab' \ > > | wc -l > 166 You're not looking at the right place as this function *is* declared in mindi: 113 victoria2.home.musique-ancienne.org-bruno ~/mondo/svn/branches/2.2.9 > find . -name LogIt ./mindi/rootfs/sbin/LogIt > I believe this is what Eric Romang was referring to originally when he said: > (In reply to comment #0) > > The LogIt function is not declared into this scripts. > > All this scripts should be removed. That's why I continue to believe this is wrong, and that it should go on. > > I may be wrong, as the original advisory is no longer up and I've only just > begun to look at this bug, but I will look into it further and maybe come up > with a patch. > No patch needed.
Adding treecleaners back. Masked since 13 Mar 2008. No progress has been made. app-backup/mondo-rescue sys-apps/mindi sys-apps/mindi-busybox
Removed from tree.
