Bugtraq mailing list archives
Re: NYT Article this morning
From: jim () math psu edu (Jim Duncan)
Date: Tue, 24 Jan 1995 10:51:06 -0500
"Perry E. Metzger" writes:
Yes. Its far worse than mere IP spoofing -- that would only get you in to places which stupidly trust things like .rhosts files. The Times did not accurately describe the scope of the problem. This is a Very Bad Problem. People should legitimately worry about this one.
This is correct. It's the most insidious problem I've seen on the net.
I know this is a full disclosure list, but I was asked when I learned about this several days ago not to divulge details -- I was only told on that condition. I'm trying to get in touch with my informant to get relased from my promise so that I can describe the situation in detail. Having been in the situation of being an administrator worried about such things and not knowing where to turn, I believe in full disclosure. I'll try to post as full a disclosure as I can in a few hours.
This problem was discussed at length _in the open_ at the CERT BOF last Thursday night at USENIX in New Orleans. In fact, it was the nicest CERT BOF in years mainly because the one time somebody began the old "security through obscurity" argument, someone else in the audience quickly pointed out that there were folks there who side on either side of that argument, but that it couldn't possibly be decided right then in that room. Instead the audience concentrated on constructive dialogue and we all learned a lot. I can't remember the last time I attended such a useful CERT BOF. Here, in a nutshell, is what to be worried about. Far too many systems on the Internet rely on IP addresses for authentication. This is bad, in that IP addresses provide identification, not authentication. In addition, far too many routers and gateways will route packets with "bad" source IP addresses; i.e., they will accept and deliver a packet in which the source IP address and the destination IP address should be on the same side of the router. This could be described as incorrect behavior, but in the past I think most implementors have viewed this error as somebody else's fault. Lastly, TCP sequence numbers can be guessed with great accuracy, and Bellovin and Cheswick, among others, have suggested methods to make this impossible. The bad guy's machine sends a legitimate packet to the victim's machine, which could be anywhere in the Internet, destined for a legitimate service. The victim's machine responds with a legitimate acknowledgement, including a sequence number. The bad guy's machine then uses the incoming sequence number to guess the next number and sends a packet for some service, rsh, for example, to the victim's machine with a forged source address of some other machine which is trusted by the victim's machine. It, and the few packets which follow, are done entirely in the blind -- the bad guys don't need to see the responses -- and do something like "echo '+ +' >> .rhosts" on the victim's machine. In the meantime, they distract the other machine, the one which is trusted by the victim's machine, by sending it some noise like TCP packets with intentionally bad sequence numbers. Did your face turn gray? It should. The only quick solution is to make your routers stop forwarding packets with bad source addresses. The long term solution is to make programmers understand the difference between identification and authentication. This is not a new problem. Programmers, as well as the general public, get this concept wrong with alarming consistency. For example, it's all too common for a bank employee or medical clerk in the United States to base a customer's authentication on their ability to recite the customer's Social Security Number. That is to say, to prove your identity, you will be asked for your SSN; if you can recite it, you must be who you say you are. SSN's are, however, merely used for identification, not authentication, and should never be used for the latter purpose. Although this specific attack is targeted at Unix systems, it is not unique to them. Any system which authenticates hosts or users based on IP addresses is vulnerable. I was glad to see that mentioned in the CERT advisory. By the way, folks using multihomed workstations as routers are pretty much helpless unless they can turn off IP forwarding and run screend. I haven't tried this myself, but it was suggested to me. If you're reasonably sure you won't have this problem from inside, then you might rest a little easier. Of course, if you have a better authentication method, you should use it; then this whole problem goes away. Jim
Current thread:
- Re: NFS packet blocking (Was Mouse EXPLOIT info...), (continued)
- Re: NFS packet blocking (Was Mouse EXPLOIT info...) Pete Shipley (Jan 22)
- Re: NFS packet blocking (Was Mouse EXPLOIT info...) Karl Strickland (Jan 23)
- Re: NFS packet blocking (Was Mouse EXPLOIT info...) Bennett Todd (Jan 23)
- Re: NFS packet blocking (Was Mouse EXPLOIT info...) Timothy Newsham (Jan 23)
- A quick patch to help against TCP ISN guessing. Darren Reed (Jan 23)
- Re: NFS packet blocking (Was Mouse EXPLOIT info...) Jas (Jan 22)
- NYT Article this morning Rens Troost (Jan 23)
- Re: NYT Article this morning Perry E. Metzger (Jan 23)
- Solaris 2.3 PPP Jake Hill (Jan 24)
- Recent troubles der Mouse (Jan 24)
- Re: NYT Article this morning Jim Duncan (Jan 24)
- the next generation of nuke.c Oliver Friedrichs (Jan 25)
- the next generation of nuke.c Scott D. Yelich (Jan 26)
- IP_FORWARDING re-enabled? pluvius (Jan 26)
- Re: IP_FORWARDING re-enabled? Pete Shipley (Jan 26)