Bugzilla Bug 223017

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 an attachment (id=153971) [details]
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.