Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
The Internet

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.
This discussion has been archived. No new comments can be posted.

Security Hole In TCP

Comments Filter:
  • ...as it is being made out to be.
    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.
  • by arfy ( 236686 )
    Yet another security vendor tries to get press by reminding everybody of something that's been out there for years.

    (Looks like it worked.)
  • The time between detected events is random. Really random.
    But with radioactive decay the decay rate decreases over time (the mean time between events increases over time).
    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.
  • As a computer security consultant, this story seems silly to me.

    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 .rhost that trusted another one. Kevin spoofed packets from the trusted computer to execute a "echo '+ +' >> /.rhosts" then just rlogin. To help the attack Kevin also SYN flooded the the trusted computer so that it would not respond with RST packets. This type of attack is called blind spoofing and is usually difficult to do. There are programs out there that will do this. ie: ADM-rsh [freelsd.net]

    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.

  • I'd have to ask for a reference on that one. I've seen several arguments, including Bell's Inequality, but none which make so broad and definitive a statement. (ex: this [nec.com])
  • Unfortunately I do not have my source, but if I remember right Mitnick did a smurf just like this to execute a blind man in the middle attack.

    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]

  • Wow, good thing we have a company like Gaurdent around. They also found a hole in gopherd:
  • by wavelet ( 17885 ) on Monday March 12, 2001 @03:45PM (#368587)
    Tsutomu Shimomura's book's webiste, Takedown [takedown.com] has some transcripts of the attack. [takedown.com]

    Interesting read... in 1995...

    Basically one of Shimomura's unix boxes had root level .rhost that trusted another one. Kevin spoofed packets from the trusted computer to execute a "echo '+ +' >> /.rhosts" then just rlogin. To help the attack Kevin also SYN flooded the the trusted computer so that it would not respond with RST packets. This type of attack is called blind spoofing and is usually difficult to do. There are programs out there that will do this. ie: ADM-rsh [freelsd.net]
  • ... Since 1992. l0pht was one of the first sites to discuss (and expose) security issues publicly on the Web (other than CERT).
  • ALL events can theoretically be traced back to a specific cause.

    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...
  • I think you're confusing two different security concepts.

    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 .rhost that trusted another one. Kevin spoofed packets from the trusted computer to execute a "echo '+ +' >> /.rhosts" then just rlogin. To help the attack Kevin also SYN flooded the the trusted computer so that it would not respond with RST packets. This type of attack is called blind spoofing and is usually difficult to do. There are programs out there that will do this. ie: ADM-rsh [freelsd.net]

    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.
  • Excellent site! I started thinking about the nitrogen issue while the city of Berkeley was funding efforts to close down the nearby Tritium lab at Lawrence Berkeley Laboratories. I will be in Great Britain in April and will be sure to bring home some tritium light keychains to piss off my neighbors.


  • by tqbf ( 59350 ) on Monday March 12, 2001 @01:32PM (#368592) Homepage
    This problem is old. Even in the context of Cisco routers. Mudge@L0pht testified about basically this exact problem in front of congress a few years ago, and even then it was old hat.

    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.

  • Okay, I understand that fluff editors sometimes let old news in (especially if it sounds scary) but did Hemos read the article? It even says it's a well-known vulnerability which has been addressed by recent software.

    So, where's the story?

  • ...and we all know where to find the 'big ass without add'-version, don't we?

    www.goatse.cx, of course!

  • This is just some company's PR trying to get themselves noticed. This is NOT A NEW DISCOVERY (as many others have already pointed out).
  • L.Ron Bumquist of the ETLA Group today announced that he had found a major vulnerability in nearly all home security systems. If the security system is made from delicious Norwegian Jarlesburg cheese instead of wires and computer chips and stuff, a potential burglar could enter the house undetected.

    This is why any reasonable TCP stack uses good random number generators (like our friends /dev/random and /dev/urandom) for choosing and incrementing TCP sequence numbers.

    This story is nigh-on useless. Ignore it.
  • Just because you can get it a catchy and unthreatening name like 'water' doesn't make it any less deadly. I mean, I can call 'dense combinations of DHMA vapor, CO, CO2, and unburned hydrocarbons trapped by atmostspheric inversion' 'sparkle' instead of 'smog', but that doesn't make it any more breathable, does it?

    -David T. C.
  • by Geoff NoNick ( 7623 ) on Monday March 12, 2001 @12:33PM (#368598)
    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.


  • Thanks guys, two good resources there for anyone who needs _really_ random numbers.
  • by citizenc ( 60589 ) <cary@glidedesi g n . ca> on Monday March 12, 2001 @12:33PM (#368600) Journal
    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.

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

  • 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.


  • Things are not random at the quantum level. We have been able to prove that. The problem with the quantum level is that they fall below our significant digits and thus, we have a tendency to round it off and treat it as random. If you go down infinitely far, it is 100% predictable. The problem is, who really wants to go down that far to predict the exact number a person is going to pick from 1-10.

  • The lava lamp is predictable on the sub-atomic level so your theory would be shot down. I wrote a random number generator in one of my Electrical Engineering classes using static from AM radio wave signal. This is still predictable if one really wants to get down to it but lacks predictability when dealing with higher level maths.
  • Actually, thigs are *fundamentally* random at the quantum level. The exact position of any given particle is not exact - it is a probability wave.
  • 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.

    Christ why are people modding this as funny! It should be +5 Insightful! Spread the word!
  • by Anonymous Coward

    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).

  • Although it is fun to pick on Microsoft and Windows, these are not the results I recieved when nmapping win2k boxes.

    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......
  • Just about anyone can drive down it, right to your door!

    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.
  • From the article: "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."

    So, is this really a big deal?

    (btw - fp.)

  • You need it to be attached to an atomic radiation source.
  • Build one yourself [fourmilab.ch].

  • You'll be entering the 'market' a little late:
    This guy [fourmilab.ch] is already doing that for free :)

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

    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|&lt|S|&lt|R| (where N is the natural numbers and R is the real numbers).
  • "Generated" and "true random" are oxymorons. How can any generated number be random? If it was generated by an algorythm, and can be generated again.

    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.


  • "...And because the flaw has been known for so long, it's unlikely that there are many TCP implementations that are still vulnerable to such attacks.

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

    I think not; therefore I ain't®

  • by Anonymous Coward on Monday March 12, 2001 @01:47PM (#368616)
    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.
  • 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.
  • 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.


  • ...you're a complete bunch of retarded chimpanzees

    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?

  • by SEWilco ( 27983 ) on Monday March 12, 2001 @12:36PM (#368620) Journal
    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.
  • 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?


  • by Anonymous Coward
    Quite possible. all you need is an external noise source.
  • by Anonymous Coward
    These people are obviously lame and trying to get fame reposting twenty year old stuff. There is, however, another issue that hasn't been addressed. There are only 2^16 possible sequence numbers. When we all used 64K links, you could only guess a few of them, but as everyone moves to fatter pipes, you get more guesses. On an OC-48 is becomes almost deterministic to guess the sequence number.
  • Urizon Technology released a security advisory today outlining the potential pitfalls for security telephony. "Why, just any joe with a Radio Shack speaker-amp and a pair of clip leads can walk up to a patch panel and evesdrop on phone calls!" reported Clive Doppler of the "Urizon Group Grappling with Security" (UGGS) department. Urizon stock closed at 47.46, down 0.28.
  • 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/

  • > 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 . . .

  • 2.) How hard can it possibly be to generate a random number, even for a simple OS installed in a router?
    ...don't usually do the work needed to create an unguessable (secure) random number...

    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
  • It is nice to have somebody actually explain what is going on, and describe how an attack would work tho. For years, nmap has spat out this 'sequence prediction', 'difficulty', and an accompanying description,and nobody had any idea what it was, and the nmap docs never mentioned it either, but it took up most of nmap's output so it looked pretty important.

    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.
  • From the post I responded to:

    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. :)

  • Interesting ports on boris.ST.HMC.Edu (134.173.xxx.xxx):

    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)
  • Hmm, let's test a few of my machines...
    #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.

  • by b0r1s ( 170449 ) on Monday March 12, 2001 @12:40PM (#368645) Homepage
    take nmap, for example.

    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
    (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.
  • Hardware random number generation is pretty easy. Just amplify the thermal noise and use that as a driver signal. It appears to be totally random, and sufficiently dense to create a lot of new keys. You could also monitor the background radiation. If you just need a short key and don't want to hardware hack (I sure don't), monitor the time between keypress events, or disk accesses (whatever's easy, fast, variable, and unrelated to the problem).

    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.
  • Actually, it's only true by definition. I.e., if 1 + 1 doesn't equal 2, then we say that the operations are inappropriate. E.g.:

    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.
  • Its a sad fact that people confuse whistleblowers as members of heretic movements. A real problem exists with the popular media who marches with the party line of accepted politics and debate while straying from the natural sciences. Our world is going to become a sad state of affairs and in dire need of help when the burden of task becomes too great for us as a society. I'm here to say its time to write letters and get the word out.

    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.

  • The web...in 1992...sigh.

    The www does NOT mean the internet, the two terms are NOT interchangeable, despite what "Wired" magazine insists.

  • by Cramer ( 69040 ) on Monday March 12, 2001 @02:02PM (#368659) Homepage
    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.
  • by Anoriymous Coward ( 257749 ) on Monday March 12, 2001 @06:06PM (#368661) Journal
    If you need a random number, go here:

    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"
  • by rw2 ( 17419 ) on Monday March 12, 2001 @12:42PM (#368665) Homepage
    I actually had a rather lengthy argument with my computer sciences teacher about this -- it is impossible to generate a truely random number.

    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.


  • 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.

  • by peterjm ( 1865 ) on Monday March 12, 2001 @12:43PM (#368668)
    gotta say, this hole really reminds of a message that was recently forwarded to bugtraq.
    (taco, your lameness filter sucks)


    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
  • by pafein ( 2979 ) on Monday March 12, 2001 @12:44PM (#368669) Homepage
    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.

  • by Fatal0E ( 230910 ) on Monday March 12, 2001 @12:51PM (#368670)
    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 [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"
  • And in other news...Security expert Joe Blow made the stunning annoucement that theoritically peoples Unix accounts could be hacked if the chose a word in the dictionary. Joe say, "Yes I know this has been known for some time, and most Unix implementations take care not to allow dictionary words, but I just wanted to be safe and let others know of my discovery". Joe Blows comany, Obvious Fixes, sells software to resolve this issue.
  • So they're saying that if you can predict the port number that will be assigned to a session, you can hijack it?

    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.

  • by e_n_d_o ( 150968 ) on Monday March 12, 2001 @12:52PM (#368677)
    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.

  • by Gendou ( 234091 ) on Monday March 12, 2001 @12:52PM (#368679) Homepage
    2) How hard can it possibly be to generate a random number, even for a simple OS installed in a router?

    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*

  • True.

    But, for the purpose of cryptography, what's important is perspective.

    That is, from any given perspective (ie: the user which is trying to predict the next number in a sequence), if the next number cannot be determined (because information which led to that number is unavailable, such as seed generated from keyboard interrupts), the data can be considered truly random.

    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) so long as time is not infinite (which is also difficult to prove ;). So, if we are going to round up probabilities to absolutes, randomness is best considered from a specific perspective (in which case we can say, for someone, "this data is truly random").

    All men are great
    before declaring war

  • by Mihg ( 2381 ) on Monday March 12, 2001 @06:50PM (#368687)
    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.
  • Something that I think a lot of people are missing is the difference between randomness and unpredictability. A computer can generate random numbers (digits of pi satisfy all known tests for randomness quite handily) easily. What it cannot do is generate unpredictable or chaotic numbers (because all pseudo-random number generators use a seed, and the seed will always give the same sequence).

    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.
  • True, but radio noise tends not to be truly "white" (ie containing pretty much all sine waves in minute amounts), but statistically pretty damn skewed. Add to this the quantisation that occurs due to the sampling process, and you have only a random-ISH quantised and statistically trackable 'field' of numbers. I'd say though that actually guessing the bugger'd still be pretty damn impossible, short of knowing something 'secret' about the sampling process.
    It's an academic point.
  • Two questions - 1) if this "problem" has been around since the mid-80's why has it never been exploited?

    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.

  • Here is my plan...I am going to start a security company and point out problems that everyone already knew about (And professors at half decent schools have pointed out in lectures)...using the media for publicity. Then we can watch every site gobble up a story on how our company cracked it.
  • by sulli ( 195030 ) on Monday March 12, 2001 @12:47PM (#368702) Journal
    is here [zdnet.com].
  • by blair1q ( 305137 ) on Monday March 12, 2001 @12:55PM (#368705) Journal
    Your CS professor was wrong:

    radioactive decay random-number generator [fourmilab.ch]
    atmospheric noise random-number generator [random.org]

    "Nineteen billion bits can't be wrong!"
  • Is it me or does it seem like there are many more advertisements disguised as articles. They feature predominantly a re-release of some non-news that's years old by some guy who happens to run a company in the field related to the particular non-news. Seems like I see alot of this from security companies mostly some 'drastic new flaw in IP' and guess what, the CEO featured in the article has a magic panecea he'll sell you to make the non-issue go away. *sigh*

    -- Greg

  • let's all switch to UDP (a better protocol IMO)
  • by Bonker ( 243350 ) on Monday March 12, 2001 @12:27PM (#368716)
    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!
  • I've always wanted to set up a site called 'internetrandomnumber.com'. Basically the idea would be you connect to either 'long.internetrandomnumber.com' or 'int.internetrandomnumber.com' and all the site does is returns a 'random' number in the requested format.

    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 ?

  • 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.
  • by kspett ( 75618 ) on Monday March 12, 2001 @12:49PM (#368725)
    1) if this "problem" has been around since the mid-80's why has it never been exploited?

    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.

  • I was using 2600 (as opposed to other sites like l0pht or what have you) as a tool to indicate the cluelessness of the writer of the article.
  • If you read the article carefully, it says that this could be used to exploit TCP stacks that use a POOR or PREDICTABLE random number generator to generate the ISN. It also says that because this has been known for so long, there are questions about if there are any TCP stacks around that are exploitable.
    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.
  • It's easy to prove that something can't be done. Just assume that it can be done, and show that this assumption leads to a contradiction.
  • by hawk ( 1151 ) <hawk@eyry.org> on Monday March 12, 2001 @01:07PM (#368733) Journal
    > 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

  • 1) Is this "problem" has been around since the mid-80's why has it never been exploited?

    A bit of digging found the tool HUNT [fsid.cvut.cz] which exploits the problem.

  • What security holes lurk in SMB, for example?

    SMB is a security hole!

  • by wunderhorn1 ( 114559 ) on Monday March 12, 2001 @12:28PM (#368739)
    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

  • by johnburton ( 21870 ) <johnb@jbmail.com> on Monday March 12, 2001 @12:28PM (#368740) Homepage
    RFC1948 which is 5 years old described this problem and how to solve it.
  • And in other news, the Berlin Wall has come down! WW II ended! These guys are only about 15 YEARS late on this discovery. Must have been really hard work reading those old papers about the topic.
  • Have Bruce Perens Speak at Your Conference! HP Sponsors All expenses!

    Ah, but how would we know it's the real Bruce Perens speaking to us?


  • If you check out the book that Shimomura wrote with John Markoff, Takedown (ISBN: 0786862106) he talks a little bit about the attack and the work he did to figure the whole thing out. He also mentions that he gave a lecture on the attack method at some conference shortly before they actually captured Mitnick.

    And yeah, that was a few years ago.

  • Even more hilarious is the DHMO.org [dhmo.org] website. A thinly veiled crack at the MSDS (Material Safety Data Sheet) phenomenon... even though I'm an ex-environmental lawyer I found it funny.

    #include "disclaim.h"
    "All the best people in life seem to like LINUX." - Steve Wozniak
  • A well-known security expert claiming that a vulnerability is theoretical carries a lot more credibility than a Mickeysoft PR drone doing spin-control on one of their brain-damaged products. Consider the source and their motives: Gibson has nothing to gain or lose if a specific vulnerability is practical to exploit or not. Mickeysoft, on the other hand, has a great deal to lose if one of their products has a hole, and has a lot to gain if a competing product has a hole that their's does not. [As if M$ has any credibility in the security arena to begin with]

  • From the article:

    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.

  • Why are you sure it was Mitnick?
  • It's not that this problem is new, or potentially really bad on it's own, but it's that they're afraid that as soon as hackers post tools to 2600, all the script kiddies will go out and exploit it, because currently, nobody's hitting this one, because it's too difficult for most people to grasp.

    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.
  • by alewando ( 854 ) on Monday March 12, 2001 @12:30PM (#368758)
    It goes without saying that TCP is one of the fundamental protocols billions of dollars of internet infrastructure and other businesses rely on. If it could happen to TCP, then which other protocols are vulnerable to similar problems? What security holes lurk in SMB, for example? Will we ever know?

    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.
  • by Anonymous Coward on Monday March 12, 2001 @12:30PM (#368760)
    Ok I submitted a much clearer picture of this story, but apparently that didn't get posted.

    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.


"Plastic gun. Ingenious. More coffee, please." -- The Phantom comics