Security Hole In TCP

Ant wrote to us with the report from eWeek concerning Guardent's find of a "potentially huge problem" in TCP. It's very similar to the hole found in some of the Cisco IOS software, concerning the ISN and the assignment of the number.

Comments

This is out of proportion

[Geoff NoNick]

The article says that this is a potentially huge problem, but the fact of the matter is that it's:
a) very hard to do, and
b) rather limited in practical damage-causing.

This issue is more founded in a company trying to make a name for itself by announcing a "huge" security flaw but it also appeals to the public at large to imagine that there might be some terrible hole underpinning the electronic revolution (like as in Y2K or the fuss around some dot.coms going belly up). Besides, this isn't a hole so much as a feature that can be used in a negative way. I don't think the possibility of doing this went unobserved by the hundreds of people involved in developing TCP.

Geoff

Re:RFC1948

[Anonymous Coward]

Not only that, but around 1997 or so there were tools floating around that used this trick specifically against IRC servers. IRC servers simply started sending random numbers in their "PING" messages, and dropping people who didn't have the same number in their "PONG." Since when you were spoofing, you couldn't see the return packets, you couldn't respond correctly.

Finally, the problem was fixed for real at the OS level in almost every OS in late 1998 or so. Unpredictably random ISNs and increments are quite common. The popular tool "nmap" can even scan a machine and tell you how unpredicatable its sequence numbers are. Non-microsoft OSes (and win2000) generate sequence numbers quite securely.

This is very old, non-news. The best quote in the whole article is the security expert who points out that this has been known pretty much forever, was fixed 5 years ago, and the fix was widely deployed over 3 years ago.

Re:NITROGEN WARNING is similar to TCP/IP warning

[dattaway]

Some people may think its a joke, but the levels of DHMO in humans has been staggering the last few years. I hear it becomes most serious on the weekends. Please be careful of the consumption of beverages that may contain significant quantities.

NITROGEN WARNING is similar to TCP/IP warning

[Bruce Perens]

The warning we are now reading about TCP is very similar to this NITROGEN WARNING:

Warning! Scientists have determined that, if you live in the U.S., over 70% of the air you breathe is now NITROGEN. Nitrogen is a colorless, odorless gas that can actually DROWN YOU by excluding oxygen from your environment.

Of course, the air has contained that much Nitrogen for the entire existence of the human species. And this TCP security problem has existed nearly as long, and has had about as little effect on your life. People fix this by improving their random number generators. Big deal.

Bruce

Re:"Old as the Hills"

[SEWilco]

I've discovered that when a backhoe cuts the wire connecting me to my ISP, the network suddenly fails. Nothing I do to the network interface seems to fix the problem. I've found documentation that this problem is as old as the hills, yet nothing has been done about it. I thought I'd better announce this in case another backhoe is built.

Re:Which other protocols *also* have holes?

[johnnyb]

You might find some good info from the creators of Samba. From what I've heard, they actually did find a huge number of security holes in the protocol. If there's docs for any of them, they'll be at http://us1.samba.org/samba/docs/

Re:Looks like a pretty standard case to me.

[Cramer]

They also failed to point out why this has never been a significant problem - ever. In order to assume any established connection, you'd have to be one the same cable or somewhere in the path (read: "man in the middle") You cannot steel any random connection on the net. In fact, it's become rather difficult to nuke 3rd party connections -- send an ICMP unreachable message to close down a connection between two distant machines (presumablly when you aren't in the path.) This was the tool of IRC channel/nick theives in the 80's :-)

And yes, you can assume the connection in any case if you are on the cable or in a direct path where you naturally see the traffic in both directions. I had fun one evening (yes, it's that easy) modifying my linux box (486dx50 running 0.99pl15 at the time) to "flash establish" a socket and assume the telnet session from my mac.

Re:Random Numbers

[pafein]

2) How hard can it possibly be to generate a random number, even for a simple OS installed in a router?

I actually had a rather lengthy argument with my computer sciences teacher about this -- it is impossible to generate a truely random number.

Actually, IIRC, SGI did this using digitized photos of lava lamps as seeds.

It is kind of like trying to prove something can't be done.

Come now. Mathematicians do it all the time.

Re:Random Numbers

[Fatal0E]

I remember reading a long time ago about a couple of programmers who needed a strong encryption routine so they improvised one.

