Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 223017 (CVE-2008-2357) - net-analyzer/mtr <0.73-r2 Stack-based buffer overflow (CVE-2008-2357)
Summary: net-analyzer/mtr <0.73-r2 Stack-based buffer overflow (CVE-2008-2357)
Status: RESOLVED FIXED
Alias: CVE-2008-2357
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Security
URL: http://seclists.org/fulldisclosure/20...
Whiteboard: C1 [glsa]
Keywords:
Depends on:
Blocks: 296413
  Show dependency tree
 
Reported: 2008-05-21 02:01 UTC by Robert Buchholz (RETIRED)
Modified: 2020-04-09 06:40 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
mtr-0.73-remove-sprintf.patch (mtr-0.73-remove-sprintf.patch,9.02 KB, patch)
2008-05-22 18:53 UTC, Robert Buchholz (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Buchholz (RETIRED) gentoo-dev 2008-05-21 02:01:39 UTC
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.
Comment 1 Robert Buchholz (RETIRED) gentoo-dev 2008-05-21 02:03:25 UTC
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
Comment 2 Robert Buchholz (RETIRED) gentoo-dev 2008-05-22 18:41:34 UTC
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.
Comment 3 Robert Buchholz (RETIRED) gentoo-dev 2008-05-22 18:52:33 UTC
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

Comment 4 Robert Buchholz (RETIRED) gentoo-dev 2008-05-22 18:53:54 UTC
Created attachment 153971 [details, diff]
mtr-0.73-remove-sprintf.patch

Removed the hunk that is included in the release, and refreshed.
Comment 5 Peter Volkov (RETIRED) gentoo-dev 2008-05-24 15:37:40 UTC
patch added in mtr-0.73-r1.ebuild. Thank you Robert for bug/patch digging!
Comment 6 Robert Buchholz (RETIRED) gentoo-dev 2008-05-24 15:59:11 UTC
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"
Comment 7 Jeroen Roovers gentoo-dev 2008-05-24 16:47:56 UTC
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.
Comment 8 Peter Volkov (RETIRED) gentoo-dev 2008-05-24 17:34:11 UTC
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?
Comment 9 Cédric Krier gentoo-dev 2008-05-24 17:38:18 UTC
No problems here.
Comment 10 Markus Meier gentoo-dev 2008-05-25 11:01:22 UTC
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.
Comment 11 Peter Volkov (RETIRED) gentoo-dev 2008-05-25 11:54:11 UTC
Markus as always attentive. Thank you, fixed in 0.73-r2.
Comment 12 Markus Meier gentoo-dev 2008-05-25 13:21:30 UTC
(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
Comment 13 Raúl Porcel (RETIRED) gentoo-dev 2008-05-25 15:53:39 UTC
alpha/ia64/sparc stable
Comment 14 Jeroen Roovers gentoo-dev 2008-05-25 16:44:59 UTC
I was probably trying to fetch it too early. It's fine now.

Stable for HPPA.
Comment 15 Tobias Scherbaum (RETIRED) gentoo-dev 2008-05-26 18:27:57 UTC
ppc stable
Comment 16 Tobias Heinlein (RETIRED) gentoo-dev 2008-05-26 19:29:23 UTC
GLSA request filed.
Comment 17 Vaclav Slavik 2008-05-26 23:14:52 UTC
(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).
Comment 18 Peter Volkov (RETIRED) gentoo-dev 2008-05-27 08:19:47 UTC
(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.
Comment 19 Peter Volkov (RETIRED) gentoo-dev 2008-05-28 12:17:46 UTC
Fixed in release snapshot.
Comment 20 Tobias Heinlein (RETIRED) gentoo-dev 2008-06-08 20:52:30 UTC
GLSA 200806-01
Comment 21 Robert Buchholz (RETIRED) gentoo-dev 2008-06-10 18:57:51 UTC
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.