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.
Comment removed based on user account deletion
It is a well known fact that all known existing hackers are 3-dimensional.
Usually, those 3 dimensions are stretched to the limit, but there's still only 3 of them.
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
(To those tempted to reply that "they know it's secure", I'd like to point out that assumed security without testing is exactly what keeps getting MS in trouble)
Why isn't Linux tested in the report? Its 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
this is not a sig
How about GNU/Hurd (I can't see if it's in the graph because of the ./ effect)? Last time I installed it (approximately six months ago) there was no random generation device...
fear my zig!
Comment removed based on user account deletion
"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.
did you change your name and repost the same comment? or are you just repeating what someone else said?
you could at least have corrected the typo...
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
Might this be a bit of MS led DNS attack.
This post encoded with ROT26. If you can read it, you've violated the DMCA. Handcuffs please, sergeant.
Question how can you tell tc/ip stack is from windows versus linux?
Link
Is it Microware's OS-9, or Apple Mac OS 9?
http://www.club977.com/ - The 80's Channel!
Your source for commercial free 80's music!
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).
When I saw it in the Bugtraq mailing list.
Extremely interesting, I'm probably just uninformed, but this has been one of the first examples I've seen where a 3d rendering has been used to express data in a way that makes any sense to me (I am mathematically challenged).
He tried to kill me with a forklift!
It's just a 133mhz netbsd box on a home adsl line though, but I figured the more the merrier.
Realistically, the amount of time to crack a random number generating algorithm is NP which means it increases exponentially with the length of the algorithm. So I suppose you could say that some pseudo-random number generators are theoretically crackable, but if it takes longer than the age of the universe to crack them (which it will for large values of N), that's random enough for practical applications.
But to be abstract, if you define a computer as an universal turing machine, a computer will *never* be able to be non-deterministic, no matter how fast it is or how many instructions it has.
OTOH you can graft randomness into it with such external things as the box I mentioned...And any REAL computer (as opposed to a turing machine) will stuff up occasionally (flip a flipflop to 1 instead of 0, etc.), so maybe this is a bit of nondeterminism?
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).
If u've read stephen wolfram's "a new kind of science" this is exactly the type of graphical thinking he advocates.
-- -- --
Help my mini cause: My journal
Don't click the link in the story. It's a fake linked to goatse.cx [coredump.cx]
These people should be put behind bars for trying to crack the TCP/IP stack. They have also attacked so many different OS's. Atleast MS should sue them.
'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); }
Unless Apple decided to start adding a version number to the version number, I think we can assume it it Microware's OS-9.
Is is just me or was there no Linux graph? Or because it was listed in the previous test?? Even then, they just tested 2.2...
These operating systems were all 100% predictable- why was OpenVMS mentioned as being one of the worst? Frankly, it did poorly for an OS that has always been prsented as an example of great security, but I don't think the obsolete VAX platform represents the typical OpenVMS installation anymore. A test of OpenVMS Alpha would have been more useful. It's possible that there's a difference.
Gamingmuseum.com: Give your 3D accelerator a rest.
...mostly because OpenVMS people tend to think, that 'their' OS is the most secure one on this planet (just like OpenBSD developers do, too).
;-), nmap rating ~10
Compared to Standard-Unices, OpenVMS might offer superior security, mostly because of the privilege model it utilizes instead of giving all-powerful root privileges to many user space applications.
On the other hand, we've got OSs which have much more sophisticated security than OpenVMS.
First, there is IBM's AS/400, which has got a privilege model quite similar in extent to the one used in OpenVMS, but additionally it has object-based design, and therefore object-based security (type enforcement and such...). However, it lacks Mandatory Access Control, TCB, Trusted Path and some other things mostly required by military and/or government environments, and therefore it only achieves a C2 security rating.
And then there are a couple of really secure Trusted Unices/Unix-style OSs, like Trusted Solaris, the Pitbull Addon for Solaris and AIX, Trusted IRIX, or XTS/400.
Just talking about fine-grained privilege controls: Argus' Pitbull has got around 100 privileges, how many privileges are there on an OpenVMS box?
No OS has ever received an A1 security branding. And the only OS which has ever received a B3 security branding, is actually a Trusted Unix Environment, something like a Unix clone with some proprietary security mechanisms built into the kernel (OpenVMS was B1 or maybe B2, iirc).
---
Regarding secure TCP/IP initial sequence number generation, it does not take a Trusted OS to just generate secure sequence numbers.
About two months ago, I compared initial sequence number generation on the following OSs using nmap:
* Windows 95
* Windows ME
* Linux 2.2.x
* Windows 2000 (plain)
* Windows 2000 (with Norton Internet security installed)
* OS/2 Warp Server Advanced 4.0 (default install)
* Sun Solaris 7 x86 (with tcp_strong_iss set to 2)
The results where pretty interesting and also a bit surprising:
Windows 95 was worst (ok, that's not surprising
Then came OS/2, which was not much better, nmap rating ~ 1000
(BTW: does anyone have nmap results from OS/390 or OS/400?)
Even Windows ME was a bit better than OS/2, but still far away from being secure, nmap rating ~ 8000
There was little difference between Win2k with Norton's Firewall (~12000) and Win2k without the Firewall (~15000)
Linux' results were quite good, nmap rating approximately some hundred-thousands or millions
Solaris with tcp_strong_iss set to 2 seemed to offer really strong sequence number generation, so nmap just printed a lot of 9s
---
Additional information:
Here is nmap.
Here is Argus Systems (EAL4 security for Solaris/AIX)
Here is IBM's AS/400
Here is Getronics (B3 secure Unix Environment running Unix and Linux applications)
And finally, here is OpenVMS
What about LinkSys, Netgear, SMC, Assante, DLink and other home routers? How good are their sequence numbers?
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 need some professional help.
You may think that having a duplicate quadruple is unlikely, but that isn't true. The most common quadruples are: your ip, your port just a bit bigger than 1024, your http proxy server ip, port 80.
Using a random local port also helps, though I don't know of systems that do that for TCP.
Aren't there other things your more interested in then critisizing the grammer of other's?
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 ***
Don't you think everyone here is intelligent enough to know to look at the link before they click it?
For gawd's sake, the link has "goatse" in it.
Hello,
:-)
could you please tell me more about this hardware device you're diving a diagram about ? What are the exact components please ?
Thanks,
--
Gilbert
(gilbertf@posse-press.com)
Actually it was sent to the full disclosure mailing list members at least 14 hours before bugtraq members, but that's ok, some people like old news :)
a couple of wires suspended is a good brownian motion generator, like a nice hot cup of tea... :)
i wish i could reach through the computer and strangle you.
surprisingly, this is the third time ive seen this article on slashdot. get a clue. thanks.
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?
I'm seeing tons of people complaining how badly this site got slashdotted. I also remember from the last time, when it did too. However, after reading a few articles about "slashdotted" solutions, I clicked the link, and here it is...
I could see what people are trying to mirror. I remember an article bitching about squid servers in ISP's, but I'm happy if I can get my stuff.
I noticed Tru64 is shown to be insecure... can HPCompaq invent a reason to sue the authors?
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.'"
How bizzarre -
Linux is one of the most popular server platforms on the net, so the absense of results from that platform stands out like a sore thumb.
I wonder what this guy's point is, or what statement he's trying to make here, by pretending linux doesn't exist, while covering some relatively obscure platforms instead...
Seconded. A couple of years ago as a VMS Admin, I used to say 'I wouldn't use UCX if they gave it away'. When they started giving it away, I didn't use it. CMU isn't totally obsolete, either. It does 'work', and it is free. I set it up a few years ago at our local court house when lightning killed the serial ports on their terminal concentrator. They had a 90TL sitting right there, with all of the PC's ethernetted together. A short chunk of coax dropped down to the 90TL, load CMU, reconfigure Reflection to use TCP/IP rather than serial, and everything was better than ever.
(Note, this is an internal network only, no internet exposure, no dialup, no one there with a clue how to hack TCP/IP, and nothing that interesting on the VAX to make it worth the effort.)
Tester Seemed to forget about Linux. If he feels that Mac OS/9 or Unicos are more important to internet security then... hmmm
I didn't see Linux on there at all. Weird, considering it's a fairly major OS.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
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.
And I just tried [www.bugzilla.org], and it worked fine
I wasn't aware of www.bugzilla.org. I was referring to bugzilla.mozilla.org, which just refused me.
Will I retire or break 10K?
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.
> Tester Seemed to forget about Linux. If he feels that Mac OS/9 or Unicos are more important to internet security then... hmmm
Poster Seemed to forget about reading the article before posting; quote:
"In this section, we review a number of operating systems that were either identified as not satisfactory in the original publication, or were not covered by our research at the time. 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."
Any idea what software was used to make those graphs?
It looks like a neat tool for visualizing sets of numbers.
It reminds me of this awesome applet that shows frequency of numbers used on the net: numbers
Here is a case of "graphing randomness":
http://www.cs.wisc.edu/~kovar/hall.html
Table-ized A.I.
Oops, I got something wrong in the original post...
Windows 2000 WITHOUT Norton's Firewall had an nmap rating of ~ 12000, Windows 2000 WITH the Firewall achieved the better rating of course, approximately 15000.
OpenVMS can not identify data which came Buffer overflows, and therefore, OpenVMS can also be exploited via buffer overflows - this can be prooved by writing just a few lines of C code.
The only difference to many other OSs is, that applications do not have more privileges than are required to run the application, while on Linux for example many applications (like Sendmail or FTP-Servers) have Superuser-privileges, and therefore can override Discretionary Access Control.
I am almost absolutely sure, that it is possible to also run arbitrary code by exploiting buffer overflows on OpenVMS. But even if you could not, you can still modify data and pointert - that's enough to compromise security of a privileged program.
There are also Unix operating systems which have a privilege model, and some of them have got a much more fine grained privilege model than OpenVMS *PLUS* Trusted Computing Base Controls, File Security Flags and many other things.
So OpenVMS is by far not the most secure OS - personally, I think even OS/400 is more secure, because of its object-based design and its type-enforcment policies.
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 ***
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare