On Sun, 26 Sep 1999, Andrea Arcangeli wrote:
> >Such part of the secret should remains constant across lots of seconds so
> >it shouldn't matter if it's zero or the right value for this issue.
> Hmm I think I was wrong. I was focusing on the zero issue. The fact that
> the secret is zero infact is not the real issue as the secret may be zero
> even with the bug fixed. I think the real problem was that they _known_
> the random part of the secret (that _incidentally_ was zero 8).
I think that the implementation of the secure TCP Sequence number
algorithm within the Linux kernel is flawed from ground on.
I agree, using known data (port numbers, addresses) as "secret" data to
hash is false. Instead a good PRNG should be used everytime a sequence
number is needed, independent to any TCP data. Operating systems such as
OpenBSD do have cryptographical safe Sequence number generators, why
should Linux go the unsafe way ?
But again, this advisory shows the general lack of security within the
old protocol suites. TCP Sequence numbers were never meant to be secure, a
32 bit number just cannot guarantee security at all. Later when the first
spoofing vulnerabilities were discovered the reasons of the sequence
number shifted from a "to order data" meaning to a "guarantee security"
meaning.
> Andrea
regards,
scut / teso
-- - scut@nb.in-berlin.de - http://nb.in-berlin.de/scut/ - sacbuctd@ircnet -- -- you don't need a lot of people to be great, you need a few great to be -- -- the best ----------------------------------------------------------------- --- nuclear arrival weapon spy agent remain undercover, hi echelon ----------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/