Security Hole In TCP 184
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.
Not as serious... (Score:2)
This will only fully hijack unencrypted transmissions, and only if the hacker can predict the ISN sequence. It's made easier if the seed isn't random, but it's a long way from being a major threat, and it's not an unknown threat--many TCP/IP stack implementations are not vulnerable.
So...? (Score:1)
(Looks like it worked.)
Re:Random Numbers (Score:1)
I had a look at the site but couldn't see if this was taken into account, unless an allowance is made for this the spread of numbers will change over time. Admittedly this is theoretical and it should be random enough in the short term, but I'm not sure it's random in the long term.
----
Re:"Old as the Hills" (Score:1)
see CERT advisories [neohapsis.com] dating back to 1995... as well as bugraq discussions [neohapsis.com] about it...
This is a very well known "vulnerability". The most famous use of this vulnerability was by Kevin Mitnick to attack Tsutomu Shimomura's computers.
Basically one of Shimomura's unix boxes had root level
Tools like nmap [insecure.org] test for ISN randomness. Just about all unixen are atleast pseudo-random, which makes the attack almost impossible to do to two computers that you can't sniff traffic to or from.
If you can sniff traffic from either box then the problem of hijacking connections becomes much simpler. At this point it doesn't even matter what the ISNs are because you can just sniff them. Tools like: hunt [fsid.cvut.cz] are the preferred tools for session hijacking. hunt even has ARP spoofing so that you can sniff over switched enviornments.
Re:Oh no, not this religious war! (Score:1)
Not that Theoretical - Mitnick did just this (Score:3)
It was a case of IP spoofing against Shimomura. While he couldn't see results (IP spoof after all) the ability to guess ISN's allowed him to play the role of one of the computers involved in the transaction.
Not my original source, but it does make mention of the story [robertgraham.com]
Gaurdent rocks! (Score:2)
Re:Not that Theoretical - Mitnick did just this (Score:3)
Interesting read... in 1995...
Basically one of Shimomura's unix boxes had root level
Re:"Old as the Hills" (Score:2)
Re:Randomness does not exist. (Score:1)
Wrong. Quantum events are inherently random and not predictable. All you have to do is to amplify such events into strings of 0 and 1. One example is radioactive emissions -- if you can keep the source and detector in the range where you count one particle at a time. That's rather difficult to do in a way that's both safe and will keep running without adjustments. Another possibility: resistor shot noise, which originates in the fluctuations as individual electrons pass through the resistor. I am not good enough at analog design to figure out just how to use that, but it should be possible to generate random numbers from shot noise in a small circuit with common parts.
If you are generating pseudo-random numbers entirely from software, then it is predictable, if you can guess the formula used. The simple formulas you'll find in pre-packaged "random number generator" subroutines are probably easily guessed. Go to a cryptographer and you can get formulas that are alterable by plugging in a secret key of hundreds of bits, so even if the basic formula is publicly known, guessing the key takes enormous computer power...
Re:Looks like a pretty standard case to me. (Score:1)
Inital Sequence Number guessing is only useful for spoofing "new" connections or blind spoofing. Thus the "Inital" part of the term. Basically you are blind spoofing communication between A and B (while your are C), to take advantage of some trust relationship between A and B.
As pointed out in many posts this attack was done by Kevin Mitnick. Basically one of Shimomura's unix boxes had root level
Session Hijacking is what you are reffering to. This is taking over an already established connection. In this attack you use the fact that you can sniff or obtain the sequence numbers already in existance by an extablished TCP connection and inject spoofed packets to interupt or tack of that session. Tools suchs as hunt [fsid.cvut.cz] do this type of attack.
DMHO site (Score:1)
Bruce
It's not meaningless, just very old... (Score:3)
But that doesn't mean it's not threatening. On the contrary, it's important to point out that TCP connection resilience is critical to the Internet infrastructure. TCP connections carry the BGP4 inter-ISP peering traffic that routes the backbone.
By and large, there's not a whole lot of meaningful things you can do with TCP spoofing (even RSTs) on a clueful network. But there are infrastructure protocols that rely on TCP and major havoc to be caused if they're disrupted.
There's been an unofficial understanding that router TCP stacks are not very robust. If ingress filtering isn't set up correctly, you can use flaws like this to disrupt peering sessions between routers. This is terrible. But Guardent could stand to be less hand-wavy and more forthcoming about their analyses.
I think Bruce Perens could stand to be a little less glib, and pay a little closer attention. This appears to be valid research, blown out of context by PR. It happens, it sucks, but we shouldn't add to the problem by using the bad PR to obscure the threat.
This isn't news at all. (Score:1)
So, where's the story?
Re:big-ass ad without version (Score:1)
www.goatse.cx, of course!
why did you give them the press they wanted?!? (Score:1)
In other news.. (Score:1)
This is why any reasonable TCP stack uses good random number generators (like our friends
This story is nigh-on useless. Ignore it.
Re:NITROGEN WARNING is similar to TCP/IP warning (Score:1)
-David T. C.
This is out of proportion (Score:4)
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:Randomness does not exist. (Score:1)
Random Numbers (Score:3)
It is kind of like trying to prove something can't be done.
------------
CitizenC
Re:automation K1DD33z (Score:1)
Umm, when was the last time you saw a scr1pt k1dd13 tool posted to 2600. DeCSS, arguably (and I would argue not, but whatever). 2600 is more of a political/news site, not a script kiddie outpost.
------
Re:Randomness does not exist. (Score:1)
Re:Random Numbers (Score:1)
Re:Randomness does not exist. (Score:1)
Re:NITROGEN WARNING is similar to TCP/IP warning (Score:2)
Christ why are people modding this as funny! It should be +5 Insightful! Spread the word!
Re:Automatic hijacking tools... (Score:1)
Sloppy thinking. All traffic is data, though some is transmitted in larger bursts than other. A TCP connection carrying Telnet data (not a "terminal session") is the textbook example of traffic that should be buffered using Nagle's algorithm to avoid sending one packet per octet. The user's keystrokes will determine how far the outgoing sequence number is eventually incremented (unless the client does Telnet negotiation or sends urgent data), but guessing how many octets the server will respond with is another problem (as is preventing the client from resetting the connection once you've injected more than one window of data).
Re:guessing a tcp sequence isnt *THAT* hard... (Score:1)
Windows 2000 Workstation:
TCP Sequence Prediction: Class=random positive increments Difficulty=232626 (Good luck!)
Windows 2000 Server:
TCP Sequence Prediction: Class=random positive increments Difficulty=22436 (Worthy challenge)
Didn't have a Windows 9x box handy to try it out on but maybe this is what you have done.
I assume this must change after every nmap, but why would the workstation be seemingly more secure than the server machine? I guess that's just Microsoft's way of doing things... The other curious thing I stumbled upon is the fact that the Windows 2000 Workstation was not recognized by this scan, it returned that no OS matched the host. Maybe this explains why it is so high, maybe it isn't Win2K after all, mind you I seem to be using the machine at the moment. Hmmmm......
Your street has a security hole! (Score:2)
So lock the door, dummy.
I'm no expert on TCP, but I think that anyone who cares about security at all already knows that it's not secure, it was not designed to be secure, and it never will be secure by itself. If you need security, you pile it on top of TCP/IP, by encrypting packets, etc.
"Old as the Hills" (Score:2)
So, is this really a big deal?
(btw - fp.)
Re:Random Numbers (Score:1)
Re:Random Numbers (Score:1)
--
Re:Random Numbers (Score:1)
This guy [fourmilab.ch] is already doing that for free
--
Re:Random Numbers (Score:1)
That depends entirely on how you define a "random" number. If you want to be a big philosopher and claim that nothing is "random", be my guest (BTW, Quatum Mechanics guarantees that there is real, true randomness in the world - presuming it's possible to sample that).
I (and most people working on crypto in academia [which I am not one of, but just pointing out there are plenty of informed people who think this]) adopt the more practial view that if there does not exist a polynomial time algorithm to decide if a given string is truly random or the output of the random number generator, it's "random". There are plenty of things that will do this just fine.
It is kind of like trying to prove something can't be done.
Huh? There are tons of things you can prove cannot be done. For example, I can prove that you cannot possibly find a integer n such that 2*n+1 is evenly divisible by two. Could you please explain what you meant by this?
In fact, there are things such that you can provide proofs for both of the following:
1) It is not possible to prove that X exists.
2) It is not possible to prove that X does not exist.
An example is an existence of a set S such that |N|<|S|<|R| (where N is the natural numbers and R is the real numbers).
Re:Random Numbers (Score:1)
All computer based random number generators are psuedo-random, which is considered to be "good enough", especially when you can get a seed from some semi-random source, such as the computers clock
But getting back to the story, these poorly implemented TCP stacks are not evenly remotely close to being random.
---
This is news, how? (Score:1)
"This is extremely difficult to do. It's a theoretical attack," said security expert Steve Gibson, of Gibson Research Corp. in Laguna Hills, Calif. "It's weird that they're talking about something like this. It's as old as the hills."
And that's from the article, itself...
At least Guardent (or what ever it is..) suckered ZDNet into giving them some space in the news hole...
t_t_b
--
I think not; therefore I ain't®
Re:RFC1948 (Score:4)
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 (Score:4)
NITROGEN WARNING is similar to TCP/IP warning (Score:5)
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:Looks like a pretty standard case to me. (Score:1)
Really, Bonker, is it necessary to insult our fellow primates, the Chimpanzees, by comparing them (even favorably) to a group of attention-hounding, press-seducing, history-ignorant, technogonadless marketers?
Re:"Old as the Hills" (Score:5)
Re:Which other protocols *also* have holes? (Score:1)
2.1.53 would have been an unstable kernel anyway. SMB is bloated all on it's own, made worse by Microsoft. How could it not have huge, unknown bugs?
------
Re:Random Numbers (Score:2)
There is a new issue. (Score:1)
In other news (Score:2)
Re:Which other protocols *also* have holes? (Score:4)
I see *you've* never taken measure theory (Score:2)
> I mean - technically nothing can ever be absolute (we can't be sure
> 1+1==2; we've just observed it throughout all of recorded history)
Oh yes, that's been proved. Take a graduate measure theory course, or maybe even an upper division undergraduate theory course. You start with the notion of a "something"--a scratch, a stick, a whatever, and build from there.
On the other hand, proving that an observed phenomenon actually corresponds to the derived "1" or "2" is another matter, but you can certainly prove 1+1=2 from the ground up . . .
hawk
Re:Is this really a problem? (Score:1)
You're talking about pseudorandom numbers there. Random numbers simply cannot be "generated". Although there are several secure pseudorandom number generators, but one shouldn't mix them with real randomness. (Take the unix C random() for example, it's initialized with 32 bits and thus it's entropy can never exceed that. Same goes for famous stream cipher RC4 (the internal state is 256bytes but still) and all others aswell.
To create truly random numbers one needs an entropy source. Computerwise there are few handy ways to get real entropy into the pseudorandom number generators, here are few examples
1) They sell hw cards that have cold radioactive sources and detectors in them. Radioactive decay after all is as random as it gets.
2) Unplugged line-in jack has static which has several random bits in it. When undisturbed, it can be concidered random.
3) The already mentioned web cam pointed to a lava lamp.
4) On UNIX systems the process table can be concidered to have some randomness in it, but one shouldnt screw up with that one either. It has atmost 10-20 bits of randomness when also measured relatively seldom.
5) User key typing or mouse motion
Re:This is NOT new nor is it news... (Score:1)
Now we know that it is merely these 'packet IDs'. I'm sure many people have pointed out that guessing these is not really much of an attack, as spoofing packets is nothing new, and people use encryption for anything important -- and encrypted data is not vulnerable to this attack.
Re:Uh... Isnt this an old hole? (Score:1)
Again, IIRC, OpenBSD's stack uses some of the best random numbers (as shown by nmap when it tries to predict the OS of the target.)
Other than that, thanks :) I was curious as to why OpenBSD was rated so much lower. (although it's all relative)
Background research for slashdot? What a strange idea. :)
Re:guessing a tcp sequence isnt *THAT* hard... (Score:2)
You know... if you're gonna mask out the ip, better mask out the host name as well cause DNS doesnt lie! (Well, usually it doesn't)
Re:Uh... Isnt this an old hole? (Score:2)
#nmap -O hostname
OpenBSD 2.8:
TCP Sequence Prediction: Class=random positive increments
Difficulty=28836 (Worthy challenge)
Remote operating system guess: OpenBSD 2.6
Digital (Tru64) UNIX 4.0F:
TCP Sequence Prediction: Class=random positive increments
Difficulty=355 (Medium)
Remote OS guesses: Digital UNIX OSF1 V 4.0,4.0B,4.0D,4.0E, Digital UNIX OSF1 V 4.0-4.0F
Linux 2.2.18:
TCP Sequence Prediction: Class=random positive increments
Difficulty=3738947 (Good luck!)
Remote OS guesses: Linux 2.1.122 - 2.2.14, Linux kernel 2.2.13
I don't have much else to test, but it seems to me that the Linux TCP/IP stack uses significantly better random numbers than OpenBSD, as shown by nmap. I'd wager some others do too.
guessing a tcp sequence isnt *THAT* hard... (Score:3)
A simple run on a freebsd 4.2 box yields:
[1:37pm] root # nmap -O boris
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on boris.ST.HMC.Edu (134.173.xxx.xxx):
(The 1513 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
80/tcp open http
110/tcp open pop-3
111/tcp open sunrpc
143/tcp open imap2
587/tcp open submission
3306/tcp open mysql
TCP Sequence Prediction: Class=random positive increments
Difficulty=17911 (Worthy challenge)
note: random positive increments
Now, the same scan on a win2k box yields:
[1:40pm] root # nmap -O skittles
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on skittles.ST.HMC.Edu
(134.173.xxx.xxx):
(The 1518 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
80/tcp open http
81/tcp open hosts2-ns
139/tcp open netbios-ssn
3306/tcp open mysql
TCP Sequence Prediction: Class=trivial time dependency Difficulty=2 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98
Thus, guessing tcp sequences isnt entirely difficult for windows 9x boxen, its just that its generally easier to exploit other problems than play with tcp stacks.
Re:Randomness does not exist. (Score:2)
Usually it's quite sufficient to feed your pseudo-random generator a new seed every few minutes. Actually, even that is usually overkill, but now we're getting to the practical rather than truly random.
Caution: Now approaching the (technological) singularity.
Re:I see *you've* never taken measure theory (Score:2)
1 cup water + 1 cup alcohol 2 cups 50% alcohol in water. (Perhaps it's 1 3/4 cup of fluid, something like that.)
1 cloud + 1 cloud = 1 cloud
300 degrees + 61 degrees = 1 degree (angular)
And there's also something about a maximum temepature where the scale falls apart because the particles are at relativistic speeds.
I'm sure that there are other cases, but those are the only ones that occur off hand. In each case we wiggle the definition so that normal addition rules don't have to apply.
OTOH, 1 apple + 1 orange = 2 pieces of fruit. So you can add apples and oranges.
Caution: Now approaching the (technological) singularity.
Re:NITROGEN WARNING is similar to TCP/IP warning (Score:2)
Or it could have something to do with the fact that DHMO is otherwise known as water.
ObJectBridge [sourceforge.net] (GPL'd Java ODMG) needs volunteers.
Re:"Old as the Hills" (Score:2)
The www does NOT mean the internet, the two terms are NOT interchangeable, despite what "Wired" magazine insists.
Re:Looks like a pretty standard case to me. (Score:4)
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 (Score:3)
www.fourmilab.ch/hotbits/ [fourmilab.ch]
The guy has a geiger-muller tube pointed at a radioactive source. The time between detected events is random. Really random.
--
#include "stdio.h"
Re:Random Numbers (Score:3)
I don't know which side of the argument you were on, but whoever said it is "impossible" is really really wrong. It's actually quite trivial.
More importantly, it's rarely useful to argue about the difference between a truly random and a pseudo-random number. This TCP story is one of the vast number where good pseudo-random numbers are plenty adequate.
--
Re:Random Numbers (Score:2)
It doesn't have to be truly random, it just has to be random enough to provide the required level of unpredictability. As long as the TCP numbers are random enough that this attack is no longer the easiest attack to make, or else that an attack on the randomness carries X level of difficulty (time, space, etc.), then your numbers are good enough in the real world. This is probably doable on a router, especially if you add custom HW to sample entropy from the environment.
simlar security hole in *every* os (Score:3)
(taco, your lameness filter sucks)
SERIOUS VULNERABILTY AFFECTS ALL VERSIONS OF UNIX AND WINDOWS
A serious vulnerability has been found in all versions of
Unix and Windows. This problem most likely affects all
other systems as well.
It has been found that computer systems must be physically moved
prior to installation at a computing facility. Moreover,
when these systems are transported, they are usually moved
at some point by human beings.
Obvious insecurity Inc. has found that a serious DOS attack
can be waged on these systems when attackers stand on top of a building
high above the area where a system is being moved at the proper
time interval.
The attackers toolkit consists of a long range flamethrower,
a large sledgehammer, and concussion grenades. If the attacker
has perfect timing, they may drop the sledgehammer/light the
flamethrower/drop the grenade onto the target system in
question, thereby creating a DOS condition.
This scenario can be spread easily through a coordinated
attack, but this has yet to be seen in the wild.
Vendors have been notified 1.5 minutes ago, but have so
far proven that they are incompetent by not releasing
patches or sending a reply to our email. Therfore, in
the interests of full disclosure, we are making these
shocking results public, since YOU have a right to know.
This earth shaking, trend setting vulnerability has been
discovered by Obvious Security Inc. We hope to overwhelm
bugtraq and the other lists with our skills so we can
make more money and have more prestige in the computer
security industry.
Remember - "Just because it's right in your face, does
not mean that it's obvious".
Obvious Security Inc. Bulletin #2600
Re:Random Numbers (Score:4)
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 (Score:5)
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 [sgi.com] 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"
Whatever (Score:2)
Let me get this straight. (Score:2)
Hello? When was this not known? Tell us something we don't know!
Linux for instance uses random positive increments. No number is truly random, but many are "random enough".
That is to say, it's Really Hard to predict the port number, hard enough that trying some other vounerability would be more rewarding.
This is a non-story. Hackers and security experts have known about this so long that many have probably forgotten it several times by now. All this muckrake serves to do is alarm the chicken littles.
Fun with NMAP TCP Sequence Prediction. (Score:4)
---- 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.
---
Randomness does not exist. (Score:3)
Yes, it's incredibly difficult to generate random numbers. Isn't it impossible? Consider this. ALL events can theoretically be traced back to a specific cause. If you ask a human to give a random number between 1 and 10, the outcome is a result of many psychological factors that predisposed that person to respond with a certain number. Likewise, if you were to go back to the beginning of the universe, and move a few molecules, you'd change the outcome. Therefore, how can anything be truly random. We can have unexpected outcomes, but if you look at the big picture, you can trace results back to causes.
So, to put this on topic, in reference to your second point... it's difficult to generate random numbers - especially on computers. :-) However, we CAN generate psuedo-random numbers. *chuckle*
Re: (Score:2)
Re:Random Numbers (Score:5)
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.
Re:Randomness does not exist. (Score:2)
All is not lost, however. Quantum mechanics, for instance, (if you believe it) shows that the randomness behind subatomic particle motion (like electrons in their orbits) and the like demonstrates a sort of 'deep cosmic chaos.' Thus, for instance, the decay of radioactive stuff is truly unpredictable, so it's not impossible to come up with numbers that are both random and unpredictable.
Re:Random Numbers (Score:2)
It's an academic point.
Re:Is this really a problem? (Score:2)
Because it's been fixed for quite a while in most OSes. There are still some [securiteam.com] exceptionally stupid OSes that are vulnerable to it, but nobody who knows beans about security uses them.
-
Use of the media (Score:2)
Version without big-ass ad (Score:5)
Re:Random Numbers (Score:3)
radioactive decay random-number generator [fourmilab.ch]
atmospheric noise random-number generator [random.org]
--Blair
"Nineteen billion bits can't be wrong!"
Alarming number of articleizements (Score:2)
-- Greg
Solution: (Score:2)
--
Looks like a pretty standard case to me. (Score:4)
Way to go guys! Before, I didn't who you were. Now I know you're a complete bunch of retarded chimpanzees!
Re:Random Numbers (Score:2)
With a sufficient number of hosts connecting the numbers you get back should be about as random as you can get.
Hey, I could even charge a micropayment each time somebody connects.
Anybody interested in a new '.com' venture ?
Re:Random Numbers (Score:2)
I think you may have missed the point of your CS teacher's argument.
Yes, it is impossible to generate a truly random number using a simple mathematical formula. That's why these are all referred to as "pseudo-random number generators." The numbers they produce look random, but if you continue to generate numbers using the same function, it will eventually repeat itself.
However, it is possible to design random number generators that can actually generate random numbers. /dev/random on Linux is an example of this. It samples the times of the user's keypress and mouse movements (actually the time specific interrupts occured, but its basicly the same thing) along with other random sources to produce real random numbers. There is also specialized hardware that will listen to atmospheric noise and background radiation to producte random numbers as well.
Now, back to the point of this topic: TCP sequence number prediction. As someone else has already pointed out, this vulnerablity has been known about (and fixed) since 1996. The above mentioned /dev/random device has been used internally by the TCP/IP stack in Linux to generate cryptographically secure random initial sequence numbers for some time now.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Re:Is this really a problem? (Score:3)
It has been... Mitnick used it, in fact, to get rootshell via rshd, which does authentication via ip adressing, which you can spoof using the TCP sequence attack.
Kspett
Re:automation K1DD33z (Score:2)
Should read: Security hole in some IMPLEMENTATIONS (Score:2)
My guess would be that someone out there found a particular implementation that had this problem and from there, started asking questions about if the problem exists in other implementations.
If the TCP protocol standard specifies that the ISN needs to be 'random', or at least a good psudorandom, than this is a failure of the implementation if it does not follow that spec, NOT a statement that 'TCP', as a protocol, has a security hole.
Re:Proving something can't be done (Score:2)
Re:Randomness does not exist. (Score:5)
> 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:Is this really a problem? (Score:2)
A bit of digging found the tool HUNT [fsid.cvut.cz] which exploits the problem.
Re:Which other protocols *also* have holes? (Score:2)
SMB is a security hole!
--
Re:"Old as the Hills" (Score:5)
Microsoft: That vulnerability is completely theoretical
l0pht: Making the theoretical practical since 19XX
RFC1948 (Score:5)
Other important news (Score:2)
Re:NITROGEN WARNING is similar to TCP/IP warning (Score:2)
Ah, but how would we know it's the real Bruce Perens speaking to us?
-
Re:Not that Theoretical - Mitnick did just this (Score:2)
And yeah, that was a few years ago.
Re:NITROGEN WARNING is similar to TCP/IP warning (Score:3)
#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak
Re:"Old as the Hills" (Score:2)
Is this really a problem? (Score:2)
if the ISN is not chosen at random or if it is increased by a non-random increment in subsequent TCP sessions, an attacker could guess the ISN
OK, so there is a random number known only by either end of a TCP session. If the number is not random, then a hacker could guess the number and spoof packets.
Two questions - 1) if this "problem" has been around since the mid-80's why has it never been exploited?
2) How hard can it possibly be to generate a random number, even for a simple OS installed in a router?
This problem to me seems to be a non-problem, but you networking gurus might have a different story.
Re:Is this really a problem? (Score:2)
--------
automation K1DD33z (Score:2)
Or maybe it's a vieled attempt by Microsoft to discredit TCP/IP so they can get the whole world to switch back to NetBEUI and WINS.
Which other protocols *also* have holes? (Score:3)
Even Linux 2.1.53 had a massive TCP/IP-stack hole, so we know we're not invulnerable. This isn't just a problem for others.
FRAUD (Score:3)
Anyway, this company has "discovered" that if ( a big if) you can predict the ISN of a remote host you can (gasp!) hijack/spoof a TCP connection. Gee, I think I heard about that in 1985. This was on ZDnet this morning and they have since changed their story to reveal just how old and well known this really is.
I know there was 1989 paper on this exact subject by AT+T, try searching for it.
Also, try using nmap on any host today. See how it says "truly random" for many many of them (including linux), that is why this vulnerability means nothing in practice. Practically every OS under the sun has good enough random ISN's that no one is going to correctly guess them.
This is just another security firm trying to get some contracts by issuing a big scary press release.
Please.