From: Olaf Kirch <okir@caldera.de>
To: linux-kernel@vger.kernel.org
Cc: security-audit@ferret.lmh.ox.ac.uk
Subject: Traceroute without s bit
Date: Wed, 6 Dec 2000 13:50:19 +0100 [thread overview]
Message-ID: <20001206135019.L9533@monad.caldera.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]
Hi all,
I wrote a small traceroute last night that works mostly like the
LBL one, except it doesn't need an s bit anymore :)
Since the source code is small, I'm attaching it to this mail.
Note that it requires a 2.4 linux kernel and possibly a recent
glibc (not sure of that).
Most of the features it uses are standard BSD stack ones, except
for the use of IP-level control messages to obtain the ICMP error
codes and the error's time stamp.
There are three things that puzzle me, however:
1. When I want to include IP options into an outgoing packet,
I'm expected to include a struct ip_options in the IP_RETOPTS
control message. However, this struct is included in
#ifdef __KERNEL__/#endif in 2.4.0-t10 (on which I'm compiling
right now). Normally this doesn't deter me, but in this case
some of the fields look sort of fishy to me.
My question is, do we really want to allow users to hand
an arbitrary, unchecked struct ip_options to the kernel?
Wouldn't raw options be a better choice?
2. There's another issue with ip_cmsg_send in ip_sockglue.c;
it allows any user to specify PKTINFO data in a control
messages. As far as I can tell, by looking at udp.c,
this lets any user set arbitrary IP source addresses
on outgoing UDP packets. Yikes.
3. There seems to be a bug somewhere in the handling of poll().
If you observe the traceroute process with strace, you'll
notice that it starts spinning madly after receiving the
first bunch of packets (those with ttl 1).
13:43:02 poll([{fd=4, events=POLLERR}], 1, 5) = 0
13:43:02 poll([{fd=4, events=POLLERR}], 1, 5) = 0
13:43:02 poll([{fd=4, events=POLLERR}], 1, 5) = 0
13:43:02 poll([{fd=4, events=POLLERR}], 1, 5) = 0
...
I.e. the poll call returns as if it had timed out, but it
hasn't.
Any input from network kernel hackers would be greatly appreciated!
Cheers,
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
[-- Attachment #2: traceroute.tar.gz --]
[-- Type: application/x-gunzip, Size: 6630 bytes --]
next reply other threads:[~2000-12-06 13:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-06 12:50 Olaf Kirch [this message]
2000-12-06 13:09 ` Traceroute without s bit Andi Kleen
2000-12-06 15:07 ` Olaf Kirch
2000-12-06 16:27 ` Andi Kleen
2000-12-06 15:35 ` James Antill
2000-12-06 16:29 ` Olaf Kirch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20001206135019.L9533@monad.caldera.de \
--to=okir@caldera.de \
--cc=linux-kernel@vger.kernel.org \
--cc=security-audit@ferret.lmh.ox.ac.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox