Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!UMN-REI-UC.ARPA!slevy
From: slevy@UMN-REI-UC.ARPA.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Ethernet Bridge
Message-ID: <8711080223.AA07353@uc.msc.umn.edu>
Date: Sat, 7-Nov-87 21:23:00 EST
Article-I.D.: uc.8711080223.AA07353
Posted: Sat Nov  7 21:23:00 1987
Date-Received: Sat, 14-Nov-87 11:53:26 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 64

On IP & Ethernet address spoofing --

If there's no LAN bridge between you and the target, it's easy.
If there is, you may still be able to fool the bridge into passing
stuff onto your side.  If you want to look like host X (of IP address X.IP
and MAC-level address X.MAC), it may suffice to send out some packets
with MAC source address X.MAC.  When the bridge sees those, it may well
get confused about where X.MAC really is, and start routing X.MAC-destined
packets onto your part of the wire.  Presumably this depends on the bridge's
design, and I've never actually tried it, but it does sound plausible.

Another trick, not dependent on the bridge behavior, would be to send
an ICMP host redirect to the target, telling it to route traffic to X
via your own IP address (or some bogus one which you were willing to ARP for).
That should work even when X is up.  We're considering making our own
hosts ignore ICMP redirects for this reason, despite the loss of functionality.

We're also considering fixing our gateways in an unorthodox way --
to look at the IP -source- address of arriving packets.  If a packet arrives
from host Y, on an interface to which that gateway would never route packets
to Y, the gateway discards the packet.  If all the gateways in a system[*] act
this way, a spoofer can pretend to be someone else on the same net, but
not someone on another net.  So IP gateways can be made to be firewalls
in a way that MAC-layer bridges can't (unless the bridges get their routing
tables from the net administrator rather than learning by listening).
In this case the gateways, too, need to be careful about what ICMP redirects
they believe... perhaps by having an administrator-supplied list of GW's,
where redirects are believed only if they point to (not just come from!)
a legitimate GW.

[*]Well... the above sort of works.  I think it only really is reliable if
the structure of the "system" is a special one -- where all the gateways
and all the paths between them are trustworthy, and all the untrusted nets
are one GW away from the trusted backbone.  Redundancy is still possible,
and the backbone can have any structure, but rigid separation of
trusted from untrusted hosts & wires still is a pretty severe restriction.
Maybe this amounts to an argument for higher-level, end-to-end
authentication.


While I'm at this, how about NFS security.  I think the fake setuid hole
can be plugged: SUN's NFS at least has a "nosuid" mount option, and
you can just arrange to mount all non-system file systems with it.
Then only the server of system files needs to be secure.
However, a local superuser can get access to any non-root user's files
simply by setting his uid to the right thing.  So can any Joe with a PC
who goes to the trouble to write an NFS client, which can claim to be any
IP address, Ethernet address, and uid it wishes.  And as far as I know,
NFS (unlike TCP) won't even turn a hair if multiple clients on a net
claim to be the same machine -- each ignores responses to the others' requests.

SUN's RPC authentication scheme, which derives keys from user passwords,
distributes them with a public-key scheme, and uses DES to authenticate
transactions after the keys are established, seems promising in this regard.
(It was written up in a paper in Summer '86 Usenix, and was supposed to
be released with Sun 4.0 the last I heard, along with an NFS that optionally
uses it.)  One thing I worry about, though.  It appears secure enough
that people might be willing to allow root access across NFS.  But,
if anyone finds a hole allowing them to be root -without rebooting the machine-
they'll easily gain root access to everything sharing filesystems
with them -- a hole bigger than the present one.

					Stuart Levy, Minn. Supercomputer Center
					slevy@uf.msc.umn.edu, 612-626-0211