[2397] in linux-security and linux-alert archive
[linux-security] Linux traceroute (oddness & localhost memory-alloc)
daemon@ATHENA.MIT.EDU (Ville)
Mon Jul 31 13:55:58 2000
Date: Mon, 31 Jul 2000 20:12:01 +0300 (EET DST)
From: Ville <viha@cryptlink.net>
To: linux-security@redhat.com
Message-ID: <Pine.LNX.4.21.0007312006140.28738-200000@populo.vip.fi>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-977140265-1613377189-964840067=:19469"
Content-ID: <Pine.LNX.4.21.0007290609321.19469@populo.vip.fi>
Resent-From: linux-security@redhat.com
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
---977140265-1613377189-964840067=:19469
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0007290609322.19469@populo.vip.fi>
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
---977140265-1613377189-964840067=:19469
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="traceroute-1.4a5-bigpacklen.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0007290607470.19469@populo.vip.fi>
Content-Description: Traceroute packet-size patch
Content-Disposition: ATTACHMENT; FILENAME="traceroute-1.4a5-bigpacklen.patch"
LS0tIHRyYWNlcm91dGUtMS40YTUvdHJhY2Vyb3V0ZS5jLm9yaWcJV2VkIEp1
bCAxOSAyMTozNDoxMSAyMDAwDQorKysgdHJhY2Vyb3V0ZS0xLjRhNS90cmFj
ZXJvdXRlLmMJV2VkIEp1bCAxOSAyMTo0NTowNyAyMDAwDQpAQCAtNDY4LDEz
ICs0NjgsNiBAQA0KIAkJbWlucGFja2V0ICs9IDg7CQkJLyogWFhYIG1hZ2lj
IG51bWJlciAqLw0KIAllbHNlDQogCQltaW5wYWNrZXQgKz0gc2l6ZW9mKCpv
dXR1ZHApOw0KLQlpZiAocGFja2xlbiA9PSAwKQ0KLQkJcGFja2xlbiA9IG1p
bnBhY2tldDsJCS8qIG1pbmltdW0gc2l6ZWQgcGFja2V0ICovDQotCWVsc2Ug
aWYgKG1pbnBhY2tldCA+IHBhY2tsZW4gfHwgcGFja2xlbiA+IG1heHBhY2tl
dCkgew0KLQkJRnByaW50ZihzdGRlcnIsICIlczogcGFja2V0IHNpemUgbXVz
dCBiZSAlZCA8PSBzIDw9ICVkXG4iLA0KLQkJICAgIHByb2csIG1pbnBhY2tl
dCwgbWF4cGFja2V0KTsNCi0JCWV4aXQoMSk7DQotCX0NCiANCiAJLyogUHJv
Y2VzcyBkZXN0aW5hdGlvbiBhbmQgb3B0aW9uYWwgcGFja2V0IHNpemUgKi8N
CiAJc3dpdGNoIChhcmdjIC0gb3B0aW5kKSB7DQpAQCAtNTAzLDYgKzQ5Niwx
NiBAQA0KIA0KIAlkZWZhdWx0Og0KIAkJdXNhZ2UoKTsNCisJfQ0KKw0KKwkv
KiBUaGlzIGNoZWNraW5nIHdhcyBtb3ZlZCBoZXJlIGJ5IG9oM21xdStycG1A
dmlwLmZpICovDQorCS8qIEl0IHdhcyB1c2VsZXNzIGJlZm9yZSBwYWNrbGVu
IGdldHMgY29tbWFuZCBsaW5lIHZhbHVlICovDQorCWlmIChwYWNrbGVuID09
IDApDQorCQlwYWNrbGVuID0gbWlucGFja2V0OwkJLyogbWluaW11bSBzaXpl
ZCBwYWNrZXQgKi8NCisJZWxzZSBpZiAobWlucGFja2V0ID4gcGFja2xlbiB8
fCBwYWNrbGVuID4gbWF4cGFja2V0KSB7DQorCQlGcHJpbnRmKHN0ZGVyciwg
IiVzOiBwYWNrZXQgc2l6ZSBtdXN0IGJlICVkIDw9IHMgPD0gJWRcbiIsDQor
CQkgICAgcHJvZywgbWlucGFja2V0LCBtYXhwYWNrZXQpOw0KKwkJZXhpdCgx
KTsNCiAJfQ0KIA0KICNpZmRlZiBIQVZFX1NFVExJTkVCVUYNCg==
---977140265-1613377189-964840067=:19469--
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe:
mail -s unsubscribe linux-security-request@redhat.com < /dev/null