They pointed a web cam at a lava lamp(!). The pictures are the hash source for the random number generator. Their theory was something like, "What could be more random then a Lava Lamp?!" Here's a link to something similar but I won't say it's -the- one I'm talking about since I honestly cant remember where I saw it originally.
"Me Ted"

Fun with NMAP TCP Sequence Prediction.

[e_n_d_o]

These are all results from NMAP

---- My Windows 2000 Pro box w/SP1

TCP Sequence Prediction: Class=random positive increments Difficulty=11993 (Worthy challenge)
Remote operating system guess: Windows 2000 RC1 through final release

---- My Linux box (RedHat 7.0, all updates)

TCP Sequence Prediction: Class=random positive increments Difficulty=5472011 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.14

---- On of work's retired NT4 servers

TCP Sequence Prediction: Class=trivial time dependency Difficulty=4 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98

Our WatchGuard firewall returns a dificulty of 9999999.

---

Re:Random Numbers

[Mihg]

Quoting /usr/src/linux/drivers/char/random.c:

Theory of operation

Computers are very predictable devices. Hence it is extremely hard to produce truly random numbers on a computer --- as opposed to pseudo-random numbers, which can easily generated by using a algorithm. Unfortunately, it is very easy for attackers to guess the sequence of pseudo-random number generators, and for some applications this is not acceptable. So instead, we must try to gather "environmental noise" from the computer's environment, which must be hard for outside attackers to observe, and use that to enerate random numbers. In a Unix environment, this is best done from inside the kernel.

Sources of randomness from the environment include inter-keyboard timings, inter-interrupt timings from some interrupts, and other events which are both (a) non-deterministic and (b) hard for an outside observer to measure. Randomness from these sources are added to an "entropy pool", which is mixed using a CRC-like function. This is not cryptographically strong, but it is adequate assuming the randomness is not chosen maliciously, and it is fast enough that the overhead of doing it on every interrupt is very reasonable. As random bytes are mixed into the entropy pool, the routines keep an estimate of how many bits of randomness have been stored into the random number generator's internal state.

When random bytes are desired, they are obtained by taking the SHA hash of the contents of the "entropy pool". The SHA hash avoids exposing the internal state of the entropy pool. It is believed to be computationally infeasible to derive any useful information about the input of SHA from its output. Even if it is possible to analyze SHA in some clever way, as long as the amount of data returned from the generator is less than the inherent entropy in the pool, the output data is totally unpredictable. For this reason, the routine decreases its internal estimate of how many bits of "true randomness" are contained in the entropy pool as it outputs random numbers.

If this estimate goes to zero, the routine can still generate random numbers; however, an attacker may (at least in theory) be able to infer the future output of the generator from prior outputs. This requires successful cryptanalysis of SHA, which is not believed to be feasible, but there is a remote possibility. Nonetheless, these numbers should be useful for the vast majority of purposes.

So, yes, I have RTFM (RTFS?) in this case (and before this article was ever posted, which should give me bonus points).

The time between the interrupts caused by my keypresses and mouse movements is random. PGP for DOS used this fact directly, however modern operating systems provide their own sources of random bits based on the same principle.

Note that devices that measure radioactive decay can be easily hooked up to the Linux random number generator. :-)

---
The Hotmail addres is my decoy account. I read it approximately once per year.

Version without big-ass ad

[sulli]

is here.

Looks like a pretty standard case to me.

[Bonker]

Guardent is trying to garner publicity by 'announcing' a known vulnerability that has been, for the most part, cmpletely addressed!

Way to go guys! Before, I didn't who you were. Now I know you're a complete bunch of retarded chimpanzees!

Re:Randomness does not exist.

[hawk]

> Consider this. ALL events can theoretically be traced back
> to a specific cause.

Pardon???? That's true in the newtonian universe, but not at lower levels.

At the quantum level, things are fundamentally random, and the "hidden
numbers theory" has long fallen out of fashion.

I don't know enough about thermal processes, but radioactive decay is, in thoery,purely stochastic--there are no causal variables and deviations from the mean number of decay evnts *must* be purely random.

hawk, once a physcist

Re:"Old as the Hills"

[wunderhorn1]

but remember the quote from l0pht's old website (which isn't up anymore, so I'm doing this from memory):

Microsoft: That vulnerability is completely theoretical
l0pht: Making the theoretical practical since 19XX

RFC1948

[johnburton]

RFC1948 which is 5 years old described this problem and how to solve it.