gnu@hoptoad.uucp (John Gilmore) (04/13/87)
I found this amusing message in mod.protocols.tcp-ip. There has been a
big discussion of how an administrator at Berkeley inadvertently
scribbled a message on screens from Podunk to the Pentagon on the DoD
Internet, using the Sun "rwall" command. Nagle seeks to put this in
perspective:
From: jbn@GLACIER.STANFORD.EDU (John B. Nagle)
Newsgroups: mod.protocols.tcp-ip
Subject: NFS security
Date: 7 Apr 87 05:43:47 GMT
Quit worrying about "rwall". All one can do with that is annoy
people. Worry about Sun NFS and Berkeley RLOGIN, both of which assume
that hosts are "good guys". Consider the following:
If you have the means to impersonate any host by setting an interesting
number in your source IP address, and can see the replies coming back,
you can access any remotely accessable file on any NFS server. If you are
on the same LAN, this is trivial; otherwise it may take some eavesdropping
or gateway tampering to bring it off. Note, by the way, that large networks
constructed with low-level bridges are especially vulnerable to this type
of attack. (This is not to be construed as an argument that IP routers
provide some kind of security). With the advent of PC-based NFS clients,
NFS break-in can be accomplished with low-cost hardware and requires minimal
technical sophistication.
NFS is useful. NFS is clever. NFS is efficient. NFS works. NFS
has security holes though which one could drive an armored division. Don't
blame Bill Joy; he's the one who insisted that SUN machines have sockets for
DES chips. However, DoD's export controls on cryptographic equipment
discourage the use of crypto hardware in commercial equipment. So the
socket is invariably empty. DoD has shot itself in the foot on this one.
John Nagle
[Nagle is right, my Suns both have sockets for an AMD encryption chip.
Both empty. Also, the PALs that run the chip are missing, so even if I got a
DES chip and plugged it in, it wouldn't work. -- hoptoad!gnu]
--
Copyright 1987 John Gilmore; you can redistribute only if your recipients can.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu gnu@ingres.berkeley.eduwebber@klinzhai.UUCP (04/14/87)
[The message I am replying to is appended below. I didn't want to
edit it, less it appear I was creating a derivative work. Instead,
all I am doing is redistibuting it along with my reply. Hopefully
future versions of the copyright business will be clear on the notion
of other people editing copyrighted messages.]
In the appended note, the case is made that Suns are ready to support
DES chips, but for export reasons, they do not come so equipped and
thus these chips (DES chips and related hardware support) never get
used. My question, what would happen if you actually installed such
hardware? Would the NFS software support it or would you then have to
make major modifications to the system software before you would
benefit from purchasing the hardware? If you actually used such
hardware, would you notice a degradation in throughput to the disk or
does the DES hardware run DMA in parallel with the cpu and i/o
controllers?
-------------- BOB (webber@aramis.rutgers.edu ; backbone!topaz!webber)
In article <1983@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes:
I found this amusing message in mod.protocols.tcp-ip. There has been a
big discussion of how an administrator at Berkeley inadvertently
scribbled a message on screens from Podunk to the Pentagon on the DoD
Internet, using the Sun "rwall" command. Nagle seeks to put this in
perspective:
From: jbn@GLACIER.STANFORD.EDU (John B. Nagle)
Newsgroups: mod.protocols.tcp-ip
Subject: NFS security
Date: 7 Apr 87 05:43:47 GMT
Quit worrying about "rwall". All one can do with that is annoy
people. Worry about Sun NFS and Berkeley RLOGIN, both of which assume
that hosts are "good guys". Consider the following:
If you have the means to impersonate any host by setting an interesting
number in your source IP address, and can see the replies coming back,
you can access any remotely accessable file on any NFS server. If you are
on the same LAN, this is trivial; otherwise it may take some eavesdropping
or gateway tampering to bring it off. Note, by the way, that large networks
constructed with low-level bridges are especially vulnerable to this type
of attack. (This is not to be construed as an argument that IP routers
provide some kind of security). With the advent of PC-based NFS clients,
NFS break-in can be accomplished with low-cost hardware and requires minimal
technical sophistication.
NFS is useful. NFS is clever. NFS is efficient. NFS works. NFS
has security holes though which one could drive an armored division. Don't
blame Bill Joy; he's the one who insisted that SUN machines have sockets for
DES chips. However, DoD's export controls on cryptographic equipment
discourage the use of crypto hardware in commercial equipment. So the
socket is invariably empty. DoD has shot itself in the foot on this one.
John Nagle
[Nagle is right, my Suns both have sockets for an AMD encryption chip.
Both empty. Also, the PALs that run the chip are missing, so even if I got a
DES chip and plugged it in, it wouldn't work. -- hoptoad!gnu]
--
Copyright 1987 John Gilmore; you can redistribute only if your recipients can.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu gnu@ingres.berkeley.edugnu@hoptoad.UUCP (04/18/87)
> ...what would happen if you actually installed such > hardware? Would the NFS software support it or would you then have to > make major modifications to the system software before you would > benefit from purchasing the hardware? If you actually used such > hardware, would you notice a degradation in throughput to the disk or > does the DES hardware run DMA in parallel with the cpu and i/o > controllers? No, NFS does not currently support the use of DES (chips or software). This is because there are lots of things that Sun has on its list to do, and supporting chips that the government won't let it sell is pretty low on the list. The chips are run as programmed-I/O devices. They do not have any DMA control. The chip involved requires really wierd timing just for programmed I/O, and a 68020 running a tight loop is a pretty good DMA controller. The time required to encrypt and decrypt, whether with a DMA controller or not, would be added to the wall clock time already required to service an NFS request. I suspect that the effect would be noticeable, considering that turning off UDP checksums makes a measurable difference. Bob Smith of Sun testified yesterday for US Representatives Norman Mineta and Don Edwards that Pentagon export regulations are big problem in keeping Sun competitive in the world market: "In many respects, the Departments of Defense and Commerce are in the Dark Ages of computer technology". Smith acknowledged some recent improvement in the commerce department but he added that "our fear is that computer technology is moving faster" than government's ability to keep track. (SF Chronicle, April 17, pg. 36) -- Copyright 1987 John Gilmore; you can redistribute only if your recipients can. (This is an effort to bend Stargate to work with Usenet, not against it.) {sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu gnu@ingres.berkeley.edu