[Note: I've marked this bug as "BETA team" only. That's the best I can do
to stop any old
dude finding this report]
Here's a copy of a mail I sent describing the sorry state of iputils
"ping". It needs a good
audit. Or you could just adopt OpenBSD's ping, porting across any new
Show of hands please, who is shipping "ping" from iputils? The following
is relative to "iputils-20000418-6", e.g. RH7.0's version.
We had just about got the netkit ping secure, so hey we'd better regress
by all starting to ship iputils ping which seems to have been forked from
a somewhat less secure base.
- Fails to drop privilege at startup after getting the raw socket
- Buffer overflow (not on stack) in pr_addr():
static char buf;
sprintf(buf, "%s (%s)", hp->h_name,
inet_ntoa(*(struct in_addr *)&addr));
AFAIK, with glibc, hp->h_name has MAXHOSTLEN of 1024
- Small buffer overflow of size "struct timeval" above output packet
- And another possible larger buffer overflow in the same area,
- Ooh, just found a URL describing the first overflow flaw
- Unreliable nul termination of buffers, e.g.
strncpy(hnamebuf, hp->h_name, sizeof(hnamebuf) - 1);
(missing explicit NULL termination)
- VERY WORRYING looking stack-based overflow
- Another buffer mismanagement flaw in the same area (read off end)
Bit of an embarassment, this, really.
Update! Update! Read all about it..
Turns out many of these issues are already fixed in the recently released:
(RH7.0 is based off iputils-ss000418.tar.gz which to be fair was the most recent
at freeze time!)
The most recent iputils still has a couple of minor overflows, though (although
they will of course yield a raw socket to an attacker rather than full blown
Patches to most recent iputils to appear..
An update.. a new upstream iputils package with all known ping security bugs
will probably be out soon.
I'll update this bug with its location when it's out.
New version of iputils with all known ping security bugs fixed:
Your call as to whether to do an update or not guys. I don't think any of the
bugs can lead to root compromise. However this is only due to luck. It all
depends on how the compiler lays out the static variables in the BSS. There are
a few statics that, if overwritten, could easily lead to a compromise. In the
current x86 binary, I believe things are safe.. but.. :-)
I'd be tempted to do an update. Better safe than sorry?
Fixed in iputils-20001010-1.
Making this readable by everyone, as it is referenced in our errata advisory.