Slashdot Mirror

It's possible that there is more to this than what I have divined from the 'uber-secret-vendor-only' disclosure but this seems to be little more than traditional cache poisoning with random-number-generator (RNG) prediction. Both of these situations have been well known and documented within the security community for a number of years.

Cache poisoning was predicted long ago by Dan Bernstein (as mentioned by a previous poster or two)[1]. (Nobody listens to me either, DJB.) The combination of this and RNG prediction was wrapped up nicely by Joe Stewart in his 2002 (I think) paper [2]. Joe used Michal Zalewski's free TCP/IP sequence number prediction software [3] to visualize random number generator attacks on DNS responses from various resolvers. The paper is well worth a look if you made it through the last sentence and are still reading this one.

Incidentally, Paul Vixie (BIND author,) posted a potential fix to this (or a surprisingly similar) problem to the Namedroppers mailing list at the end of February [4]. Time will tell whether the two events are connected.

This whole saga appears to be another case of 'marketing department run amok' but we'll have to wait for the BlackHat presentation to find out if all of this is just regurgitated previously ignored security advice.

[1] http://cr.yp.to/djbdns/dns_random.html
[2] http://www.lurhq.com/dnscache.pdf
[3] http://razor.bindview.com/publish/papers/tcpseq/vseq.tgz (currently down)
[4] http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00378.html

So what is it? YAMIHDE [Yet Another Microsoft In-House Database Engine]?

I could have sworn that I read a few years ago that they were ditching the existing registry engine, and were going with a new engine for Longhorn/Vista.

One of the most important rules of stream ciphers is to never use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext -- and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques.
...
Microsoft uses the RC4 stream cipher in both Word and Excel. And they make this mistake. ...

Every file that is written to an encrypted folder by User A has a private encryption key generated for it. That private encryption key is then encrypted with User A's public key and every designed Encrypted Data Recovery Agent's public key. Then either User A or any such recovery agent's private key can then decrypt the file. Of course, MS just lets lay users assume their "encrypted" files are private.

They (and they employers) also probably assume that when their key is lost then all of their work is not lost forever. You are right that Microsoft's encryption is a joke, but this is not a good example. What you have described is not a flaw per se, but a design decision. In fact, that is the only way to restore the encrypted data when the user's key is lost. On the other hand, the RC4 flaw is about reusing the same keystream in stream ciphers, which is an inexcusable amateur mistake and shows a level of incompetence just plainly laughable in the case of the largest software giant on the planet. Let me quote Bruce Schneier on Microsoft RC4 Flaw:

One of the most important rules of stream ciphers is to never use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext -- and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques.

It's an amateur crypto mistake. The easy way to prevent this attack is to use a unique initialization vector (IV) in addition to the key whenever you encrypt a document.

Microsoft uses the RC4 stream cipher in both Word and Excel. And they make this mistake. Hongjun Wu has details (link is a PDF).

In this report, we point out a serious security flaw in Microsoft Word and Excel. The stream cipher RC4 [9] with key length up to 128 bits is used in Microsoft Word and Excel to protect the documents. But when an encrypted document gets modified and saved, the initialization vector remains the same and thus the same keystream generated from RC4 is applied to encrypt the different versions of that document. The consequence is disastrous since a lot of information of the document could be recovered easily.

This isn't new. Microsoft made the same mistake in 1999 with RC4 in WinNT Syskey. Five years later, Microsoft has the same flaw in other products.

As you can see, Microsoft's crypto is a joke indeed. It is an old, unfunny joke that they keep repeating ad nauseam. But it is about a much more important incompetence than what you have noticed. As some people say: "When it comes to security, it's always Amateur Hour in Redmond." Sadly, this has been true forever. When people invest in Microsoft's security they always say "maybe this time they got it right, I'm sure." This is not without a reason.

It sounds like you have little idea who the author is, or you wouldn't make such a statement. Michal Zalewski is a well-respected security researcher, with impeccable credentials, and no particular love for Microsoft, who's made an undeniably valuable contribution in many areas of IT security.

