Linux traceroute (oddness & localhost memory-alloc)

[Ville <viha cryptlink net>]

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

--- traceroute-1.4a5/traceroute.c.orig	Wed Jul 19 21:34:11 2000
+++ traceroute-1.4a5/traceroute.c	Wed Jul 19 21:45:07 2000
@@ -468,13 +468,6 @@
 		minpacket += 8;			/* XXX magic number */
 	else
 		minpacket += sizeof(*outudp);
-	if (packlen == 0)
-		packlen = minpacket;		/* minimum sized packet */
-	else if (minpacket > packlen || packlen > maxpacket) {
-		Fprintf(stderr, "%s: packet size must be %d <= s <= %d\n",
-		    prog, minpacket, maxpacket);
-		exit(1);
-	}
 
 	/* Process destination and optional packet size */
 	switch (argc - optind) {
@@ -503,6 +496,16 @@
 
 	default:
 		usage();
+	}
+
+	/* This checking was moved here by oh3mqu+rpm vip fi */
+	/* It was useless before packlen gets command line value */
+	if (packlen == 0)
+		packlen = minpacket;		/* minimum sized packet */
+	else if (minpacket > packlen || packlen > maxpacket) {
+		Fprintf(stderr, "%s: packet size must be %d <= s <= %d\n",
+		    prog, minpacket, maxpacket);
+		exit(1);
 	}
 
 #ifdef HAVE_SETLINEBUF