Subject: Re: Calculations of ISN for new TCP sessions

From: Vernon Schryver <[email-masked]>
Date: Sat, 16 Sep 2000 12:19:02 -0600 (MDT)

> From: Andi Kleen <[email-masked]>

> ...
> > I don't agree that MD5 hashes of secrets are always required....not
> > that he says that, but that's what the test authors tell their customers.
>
> There are much easier ways to attack the ISN computation in most OS
> anyways than attacking MD5:  you attack the secret generation.
>
> On diskless devices you can usually just find out the initial secret because 
> ...

Yes, if the bad guy knows what you're feeding MD5 or SHA, then using them
is a waste of CPU cycles.

That's why I think
 - the products that claim to detect predictable ISN's are snake oil and
  frauds, because they have both false positives and false negatives.

 - in addition to (or even instead of) a static secret that you feed to
  MD5, you should use something that even the host cannot know in advance,
  such as a fine granularity real time clock.  It's also nice to throw
  into the pot things with at least some bits of entropy such as the
  memory addresses of TSP's and buffers containing packets such as the SYN.

> ...
> As soon as you can guess the entropy pool you can guess the secret and
> attacking the ISN is trivial.

and so the trick is to find sufficient entropy with which to generate
the ISN.

On a 10 MHz Ethernet, packets (including the SYN) arrive with milliseconds
of jitter and so more entropy than you can use for the ISN, provided you
have a clock that ticks microseconds or better.

You still need MD5 to meet the checklists.  MD5 is handy and now fast
enough for mixing whatever you have, including configured secrets, entropy
from disk spindles, clocks, and buffer addresses.

Vernon Schryver    [email-masked]

---

From: Andi Kleen <[email-masked]>
Date: Sun, 17 Sep 2000 16:38:34 +0200

>   memory addresses of TSP's and buffers containing packets such as the SYN.

At least on Linux hashing the addresses of packets in would not help very
much: A SYN data payload is <= 64bytes, so it would always end up in the
same zone of the zone allocator. For 64byte allocations there are only a few
pages in that zone, which are predictable. Brute forcing the possible
addresses in the zone is quite possible (only a few thousand candidates) 
For the brute force attack you only need the ISN of a single SYN.

> have a clock that ticks microseconds or better.

iirc that was proposed but rejected because it could possible allow an
attacker with a sniffer on your local ethernet to maintain a copy of your
entropy pool.

-Andi