Slashdot Mirror
Graphing Randomness in TCP Initial Sequence Numbers
Saint Aardvark writes "This is neat: Graphic visualization of how random TCP Initial Sequence Numbers really are for different OSs. It's a great way of seeing how secure a TCP stack really is. Cisco IOS is great; OS9, OpenVMS and IRIX aren't. Posted to the ever-lovin' BugTraq mailing list." This is a follow-up to the previous report.
He must be running a server with no tcp stack. heh.
I propose a new flag in the standard TCP/IP packet. We shall call this the Slashdot Flag. The general purpose of this flag is to state whether or not the bandwidth limits of the server can handle the requirements a Slashdot posting can impose. If the flag is set false, Slashcode will automatically generate numerous, random, 'this page has been slashdotted' posts requesting a link to a mirror.
That being said, the page *is* finally loading up so I'm going to go look at some pictures now.
tinfoilmedia
Original report here:
t ml
http://razor.bindview.com/publish/papers/tcpseq.h
You will find the original report here, and you might like to check out the linux section. Credit to a previous poster for that link, however.
Try NetBSD... safe,straightforward,useful.
Comment removed based on user account deletion
>certainly more common than many of the other
>selections.
>
>Should we assume Linux matches *BSD or some other
>flavor? or do I need to read more carefully
You need to read more carefully.
"Please could you violate the site's copyright before posting the story"
although "please use server xxx.xxx as the proxy" for submissions could be a solution
could even set up Apache to do that on a url therefore subtly circumventing the copyright problem, banners could be passed through.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
But it is still a nice article, illustrating Knuth's advice simply to plot random numbers to visually quickly judge the quality of a pseudo random number generator.
Lets face it: current computers and humans are both as bad as each other at randomness. The fact that computers have to "calculate" randomness is a bad sign in itself, and the humans that program these computers are almost utterly incapable of perceiving true randomness anyway. I'm waiting for the day when the national lottery comes up 1,2,3,4,5 with a bonus ball of 6. Society will crumble, public enquiries will be called for and conspiracy theorists will have something to bang on about for years. I think that barring the sudden development of Quantum x86 chips (at which point randomness becomes "real" and encryption becomes pretty much unbreakable), the only real solution for decent randomness must surely be TCP/IP seeding based on Lava Lamps
It's too late for me to die young
Posting anonymously because I'm not a whore.
Given that the server is slashdotted, here are a few facts about pseudo-random number generators:
Linear Congruential Generators are infamous for certain weaknesses, most notably that n-tuples fall "mainly on the planes": they lie on hyperplanes in higher dimensional space, depending on the additive and multiplicative parameters chosen.
This doesn't mean that they are any worse for cryptography purposes, because even if you choose parameters that aren't as bad, once the generator parameters are determined and a seed is found, the sequence is deterministic.
But, all is not lost. Modern generators often use shuffling techniques, where you keep track of a few dozen numbers at a time, and then pick one number to determine which of the pool to select, and a second number to replace that selected number. Even a poor LCG when accompanied by such a shuffling technique can perform well. Well, not a really poor one--IIRC randu had problems that shuffling would not fix. I believe the gnu lrand48 and friends use this shuffling technique, as well as CMUCL. I suppose this can be even better if you populate the initial pool of numbers from outside the pseudo-random sequence, so that the potential attacker has almost no shot at figuring out what you seeds are, but to scientists who aren't worried about cryptographic purposes, that is counter-productive. I believe that there are some generators that have been proven 'non-invertible'--you can not go backwards in the sequence except by performing brute force search. Whether or not TCP geeks use these is beyond my knowledge.
But, all is still not safe. You have to be careful about how you change your random number into a usable number. Often people use the high-order bits (e.g., they multiply by some number and then round off). This can be a mistake (of course depending on what your generator really is, and what your purposes are).
Is this a subtle joke? Maybe the graphs are not available because of the /. effect? DUH!
At least I am seeing it very clearly.
And the moderators are on crack again.
It's just a 133mhz netbsd box on a home adsl line though, but I figured the more the merrier.
Why test NextStep? Because he still uses it? It will not and has not been upgraded in about 5 years unless you count Mac OS X as the upgrade (which it is).
't be cool to have a board with a bit of radioactive alpha source and a counter to make genuine random numbers. Like this, or, ha, here's one (3rd from the top) that proposes using disk drive air turbulance to generate random numbers!
try { do() || do_not(); } catch (JediException err) { yoda(err); }
One year later, we find that both Windows 2000 SP2 and Windows XP still use essentially the same ISN generator
One might presume from this that the available graph is suitable for all of them.
I Doubt MS had anything to do with the content of the report. The authors simply saved space by showing one graph for all of them.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
If you read the article is says:
- Raynet --> .
Not being well versed in statistics and math in general, I was struck by the resemblance of some of these pictures to images that i've seen of far off galaxy's and star clusters. Could it be that we live in a very high resolution of a randomness graph from some other universe???
You are overlooking the fact that most OpenVMS installations use third party TCP/IP stacks, generally Multinet or TCPware from Process Software (the CMU stack being largely defunct now), which do not suffer from this defect. This is largely because the initial implementation of DEC's TCP/IP stack, UCX, was buggy as hell and lacked many features, although it is finally starting to catch up.
Not that it matters much anyway. This predictable ISN weakness only threatens systems configured to trust others based solely upon their IP address (a bad idea). The only ways to crack a properly configured OpenVMS system currently involve (1)physical access to the console, (2) "social hacking" (tricking someone into telling you their password), or (3) packet sniffing for protocols which pass unencrypted passwords such as POP3 and telnet (easily solved by disabling such nonsecure protocols); three vulnerabilities which pose a threat to any OS, no matter how well designed. Nice having an OS which cannot be compromised via buffer overflow exploits (OpenVMS discards data from buffer overflows and raises an exception, always. Overflowing data cannot be executed).
*** Quantum Mechanics: The Dreams of Which Stuff is Made ***
Agreed, such devices tend to have poor ISNs, but then again, they are for home use, and the ports they serve only respond on the INSIDE. Outbound traffic passes thru with more-or-less the same ISN it started with.
Unless you don't trust people on your home lan, it's not much of an issue. Yes, it should be done right, but the only people that can exploit this are those within your network. If they are in your home, they can do much worse than hijack your session as you configure the router.
As for outbound traffic, if you connect to an outside website from an inside PC, it uses the ISN that the PC generated and doesn't change it or adds some simple fixed constant. It still retains all of the entropy of the original PC's ISN. Nobody from the outside should be able to connect to the configuration server in the "DSL router" device. Hence, nobody from the outside really sees the poor entropy of the DSLRouter's ISNs.
Only higher-end firewall products, ie: the cisco PIX, attempt to mangle the ISN generation as they translate hosts. Most of the simple products do not, and certianly none of the $100 DSL routers do.
Also good ISN generation is actualy important to more "commercial" grade routers, since these devices are sometimes deployed and administered remotely, generate tunnels, etc. Thus these routers/firewalls sometimes have exposed ports, or exposed client traffic on a public network as they are being reconfigured.
Of course, many are only configured localy, or over a local LAN, which makes the risk a lot lower, but also users on corprate lans are generaly less trusted than those in your own home.
-Matt
But since alot of home users are buying Wireless Routers. They face a similar attack from the wireless interface as from the public internet...
Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com
Unless Apple decided to start adding a version number to the version number
;)
You mean like MacOS X 10?
--
Reverse outsourcing: it's the future
I propose a new flag in the standard TCP/IP packet. We shall call this the Slashdot Flag.
There is already a flag in HTTP/1.1 (which operates on top of TCP) that allows Slashdot attacks to be detected. It's called the Referer: header. If the referer is slashdot.org then either refuse the visitor (bugzilla does this) or present a static page with low-resolution graphics.
Will I retire or break 10K?
Thank you, I was going to say the same thing...the whole point of the paper is to demonstrate that hijacking a connection is entirely feasible on certain systems. Why else would you need to predict ISNs?
The fact that they even have to mention that IRIX is insecure just shows how out of touch geekdom as a whole has become. Why even test IRIX for security holes? It's light years beyond swiss cheese.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Only those OSes which scored badly the first time around were retested.
.03% probability of a successful attack. Satisfactory but not 0.
.0000001%?)
That said, the last test was for 2.2 - It would be useful to test 2.4 just for comparison. It sounded like 2.2 had a few *MINOR* flaws (Mainly a reduced number of bits of randomness, probably easily changed by changing the type of a variable or two) that despite being flaws, were insignificant. Something like a
Has 2.4 achieved a 0? (Or at least
Or what if the kernel developers accidentally screwed something up and 2.4 is worse than 2.2? (HIGHLY unlikely but still possible...)
retrorocket.o not found, launch anyway?
A TCP implementation that generates initial sequence numbers using a trivial time dependency may be secure against sequence number guessing attacks if it implements RFC 1948.
The idea is to add a bias to the sequence numbers that depends on the source address. A client will be able to predict his own sequence numbers but not the sequence numbers of others. The bias is calculated using a cryptographic hash of the connection ID and a secret value.
A TCP implementation that uses RFC 1948 may still get a very poor rating for initial sequence number predictability from tools like nmap.
Does anyone know any TCP stack that actually implements it?
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
... Linux is apparently beneath their contempt. Do they know something we don't know?
From section 3 of the linked article:
"Several systems, such as Linux, use the same, satisfactory ISN generator as the one used a year ago, and because of that, are
not covered here in any more detail.
"
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
Apart from the version number thing, it still was better than that (that being OS 9) - and Windows 9x and NT up to service pack 3.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
It's a great way of seeing how secure a TCP stack really is.
Yeah, right.
Try the following: plot 500 points with point i having x coordinate Fib(i + 37) % 97 and y coordinate Fib(i + 97) % 97 (where Fib(i) is the i-th Fibonacci number). They look random, but in fact are totally predictable!
Now imagine that someone got this right, and uses a crypto-secure PRNG to generate their TCP ISNs, seeding it with known-good random data. It would be nice to believe that this defeats all known TCP attacks! In fact, of course, their stack may be completely open to all kinds of attacks not involving ISN spoofing.
The graphics are amusing, but not particularly informative except in the negative case. There is no substitute for real security. Testing can only prove a system insecure. ISN attacks are not the biggest worry in most TCP applications.
Here is a case of "graphing randomness":
http://www.cs.wisc.edu/~kovar/hall.html
Table-ized A.I.
I would love to see such code, as this does not jive with what I've observed in my own socket coding. When a buffer overflow occurs on a VMS socket_read() call (at least under Multinet), the overflowing data doesn't seem to even get written to memory, let alone passed to DCL (unlike the situation in Unix and Windows where overflowing data gets passed to the shell).
*** Quantum Mechanics: The Dreams of Which Stuff is Made ***
satisfactory ISN generator
If Linux having an attack feasibility of 0.05% is satisfactory, compared with OpenBSD's 0.00% for example.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
That's less than 0.05%, to be accurate.
Correct.
and at the time of the last test, OpenBSD's attach feasibility was 5%, an order of magnitude worse.
No, the original article states that the release of OpenBSD tested at the time (2.8), had an attack feasibility of 3.05%. It also states that OpenBSD -current had an attack feasibility of 0.00%.
The level of bandwidth and time required to pull off a sub-0.05% feasability attack is so ridiculous that it it is completely impractical in the real world.
But increasing bandwidth and processor speed will eventually make brute force guessing of 32-bit ISNs feasible for the average attacker.
Linux is only 24bits wide. Thats a 128 times smaller area to guess than OpenBSD's and 3GHz P4's, broadband WAN's and Gigabit+ LAN's are upon us.
Why the hell not fix it?
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
>Simple free products like OpenBSD with pf/nat do.
:)
In the context I meant it, I'd certianly not call OpenBSD a "simple product". By simple I meant "designed with minimal work".
OpenBSD has got a lot of well thought out and well placed security design. In that respect, I'd call it one of the higher end, carefuly engineered products.. even if it is free
-Matt