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

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: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"

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.

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.