While he generally seems to work on Unix-like systems, he has also published work on M$ software security problems - e.g. http://www.bindview.com/Support/RAZOR/Advisories/2 001/adv_mstelnet.cfm
http://news.softpedia.com/news/2/2004/April/7797.s html
http://cert.uni-stuttgart.de/archive/bugtraq/2000/ 06/msg00066.html

A quick google will repay your time.

Give the guy some credit - it seems he's uncovered a surprising lack of robustness in non-IE browsers - and admittedly an even more surprising degree of resilience in IE's handling of the HTML tag soup he played with ... strange but apparently true :-)

Biggest Windows vulnerability ever, again. How many times have we said that this year? At work, it's begining to feel a bit like a duck and cover drill.

This is sort of on topic with your post. Here's a discussion and visualizations of various OS's TCP sequence numbers:

Strange Attractors and TCP/IP Sequence Number Analysis

Guessing a port and IP is fairly easy. Guessing the sequence number is not. This is why making sure that TCP initial sequence numbers are random is important.

This is old news.

For the insanely paranoid use a hardware entropy generator (TRNG) for choosing ISN's.

There are all sorts of attacks against network protocols when poor random number sources are used. This is but one example...

this just reminded me of an old(ish) NT bug,
where you could ask yourself for impersonation rights for someone else's procs :)
here it is

Personally, I would be very interested in seeing how well the machine in this record-setting example handles an attack of the type mentioned in the above referenced article.

It was the happy side effect from addressing another problem. The other problem being operating systems with shitty TCP stack implementations (*cough* Windows) that choose initial sequence numbers that weren't exactly random.

What happens when you pick a easily guessed sequence number? Somebody comes along and hijack's your connection.

Not too familiar with strace, but there is an strace for NT (Alpha build, don't use on production servers according to the notes). Also, Sysinternals makes some good utilities for debugging...which, once again, I don't get into. I'm not sure why having the source code would allow me (a non programmer) to see what the application is doing internally any more than I can deduce what Windows is doing internally by looking at external events. Oh, and tcpdump is also available for Windows as WinDump (bonus points for being BSD licensed).

I've never reinstalled a Windows Server because it couldn't be fixed. I've reinstalled because of hardware failures, misconfigurations or upgrades, but that's about it. I have, however, reinstalled Windows desktops because I didn't want to take the time to fix them. Like I said, though, if I can fix it about 2 hours with a reinstall, it's a better proposition than spending 4 fixing it.

Windows the OS is very stable...it will run on decent hardware for just shy of forever. Windows apps and assorted device drivers, however, are all over the place in terms of stability and are the cause of virtually every BSOD or crash I have ever seen. I do wish Windows had a better model between device drivers and the kernel, but then I don't run flaky drivers on servers...that's more a desktop concern. Flaky apps should be fixed by the vendor or changed to a competing app.

1. write
   
2. preview
   
3. post
   
4. think
   
5. reply to you own post
   

a safe, secure way of running Linux versions and Linux processes

Well, yes it is, but if you want to take advantage of the security, and debug processes in depth, then you might have some problems.

Many of you will probably remember the Reverse Challenge. One evening I downloaded the malicious binary, and decided that UML would be ideal to try running it in a tightly controlled enironment - using fenris to trace its execution and learn more about it.

Unfortunately, fenris doesn't work under UML (neither does strace if I remember correctly).

Shame. It's a lot cheaper than VMWare!

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.

Original report here:

http://razor.bindview.com/publish/papers/tcpseq.ht ml

Yes, I like open source as well. But whether it leads to better products in any particular aspect depends on a person's needs and wants

As an example I'm sure you've probably already seen, here is an example of open source software being more secure than closed source, where convenience is not hurt.

Open source on top.

Security here, is basically ranked as highest to lowest, which turns out to be open to closed. Naturally, as one would expect, the open source project which focuses on security is at the top of the lot.

In the open source world, someone might implement a PRNG thinking it is strong. One day, someone discovers that it is not very strong by looking at the source or looking at the output statistically. They might complain that it is not strong, leading to a better PRNG being written by the original author, or as is typical with open source, someone with greater expertise may submit code that is stronger, which gets used.

In the closed source world, someone (or a team) might typically be hired to program a PRNG as an "expert" of math programming. So his expertise is trusted, he implements his expertise, his random streams turn out to be VERY pseudo, as analysed, spoofing attack tools become available and the admins and closed source programmers scratch their heads in wonder at these attacks. Finally, after it becomes publicly known that the closed source is weak (usually through open source advocates who present analytical evidence), the closed source programmers embrace the BSD license as a "God send" and then proclaim industry leadership through innovation. ; )

