Seems like the message got filtered on BUGTRAQ, I'd still
think at least some of the people on this list may have an
interest in parts of the data below.
Cheers.
---------- Forwarded message ----------
Date: Sat, 29 Jul 2000 06:11:54 +0300 (EET DST)
From: Ville <viha@cryptlink.net>
To: bugtraq@securityfocus.com
Subject: Linux traceroute (oddness & localhost memory-alloc)
Hi.
During a standard security-audit on a tad older Linux-system,
I stumbled upon some oddities in traceroute that had a nasty
feel into them.
When I researched further into it, I found no obvious way of
using the means to cause anything useful (audit-wise), but
figured I could still share the bits and pieces as they may
turn out to be of amusement or need to some.
This was way more than six months back, but I never got
around to sending mail about it. I reran the test on an RH 6
box and got the following results (reported to the correct
dev/security teams a week earlier):
1. Traceroute parses its output for any obvious over-
flow attempts.
$ traceroute `perl -e "print '1'x512"`
traceroute: Nice try !
It seems this has already been worked on once.
--- traceroute-1.4a5/traceroute.c.secfix Fri Jun 13 05:30:27 1997
+++ traceroute-1.4a5/traceroute.c Tue Dec 16 12:14:32 1997
+ <MAXHOSTNAMELEN>
+ Fprintf(stderr, "%s: Nice Try !\n", prog);
2. The input-validation for packet-size does not get
applied properly.
$ traceroute 127.0.0.1 `perl -e "print '1'x4096"`
Segmentation fault.
$ traceroute 127.0.0.1 `perl -e "print '1'x10"`
traceroute: malloc: Cannot allocate memory.
This is not likely to be as severe as it may seem
on first sight. Further analysis reveals that the
size-value is correctly checked for numeric-input
only (0-9) and thus any alphabetical input will
get rejected.
Not only the fact that ASCII-codes in the 048-057
(0x30 to 0x39) region map purely to functions
relating to XOR, AAA and CMP in x86-ASM, but also
the reality that the value is stored as a simple
integer makes a buffer-overflow (or its cousin)
quite far-fetched.
3. Traceroute permits a simple denial-of-service on
localhost as a normal user (the program is +s[uid]
root by default).
$ traceroute 127.0.0.1 360000000
^C^C^C
This seems to attempt allocating hundreds of mega-
bytes of memory because the code checking correct
packet-sizes has been misinserted into the wrong
section of the source-code.
Result: Localhost gets very unresponsive and may
need a reboot if a system watchdog fails to nail
the process.
4. It is possible to cause a puzzling message into
system logs with no obvious trace of the culprit.
$ traceroute 0.0.0.0
server0 kernel: a.b.c.d sent an invalid ICMP
error to a broadcast.
1 foo (a.b.c.d) 0.444 ms 0.203 ms 0.174 ms
This should probably be prevented at proper stage
or implemented differently, while it admittedly
is a very minor issue.
I sent a rough equivalent of the above blurp to all related
Linux parties and got one reply (from Debian), pointing out
at least #2 does not seem to apply to them, but that there
may still be an issue with the memory allocation even in the
version of traceroute they ship.
Simple patch by another co-worker attached to move the size-
checking into the correct location (based on 1.4a5).
Oh, I wonder if the program does yet check whether specified
-s[ource addresses] are mapped as local interfaces on the
box? I'm too tired to try a dump on the network-traffic now.
Apologies if any of this was already [widely] known.
Ta ta.
--
Ville <viha@cryptlink.net> Information-Security Consultation
Cryptlink Networking
