Newsgroups: alt.security,comp.security.misc,comp.security.unix
Path: nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!Belgium.EU.net!
Germany.EU.net!
wizard.pn.com!satisfied.elf.com!news.mathworks.com!hookup!swrinde!pipex!
uunet!allegra!ulysses!smb
From: s...@research.att.com (Steven Bellovin)
Subject: CERT advisory -- details
Message-ID: <D2w26n.2zr@ulysses.homer.att.com>
Sender: netn...@ulysses.homer.att.com (Shankar Ishwar)
Organization: AT&T Bell Laboratories
Date: Tue, 24 Jan 1995 02:42:23 GMT
Lines: 95
There's a great deal of confusion about what kind of attack the
recent CERT advisory is referring to. Let me try to clear things
up.
The specific attack is a sequence number guessing attack, originally
described by R.T. Morris in Bell Labs Computer Science Technical
Report #117, February 25, 1985. I generalized (and publicized)
the attack in my 1989 paper ``Security Problems in the TCP/IP
Protocol Suite'', Computer Communications Review 19:2, April 1989,
pp. 32-48. Both his attack and my generalizations are special
cases of a more general attack, IP source address spoofing, in
which the attacker illegitimately uses a trusted machine's IP
address in conjunction with some protocol (such as rsh) that does
address-based authentication.
In order to understand the particular case of sequence number
guessing, you have to look at the 3-way handshake used in the TCP
open sequence. Suppose client machine A wants to talk to rsh server
B. It sends the following message:
A->B: SYN, ISSa
That is, it sends a packet with the SYN (``synchronize sequence
number'') bit set and an initial sequence number ISSb.
B replies with
B->A: SYN, ISSb, ACK(ISSa)
In addition to sending its own initial sequence number, it acknowledges
A's. Note that the actual numeric value ISSa must appear in the
message.
A concludes the handshake by sending
A->B: ACK(ISSb)
The initial sequence numbers are intended to be more or less random.
More precisely, RFC 793 specifies that the 32-bit counter be
incremented by 1 in the low-order position about every 4 microseconds.
Instead, Berkeley-derived kernels increment it by 128 every second,
and 64 for each new connection. Thus, if you open a connection to
a machine, you know to a very high degree of confidence what sequence
number it will use for its next connection. And therein lies the
attack.
X first opens a real connection to its target B -- say, to the mail
port or the TCP echo port. This gives ISSb. It then impersonates
A and sends
A->B: SYN, ISSx
B's response to X's original SYN
B->A: SYN, ISSb', ACK(ISSx)
goes to the legitimate A, about which more anon. X never sees that
message but can still send
A->B: ACK(ISSb')
using the predicted value for ISSb'. If the guess is right -- and
usually it will be -- B's rsh server thinks it has a legitimate
connection with A, when in fact X is sending the packets. X can't
see the output from this session, but it can execute commands as
more or less any user -- and in that case, the game is over and X
has won.
There is a minor difficulty here. If A sees B's message, it will
realize that B is acknowledging something it never sent, and will
send a RST packet in response to tear down the connection. There
are a variety of ways to prevent this; the easiest is to wait until
the real A is down (possibly as a result of enemy action, of course).
There are several possible defenses. Most obvious is to take
advantage of topological knowledge: don't let packets purporting
to be from a local machine arrive on an outside interface. That
works very well if you only trust local machines. If trust is
granted to outside machines (say, via .rhosts files) and if the
attacker can identify the patterns of trust (which isn't that
difficult), the topological solution won't work. In that case,
you have to block all protocols that use TCP and address-based
authentication. (UDP is a separate can of worms.)
Best of all, don't use address-based authentication; it's a disaster
waiting to happen. The only real solution is cryptographic
authentication.
--Steve Bellovin
For further information, see the two papers cited above:
ftp://ftp.research.att.com/dist/internet_security/117.ps.Z
ftp://ftp.research.att.com/dist/internet_security/ipext.ps.Z
Path: nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!Belgium.EU.net!ub4b!
EU.net!howland.reston.ans.net!news.sprintlink.net!interactive.net!
winternet.com!news
From: g...@icicle.winternet.com (Michael Bresnahan)
Newsgroups: alt.security,comp.security.misc,comp.security.unix
Subject: Re: CERT advisory -- details
Date: 24 Jan 1995 15:51:06 GMT
Organization: StarNet Communications, Inc
Lines: 105
Message-ID: <3g37la$ags@blackice.winternet.com>
References: <D2w26n.2zr@ulysses.homer.att.com>
NNTP-Posting-Host: icicle.winternet.com
In article <D2w26n....@ulysses.homer.att.com>,
Steven Bellovin <s...@research.att.com> wrote:
>There's a great deal of confusion about what kind of attack the
>recent CERT advisory is referring to. Let me try to clear things
>up.
>
>The specific attack is a sequence number guessing attack, originally
>described by R.T. Morris in Bell Labs Computer Science Technical
>Report #117, February 25, 1985. I generalized (and publicized)
>the attack in my 1989 paper ``Security Problems in the TCP/IP
>Protocol Suite'', Computer Communications Review 19:2, April 1989,
>pp. 32-48. Both his attack and my generalizations are special
>cases of a more general attack, IP source address spoofing, in
>which the attacker illegitimately uses a trusted machine's IP
>address in conjunction with some protocol (such as rsh) that does
>address-based authentication.
>
>In order to understand the particular case of sequence number
>guessing, you have to look at the 3-way handshake used in the TCP
>open sequence. Suppose client machine A wants to talk to rsh server
>B. It sends the following message:
>
> A->B: SYN, ISSa
>
>That is, it sends a packet with the SYN (``synchronize sequence
>number'') bit set and an initial sequence number ISSb.
>
>B replies with
>
> B->A: SYN, ISSb, ACK(ISSa)
>
>In addition to sending its own initial sequence number, it acknowledges
>A's. Note that the actual numeric value ISSa must appear in the
>message.
>
>A concludes the handshake by sending
>
> A->B: ACK(ISSb)
>
>The initial sequence numbers are intended to be more or less random.
>More precisely, RFC 793 specifies that the 32-bit counter be
>incremented by 1 in the low-order position about every 4 microseconds.
>Instead, Berkeley-derived kernels increment it by 128 every second,
>and 64 for each new connection. Thus, if you open a connection to
>a machine, you know to a very high degree of confidence what sequence
>number it will use for its next connection. And therein lies the
>attack.
>
>X first opens a real connection to its target B -- say, to the mail
>port or the TCP echo port. This gives ISSb. It then impersonates
>A and sends
>
> A->B: SYN, ISSx
>
>B's response to X's original SYN
>
> B->A: SYN, ISSb', ACK(ISSx)
>
>goes to the legitimate A, about which more anon. X never sees that
>message but can still send
>
> A->B: ACK(ISSb')
>
>using the predicted value for ISSb'. If the guess is right -- and
>usually it will be -- B's rsh server thinks it has a legitimate
>connection with A, when in fact X is sending the packets. X can't
>see the output from this session, but it can execute commands as
>more or less any user -- and in that case, the game is over and X
>has won.
>
>There is a minor difficulty here. If A sees B's message, it will
>realize that B is acknowledging something it never sent, and will
>send a RST packet in response to tear down the connection. There
>are a variety of ways to prevent this; the easiest is to wait until
>the real A is down (possibly as a result of enemy action, of course).
>
>There are several possible defenses. Most obvious is to take
>advantage of topological knowledge: don't let packets purporting
>to be from a local machine arrive on an outside interface. That
>works very well if you only trust local machines. If trust is
>granted to outside machines (say, via .rhosts files) and if the
>attacker can identify the patterns of trust (which isn't that
>difficult), the topological solution won't work. In that case,
>you have to block all protocols that use TCP and address-based
>authentication. (UDP is a separate can of worms.)
>
>Best of all, don't use address-based authentication; it's a disaster
>waiting to happen. The only real solution is cryptographic
>authentication.
>
> --Steve Bellovin
>
>For further information, see the two papers cited above:
>
>ftp://ftp.research.att.com/dist/internet_security/117.ps.Z
>ftp://ftp.research.att.com/dist/internet_security/ipext.ps.Z
>
What I don't understand is why people haven't exploited this until
now. Or at least why nothing has been publicized about people
exploiting it. It seems so easy to do. What am I missing?
MikeB
Path: nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!ub4b!EU.net!
howland.reston.ans.net!news.sprintlink.net!news.vt.com!usenet
From: Graham Toal <gt...@gtoal.com>
Newsgroups: alt.security,comp.security.misc,comp.security.unix
Subject: Re: CERT advisory -- details (another staged press release?)
Date: 25 Jan 1995 18:22:57 GMT
Organization: Valley Tech Corporation
Lines: 21
Message-ID: <3g64u1$c7i@taco.vt.com>
References: <D2w26n.2zr@ulysses.homer.att.com> <3g37la$ags@blackice.winternet.com>
NNTP-Posting-Host: amicus.vt.com
g...@icicle.winternet.com (Michael Bresnahan) wrote:
(gratuitous re-quoting of a long article deleted)
> What I don't understand is why people haven't exploited this until
> now. Or at least why nothing has been publicized about people
> exploiting it. It seems so easy to do. What am I missing?
What you're missing is several years of watching CERT's MO. This
is entirely consistent with their normal behaviour - they don't
ever publish any known system holes until long after they've
been exploited.
Last time they publicised a big hole which hit the press even before
it hit the net, it was a press release given out the day before a
major Clipper announcement, which had the effect - intentional or
otherwise - of bolstering the Clipper announcement's credibility:
I urge everyone to keep an eye out for Whitehouse announcements in
the next couple of days to do with "securing the info superhighway"
that will further restrict privacy.
G
Newsgroups: alt.security,comp.security.misc,comp.security.unix
Path: nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!Belgium.EU.net!
Germany.EU.net!
wizard.pn.com!satisfied.elf.com!news.mathworks.com!hookup!swrinde!pipex!
uunet!allegra!ulysses!smb
From: s...@research.att.com (Steven Bellovin)
Subject: Re: CERT advisory -- details (another staged press release?)
Message-ID: <D2zqqo.EFq@ulysses.homer.att.com>
Sender: netn...@ulysses.homer.att.com (Shankar Ishwar)
Organization: AT&T Bell Laboratories
References: <D2w26n.2zr@ulysses.homer.att.com>
<3g37la$ags@blackice.winternet.com> <3g64u1$c7i@taco.vt.com>
Date: Thu, 26 Jan 1995 02:25:36 GMT
Lines: 69
In article <3g64u1$...@taco.vt.com>, Graham Toal <gt...@gtoal.com> writes:
> g...@icicle.winternet.com (Michael Bresnahan) wrote:
> (gratuitous re-quoting of a long article deleted)
> > What I don't understand is why people haven't exploited this until
> > now. Or at least why nothing has been publicized about people
> > exploiting it. It seems so easy to do. What am I missing?
>
> What you're missing is several years of watching CERT's MO. This
> is entirely consistent with their normal behaviour - they don't
> ever publish any known system holes until long after they've
> been exploited.
>
> Last time they publicised a big hole which hit the press even before
> it hit the net, it was a press release given out the day before a
> major Clipper announcement, which had the effect - intentional or
> otherwise - of bolstering the Clipper announcement's credibility:
> I urge everyone to keep an eye out for Whitehouse announcements in
> the next couple of days to do with "securing the info superhighway"
> that will further restrict privacy.
Well, you can blame CERT as much as you want. I won't try to prove
anything; it's rather difficult to prove a negative. However, the
actual sequence of events is not as you describe, and neither the events
nor the timing were under CERT's control.
The first documented instance of this attack happened to Tsutomu Shimomura.
He doesn't work for CERT, though of course he knows many of the folks
there and vice-versa. He described the attack publicly at a conference.
Rumors of this attack were being passed around at Usenix last week.
There was also a meeting there attended by me, several CERT folks, Bill
Cheswick, and a few other random invitees. Bill Cheswick, who had heard
Tsutomu's presentation the week before, filled us in. The situation
was being discussed pretty openly Thursday afternoon; it was presented
to the assembled multitudes by Ed DeHart of CERT, Bill Cheswick, and me
at the CERT BOF; during the firewalls BOF, which followed immediately,
the discussion (including countermeasures) continued. Also some time
Thursday, John Markoff of the NY Times had the story and was looking
for details. I spoke with him Friday afternoon when I returned to New
Jersey.
So -- the first known incident was on Christmas day, and it took several
days for Tsutomu to analyze what had happened. He -- and not CERT --
went public about two weeks later, which doesn't sound like a coverup
to me. And CERT reacted to the fact that it was already public knowledge.
I don't know when Tsutomu notified CERT; I don't even know if it was
before that other conference. Whatever the case, they didn't sit on things
for that long; there just wasn't time.
Was the attack forseeable? Sure -- Morris wrote it up 10 years ago;
I generalized it 6 years ago; and Cheswick and I described it in our
book. Had it happened before? Probably -- it's hard to detect; Tsutomu
was able to reconstruct it because he logs *all* packets into that site.
Will various forces in the government try to exploit this to push key
escrow? Maybe -- Al Gore doesn't take me into his confidence. If
they were to say that proper use of the key escrow PCMCIA card (now called
Fortessa, I believe) would have prevented this attack, they'd be quite
right. That doesn't mean there aren't bad side effects to doing so.
Disconnecting from the Internet would work, too. That also has bad
side effects. And there are better alternatives to either, in my opinion,
for quite a number of purely technical reasons (I'll leave politics out
of this newsgroup, thank you; if you want my personal opinion on key
escrow, you're welcome to discuss it with me via email).
Conclusion: demonizing folks isn't useful. It's especially not useful
when you don't have all the facts. The only reason I happen to have them
is that I happened to be at Usenix, and even that was a late decision.
--Steve Bellovin
Newsgroups: alt.security,comp.security.misc,comp.security.unix
Path: nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!ub4b!EU.net!
Germany.EU.net!
wizard.pn.com!satisfied.elf.com!news.mathworks.com!hookup!swrinde!
howland.reston.ans.net!news.sprintlink.net!crash!dbarber
From: dbar...@crash.cts.com (David C. Barber)
Subject: Re: CERT advisory -- details
Organization: CTS Network Services (CTSNET), San Diego, CA
Date: Thu, 26 Jan 1995 00:57:03 GMT
Message-ID: <dbarber.791081823@crash.cts.com>
References: <D2w26n.2zr@ulysses.homer.att.com>
<3g37la$ags@blackice.winternet.com> <3g4jmq$fml@nntp.ucs.ubc.ca>
Sender: n...@crash.cts.com (news subsystem)
Nntp-Posting-Host: crash.cts.com
Lines: 10
There are some fairly fast crypto methods (IDEA, even DES) once a
"session key" has successfully been exchanged (RSA/PGP public key).
Considering how fast the h/w is getting, would crypting every packet
(or just the authentication bytes) be too much of a burden for
increased security? I wouldn't think so.
Without Faith *David Barber*
nothing else has value dbar...@cts.com
Path: nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!ub4b!EU.net!
sun4nl!vpro!vpro!news
From: pe...@2hoog.vpro.nl (Peter Busser)
Newsgroups: alt.security,comp.security.misc,comp.security.unix
Subject: Re: CERT advisory -- details
Date: 26 Jan 1995 19:12:46 +0100
Organization: VPRO Radio&Televisie
Lines: 17
Message-ID: <3g8omu$nca@2hoog.vpro.nl>
References: <D2w26n.2zr@ulysses.homer.att.com>
<3g37la$ags@blackice.winternet.com> <3g4jmq$fml@nntp.ucs.ubc.ca>
<dbarber.791081823@crash.cts.com>
NNTP-Posting-Host: 2hoog.vpro.nl
dbar...@crash.cts.com (David C. Barber) writes:
>There are some fairly fast crypto methods (IDEA, even DES) once a
>"session key" has successfully been exchanged (RSA/PGP public key).
>Considering how fast the h/w is getting, would crypting every packet
>(or just the authentication bytes) be too much of a burden for
>increased security? I wouldn't think so.
I second this. But there are a few points which make it difficult to
implement:
- backward compatibility
- it can require much effort
- it costs money for new or extra hardware
Groetjes,
Peter Busser
Path: nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!Belgium.EU.net!
Germany.EU.net!
wizard.pn.com!satisfied.elf.com!news.mathworks.com!hookup!olivea!
news.hal.COM!decwrl!tribune.usask.ca!quartz.ucs.ualberta.ca!unixg.ubc.ca!unruh
From: un...@physics.ubc.ca (William Unruh)
Newsgroups: alt.security,comp.security.misc,comp.security.unix
Subject: Re: CERT advisory -- details
Date: 27 Jan 1995 04:54:49 GMT
Organization: The University of British Columbia
Lines: 16
Message-ID: <3g9uap$8k5@nntp.ucs.ubc.ca>
References: <D2w26n.2zr@ulysses.homer.att.com>
<3g37la$ags@blackice.winternet.com> <3g4jmq$fml@nntp.ucs.ubc.ca>
<dbarber.791081823@crash.cts.com> <3g8omu$nca@2hoog.vpro.nl>
NNTP-Posting-Host: physics.ubc.ca
pe...@2hoog.vpro.nl (Peter Busser) writes:
]>Considering how fast the h/w is getting, would crypting every packet
]>(or just the authentication bytes) be too much of a burden for
]>increased security? I wouldn't think so.
]I second this. But there are a few points which make it difficult to
]implement:
] - backward compatibility
] - it can require much effort
] - it costs money for new or extra hardware
Not to mention ITAR. Please some of you non-US people please do it!
--
Bill Unruh
un...@physics.ubc.ca
Newsgroups: alt.security,comp.security.misc,comp.security.unix
Path: nntp.gmd.de!Germany.EU.net!wizard.pn.com!satisfied.elf.com!
news.mathworks.com!udel!gatech!howland.reston.ans.net!pipex!uknet!info!iialan
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: CERT advisory -- details
X-Nntp-Posting-Host: iifeak.swan.ac.uk
Message-ID: <D3FuGA.Gyp@info.swan.ac.uk>
Sender: n...@info.swan.ac.uk
Organization: Institute For Industrial Information Technology
References: <dbarber.791081823@crash.cts.com> <3g8omu$nca@2hoog.vpro.nl>
<3g9uap$8k5@nntp.ucs.ubc.ca>
Date: Fri, 3 Feb 1995 19:07:22 GMT
Lines: 27
In article <3g9uap$...@nntp.ucs.ubc.ca> un...@physics.ubc.ca (William Unruh) writes:
>pe...@2hoog.vpro.nl (Peter Busser) writes:
>]>Considering how fast the h/w is getting, would crypting every packet
>]>(or just the authentication bytes) be too much of a burden for
>]>increased security? I wouldn't think so.
>
>]I second this. But there are a few points which make it difficult to
>]implement:
>
>] - backward compatibility
>] - it can require much effort
>] - it costs money for new or extra hardware
>
>Not to mention ITAR. Please some of you non-US people please do it!
There are IP authentication and encryption drafts available. I'm currently
adding IP auth to Linux (a 386DX40 can do MD5 at 1.25Mbytes/second so
its impact is small but real). While I'm now happy Novells patent is bogus
I wont be releasing code that will permit use in the USA - sorry folks
sort the patent mess out.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`--[Anti Kibozing Signature]-'`----------------------------''
One two three: Kibo, Lawyer, Refugee :: Green card, Compaq come read me...