This is just a bag of disjointed tools that might, with effort, be coaxed into doing what needs to done -- I say this as a user of some of the tools you've mentioned.

Because most of them do an excellent job without graphs? : ) I kinda prefer getting SMS paged with critical alerts and emailed with all alerts greater than "odd behaviour". Sitting looking a graphs 24/7, or having some team paid to do this is not my idea of effective event monitoring.

For example, Windows NT (just to give an example) allows you to monitor the behaviour of virtually every kernel object and graph them against time. I am not aware of similar capabilities in any of the tools you have mentioned

Some people who go further than waiting for the next service pack, don't need graphs. Where they are useful, they are usually present.

Or what about auditing trails, such as who accessed what how when?

Proper admin would advocate the usage of sudo, which logs nicely and proper usage of file permissions. If you're sufficiently concerned about security then logs can be made impossible to tamper with electronically. Printing logs to line printers is very common in Bank and Stock Exchange data centers. Been there, done that. Or if this is over the top for your systems, you might like to log to an OpenBSD syslog server which is configured to only allow appending to logs even for the root user. Doing that via a serial connection that does not accept logins for that little extra security? Or perhaps logging to WORM is more your style?

It's already happened. We started the whole #!/bin/sh thing after all. All we need now is a a convenient way of preserving file attributes and a convenient way of opening email attachments and we are in a world of hurt.

If a Unix user logs in as a normal user on a system that has been kept up to date with security patches, little can be damaged. Perhaps some of their own files will be lost or exposed if they use an insecure mail reader. If they're logging in as root, on a system that is not up to date security wise, while reading mail with an insecure mail reader, then they deserve what they get. I'm guess the point between discovery of this weak mail reader and the fix would be a very thin slice of time if the history of open source security is anything to go by.

Wouldn't the randomness itself indicate an intent to deceive?

On the contrary. Having a bunch of nodes behind an OpenBSD NAT firewall with state modulation should, it seems to me, look the same to an outside observer as having a single OpenBSD node.

Nevertheless, the documented point of state modulation isn't to hide the fact that you're doing NAT. It's to correct for the fact that many operating systems pick initial sequence numbers poorly, and are thus vulnerable to sequence prediction attacks. So there may well be ways to tell the difference -- though it would surprise me.

In the end, though, I agree with the sentiment expressed elsewhere under this topic: that ISPs are misguided in trying to penalize intelligent use of their services, but also that users are misguided in playing hide-and-seek with bad ISPs' policy enforcement rather than choosing more honest and professional ISPs.

OpenBSD's just got good marketing... as you say, their security's on par with the other *BSDs and the better Linux distros.

"The worst an Outlook virus could do on Linux is take out the account of the user who clicked on the attachment."

Sure, because there have never been privilege elevation flaws in common unix software, have there?

teknoenie wrote:
> is this something that can be proven to the openbsd team.

Yes.

OpenBSD 2.7 was vulnerabile about remote root exploit with the default install. Please look at this advisory and compare it with the fix by openbsd.

cperciva wrote:
> I'm not sure about this, but I think what they mean is that there
> have been no vulnerabilities discovered before they were fixed

Actually above exploit is fixed by NetBSD people before OpenBSD. You can confirm this by the cvs log.

bolverk wrote:
> Well, we can force ssh _clients_ to do X11 forwarding... not a root
> flaw, and not remote... so on to the next.

The above problem is a remote root flaw. Due to the reason I don't know, this flaw is not listed in OpenBSD's security page. Perhaps OpenBSD people don't have an ability to know their security information unlike they claimed?

Anyway, the "4 Years Exploit Free" message is just wrong.

OpenSSH pre 2.3.0 is also vulnerable, so don't be getting any false sense of security here.
-
sig sig sputnik