Bugzilla Bug 34477

The following utilities are set-uid root by default, I believe they should not
be and pose a useless security risk for a default install. And if they are not
set-uid root, they should be move to /usr/sbin where they belong and where they
are in every other distro that I've checked.

net-analyzer/traceroute-1.4_p12-r1:
/usr/bin/traceroute

net-misc/iputils-020927:
/usr/bin/tracepath
/usr/bin/traceroute6
/usr/bin/tracepath6

net-analyzer/tcptraceroute-1.4-r2:
/usr/bin/tcptraceroute

traceroute needs to be setuid root, it uses raw sockets. 

you're right about tracepath though, the man page specifically says this should not be setuid root.

I mean traceroute shouldnt be set-uid root and should be only usable by root by
default.. 

Securityfocus has two exploits for traceroute and one for tcptraceroute.. And
since tracepath exists, I still think they shouldnt be setuid by default and
they should be installed in /usr/sbin like in every other distribution... 

traceroute-1.4_p12-r2 installs into /usr/sbin and is given 0755 as perms

tcptraceroute-1.4-r3 no longer installs +s

I posted to a mailing list on this subject previously, but wanted to contribute
my $0.02CDN to this bug.

Is it possible, instead of removing the setuid bit (therefore rendering
traceroute usable only to root and those configured, and knowledgeable in sudo)
to change the group to an administrative group and set 4750 perms so we don't
have to jump through hoops to use this application?

The setuid bit is a long-standing facet of traceroute, and it's been pointed
out that various BSD's (Free among them) haven't found it neccesary to remove
said bit.

4710 root:wheel perhaps ?

traceroute/tcptraceroute are now 4710 root:wheel

*** Bug 41583 has been marked as a duplicate of this bug. ***

Hello,
traceroute is a standard util and users expect it working. After world update,
it is executable for members of wheel group only. Are there any known issues 
to justify this really drastic change? All UNIX systems I saw make traceroute
executable for all. If restricted to group, wheel group is by far the worst
possible choice imaginable. (sorry cannot reopen)

Traceroute is a utility riddled with past and present vulnerabilities, and as a
setuid util, it isn't considered safe to be accessable by all users. The wheel
group was chosen, albeit somewhat arbitrarily, to abate the issue and reduce
exposure to harm for a system.

One other proposed solution that I'd still like to see implemented in the near
future is a group such as "sockets" that would allow its users to have direct
socket access. Utilities such as traceroute, ping, netcat(?), tcpdump, et al.
could be placed in such a group to permit finer-grained access control.

One detraction of using the wheel group, as pointed out elsewhere (#gentoo-dev,
IIRC) is the fact that 'su' is typically wheel-restricted, therefore allowing
anybody with traceroute access the abililty to utilize su capabilities.

We are talking about traceroute in general or version gentoo is using? If it
is considered so dangerous (by who??), shouldn't there be a security
anouncement and the author be notified? Where is the article? Because, all
linux distributions we use here have same version and suid bit set:

debian (woody)
1.4a12-9        /usr/bin, 4755

debian (sarge) (-13 = latest ver avail from debian)
1.4a12-13       /usr/bin, 4755

mandrake (dolphin)
1.4a12-3mdk     /usr/sbin, 4755

mandrake (fivestar)
1.4a12-4mdk     /usr/sbin, 4755

redhat (9.0)
1.4a12-9        /usr/sbin, 4755

fedora core (0.94)
1.4a12-20.1     /usr/bin, 4755


Only exception is SuSE who also have switched to a different traceroute in 
9.0 that is said to run non suid root.

suse (8.0)
1.4a12-156      /usr/sbin, 0755

suse (8.2)
1.4a12-208      /usr/sbin, 0755

we didnt say this version was full of holes, we said it has a history of not
having the cleanest code

Yeah you did. Comment #2 says "two exploits for traceroute" and seems to base
decision upon it. Debian has same version of traceroute in use since 1999 and
all updates are marked "urgency=low", so I ask again, where is mysterious
exploit? Are all my other machines in danger?

This I don't get: I just found *exploitable* bug on gentoo software in bugzilla open
for almost 1 year. In another bug someone from security team says security team
does not have time and resources to send out GLSA for everything. In another 
report same person does not want to apply perfectly valid patch to serious 
symlink attack issue because nobody has "time or skills to audit patch". But
you *do* have time and resources to cripple utility executable for all by (unwritten)
standard (works on Solaris, IRIX, HP-UX too) I did not find single vulnerability
for? Please enlighten me.

We should find out what SuSE is doing and do that.

You sound rather hostile. What was your developer e-mail address?

A quick search of SecurityFocus did uncover a few security advisories for the various versions of traceroute.

Gentoo isn't a distribution with vast corporate resources to address all the problems that are brought to BugZilla. If you, on the other hand, have spare time and resources I'm sure the security team would be glad to have you.

Meanwhile, the traceroute 'fix' (not, I might add, written in stone) was a minor precaution taken to negate the possibility of an attack on this, and the many other setuid utilities in the tree.

I don't know if this is the right place, but just to clear things up, English 
is not my first and second language, no hostility intended. Issues here are,
first, change was not announced anywhere and breaks new installations but old 
ebuild has disappeared. Wheel group has too many privileges, sometimes write 
access to /usr/local, in many places.

Second, why don't you just use version from RedHat or Fedora then? To say there
are exploits without telling details just causes major panic in management.

I'll be quiet now.

This is inconsistent, really.
traceroute is in /usr/sbin -- usable only for root.
traceroute6 however is in /usr/bin - setuid root.

great -- so file a bug that traceroute6 should be moved to /usr/sbin and
installed  without the SUID bit set.

What do you mean "FIXED"?
I just remerged iputils-021109-r3 after emerge sync and /usr/bin/tracepath and /usr/bin/tracepath6 are still suid root.
As is /usr/bin/traceroute6 also.