Bug 106497 - app-backup/mondo-rescue removal request
|
Bug#:
106497
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: zataz@zataz.net
|
|
Component: Auditing
|
|
|
URL:
|
|
Summary: app-backup/mondo-rescue removal request
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2005-09-19 03:23 0000
|
#########################################################
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 :)
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?
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.
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
@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.
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.
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.
# 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.
(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.
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.
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 ?
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
