Quoting Adam Zabrocki: It is possible to overflow buffor on stack in suid program - mtr. Remote attack is possible too. Bug is in function which print result of runing program with parametr 'split' (-p). Victim must use DNS which we can control or we can try exploit this vulnerability by spoofing technique. In remote exploiting this vulnerability we must know which IP user gave to program - or he must simply run program and argument must be IP adres which we can controle in DNS server.
We install the program with following privileges: # ls -la /usr/bin/mtr -rws--x--- 1 root wheel 75328 21. Mai 03:59 /usr/bin/mtr
CVE-2008-2357: Stack-based buffer overflow in the split_redraw function in split.c in mtr before 0.73, when invoked with the -p (aka --split) option, allows remote attackers to execute arbitrary code via a crafted DNS PTR record. NOTE: it could be argued that this is a vulnerability in the ns_name_ntop function in resolv/ns_name.c in glibc and the proper fix should be in glibc; if so, then this should not be treated as a vulnerability in mtr.
This issue is fixed in mtr 0.73. Still, a lot of sprintf's are used in the code. For the future, it should be worthwhile to get this patch in there and upstream: http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/mtr/F-7/mtr-0.69-CVE-2002-0497.patch?rev=1.1
Created attachment 153971 [details, diff] mtr-0.73-remove-sprintf.patch Removed the hunk that is included in the release, and refreshed.
patch added in mtr-0.73-r1.ebuild. Thank you Robert for bug/patch digging!
Arches, please test and mark stable: =net-analyzer/mtr-0.73-r1 Target keywords : "alpha amd64 arm hppa ia64 ppc release s390 sh sparc x86"
I'm having fetch problems here for gtk-2.0-for-mtr.m4.bz2. On top of that, the Manifest doesn't agree with the /space/distfiles-local version. The file doesn't seem to have hit mirrors yet, perhaps because of the Manifest problem.
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-analyzer/mtr/Manifest?rev=1.96&view=markup DIST gtk-2.0-for-mtr.m4.bz2 2508 RMD160 f5fc7a3a3c4fcfe03356170371113a1b0f18eda6 SHA1 c72993fdb224ffba6afeca43a60303ed0350c56f SHA256 59152f9a4a1af5cf09f2aaa804c9071afe3eb6632162f1660d85c820db342eba pva@woodpecker ~ $ gpg --print-mds /space/distfiles-local/gtk-2.0-for-mtr.m4.bz2 | egrep 'SHA1|RMD160|SHA256' SHA1 = C729 93FD B224 FFBA 6AFE CA43 A603 03ED 0350 C56F RMD160 = F5FC 7A3A 3C4F CFE0 3356 1703 7111 3A1B 0F18 EDA6 SHA256 = 59152F9A 4A1AF5CF 09F2AAA8 04C9071A FE3EB663 2162F166 0D85C820 DB342EBA They are equal as I see... Thus strange. Does anybody else have fetch problem?
No problems here.
chown: cannot access `/var/tmp/portage/net-analyzer/mtr-0.73-r1/image//usr/bin/mtr': No such file or directory chmod: cannot access `/var/tmp/portage/net-analyzer/mtr-0.73-r1/image//usr/bin/mtr': No such file or directory >>> Completed installing mtr-0.73-r1 into /var/tmp/portage/net-analyzer/mtr-0.73-r1/image/ the binary is located in /usr/sbin/mtr.
Markus as always attentive. Thank you, fixed in 0.73-r2.
(In reply to comment #11) > Markus as always attentive. Thank you, fixed in 0.73-r2. thanks :) btw adding ``|| die'' for such things can also be useful... amd64/x86 stable
alpha/ia64/sparc stable
I was probably trying to fetch it too early. It's fine now. Stable for HPPA.
ppc stable
GLSA request filed.
(In reply to comment #10) > the binary is located in /usr/sbin/mtr. Only because the code to put it into /usr/bin was removed in 0.73-r1 for some mysterious reason. Worse, it's not even executable by wheel users anymore. (/usr/bin was intentional, see #6521).
(In reply to comment #17) > Only because the code to put it into /usr/bin was removed in 0.73-r1 for some > mysterious reason. Worse, it's not even executable by wheel users anymore. > (/usr/bin was intentional, see #6521). Wheel group is 'su -' allowed group. How it's related to networking stuff? Speaking about path, I suppose it was set at times mtr had o+rx permissions. Now it better fits /usr/sbin as ordinary users are not allowed to run this binary while users in wheel or root group should have sbin binaries in PATH (and that's what upstream has in mind, btw) as they are administrators and should either use that binaries or use full path! That said, after reading SECURITY file in distribution, may be we could revert back mode to 4711, to allow ordinary users run this binary? But... The problem here is a bit broader than mtr package... It's about how should we allow ordinary users to run networking applications which require root privileges to run. Should we create per package group and allow only users in that groups to run binaries with user ID execution bit set? Should we use wheel group for this (I'd better not)? Or may be we should allow ordinary users run such applications in case upstream supported that by dropping privileges (like in case of mtr)? Any suggestions from security team are more than welcome.
Fixed in release snapshot.
GLSA 200806-01
Vaclav, /usr/sbin really is the best place for executables that have restricted execution access. This is unarguably the case for root, and I would argue also for wheel users. Peter, do you know exactly why one would not have a user execute MTR? What more than ping/traceroute can it do? About your point in privileged groups for network monitoring, I would agree to have a system group for this. While monitoring a network on a machine usually correlates to root access to the machine, wheel is not the right group for this. This is better discussed in a new bug or on the netmon group, and it would best be accompanied by documentation like a network management guide.
