Neil Readwin says:
> Imagine you're running NFS and I send you unlink RPC calls and you send
> all the ACKs back to another machine. I can't get a data back out but I
> can destroy your disks.
>
> I don't know enough about NFS/RPC to know if the above would work, but I
> could design a protocol in which it would work so the fact that traffic
> only goes in is not *necessarily* any protection.
It might work, but you'd have to be tricky about it. Inode generation
numbers are randomized when disks get built. However, the random
number generators in question are rather poor and thus you can
probably spoof the connections. There should be ways to do this sort
of thing as well -- NFS is so low on security that I've never bothered
to look at it in detail -- it would be like trying to look for new
holes in a sieve.
Also, there are ways to hijack TCP connections even if you can only
get half the connection -- see Bellovin's paper on security in the
TCP/IP suite.
Beyond this, if your network hosts comply with the host requirements
RFC on how to handle source routed packets, you can pretend to be any
machine on the network at will -- John Ioannidis has in fact built a
virtual interface for BSD style TCP/IP that will let you do this
conveniently.
IP isn't a secure protocol. It was never meant to be. If you need to
trust information, make sure the information is cryptographically
authenticated. If you can't cryptographically authenticate it, you
shouldn't trust it.
By the way, for those of you who think that Sun's "secure RPC" based
on Diffie-Hellman key exchange is secure, think again -- it turns out
that its trivially broken, because of especially bad implementation
choices. (I nearly fell over laughing when I read a paper on the
subject -- see "Computation of Discrete Logarithms in Prime Fields" by
LaMacchia and Odlyzko of Bell Labs. Turns out that with a little
precomputation you can break "secure" (ha!) RPCs with about as much
effort as it takes to crack open walnuts.) So when you trust
cryptography, be sure you are trusting GOOD cryptography.
All this is even more reason to be as paranoid as humanly possible
when building firewalls.
Some may call me paranoid, and some may say that all the effort
involved in making your systems secure isn't worth the cost.
However...
1) Not having security can cost you your network, and
2) Cryptography is very cheap in the scheme of things, and good
cryptography costs no more than bad cryptography.
Perry
Follow-Ups:
|
|
