Slashdot Mirror

Have a look here(PDF doc).

I know it has been demonstrated at 217 feet (well short of a kilometer but well more than the industry claimed) with a U.S. passport, but the paper above indicates 2 miles is theoretically possible.

Kristin Paget used to be Chris Paget, famous GSM hacker. With that out of the way, we return you to this awesome hack.

That's a long story. They *think* they have a license, but they really don't. According to Chris Paget's slides (slide 6), they believe that they are in the clear because they think they are operating in a ham band.

FTFA:

That GSM hack is based on a demonstration that security researcher Chris Paget performed at Defcon last year, showing that with a powerful enough antenna placed close enough to target phones, the victims’ handsets can be tricked into connecting to Paget’s setup instead of the carrier’s tower. Perkins and Tassey have implemented the same tools in their airborne hacking machine, and like Paget, used a portion of the radio frequency band set aside for Ham radios to avoid violating FCC regulations.

There's supposedly an overlap in the Euro GSM 900 band and our Ham band between 902-914MHz, but this is actually incorrect (just see every other GSM frequency chart online). The Cell phone (uplink) is actually in this band, and the tower (downlink) is 45 MHz greater. It's unfortunate that this little typo is cropping up like this.

Fixed it: http://www.tombom.co.uk/blog Chris Paget's Blog

Nope, the demo will definitely comply with FCC regs about operating in the GSM band. http://www.tombom.co.uk/blog/?p=195

"Meanwhile, another Black Hat presenter, Chris Paget plans to demonstrate a completely different way to intercept GSM calls. He's setting up a fake cellular tower that masquerades as a legitimate GSM network.

According to Paget, using open-source tools and a US$1,500 USRP radio, he can assemble his fake tower, called an IMSI (International Mobile Subscriber Identity) catcher. In a controlled experiment, he's going to set one up at Black Hat and invite audience members to connect their mobile phones. Once a phone has connected, Paget's tower tells it to drop encryption, giving him a way of listening in on calls."

Yes, the only question is how to get it to forward calls. A perverse thought is someone plugging a Magic Jack into it, but you probably need something more sophisticated. Like Skype, or Asterick and some SIP minutes. Maybe not even that.

Read Chris's blogs. She's clever. ps - I assume she's a she, she carries a handbag and wears heels, but I'm somewhat limited in my outlook, acording to Chris. I can only tell her how I see it from my frame of reference.

"Meanwhile, another Black Hat presenter, Chris Paget plans to demonstrate a completely different way to intercept GSM calls. He's setting up a fake cellular tower that masquerades as a legitimate GSM network.

According to Paget, using open-source tools and a US$1,500 USRP radio, he can assemble his fake tower, called an IMSI (International Mobile Subscriber Identity) catcher. In a controlled experiment, he's going to set one up at Black Hat and invite audience members to connect their mobile phones. Once a phone has connected, Paget's tower tells it to drop encryption, giving him a way of listening in on calls."

Yes, the only question is how to get it to forward calls. A perverse thought is someone plugging a Magic Jack into it, but you probably need something more sophisticated. Like Skype, or Asterick and some SIP minutes. Maybe not even that.

Read Chris's blogs. She's clever. ps - I assume she's a she, she carries a handbag and wears heels, but I'm somewhat limited in my outlook, acording to Chris. I can only tell her how I see it from my frame of reference.

"Meanwhile, another Black Hat presenter, Chris Paget plans to demonstrate a completely different way to intercept GSM calls. He's setting up a fake cellular tower that masquerades as a legitimate GSM network.

According to Paget, using open-source tools and a US$1,500 USRP radio, he can assemble his fake tower, called an IMSI (International Mobile Subscriber Identity) catcher. In a controlled experiment, he's going to set one up at Black Hat and invite audience members to connect their mobile phones. Once a phone has connected, Paget's tower tells it to drop encryption, giving him a way of listening in on calls."

Yes, the only question is how to get it to forward calls. A perverse thought is someone plugging a Magic Jack into it, but you probably need something more sophisticated. Like Skype, or Asterick and some SIP minutes. Maybe not even that.

Read Chris's blogs. She's clever. ps - I assume she's a she, she carries a handbag and wears heels, but I'm somewhat limited in my outlook, acording to Chris. I can only tell her how I see it from my frame of reference.

Any application program can send messages to any other application program. There is nothing in the Win32 interface that provides any type of protection.

Bzzzt, wrong. As I said before, desktop objects are the security barrier between windows (and their messages). Every window is owned by a thread; messages to the window are posted to that thread's message queue. Every thread that can participate in window messaging is associated with a desktop object. A thread can only send or recieve messages to and from windows on the same desktop it is associated with. A window message cannot be sent without a destination window on a specific desktop. A thread can only be associated with a desktop if that desktop has been opened with sufficient access. The process of opening a desktop includes a check against the desktop's security descriptor. Microsoft guidelines have always warned against putting windows of different privilege levels on the same desktop because of the possibility of the harmful interaction it allows. As long as apps are following those guidelines, there is no way for a unprivileged malicious program to send arbitrary messages to a privileged process.

The most a process could be expected to be tolerant of is arbitrary user input, but even then the security model doesn't require a user's applications running with that user's authority to be protected from the user himself. The only programs that need to be immune to user input are ones that are trusted by the OS, yet interact directly with the user. Winlogon is the only process that fits that description. (Note that Winlogon has its own desktop to protect itself from any messages coming from the user's processes.)

There's no argument that Win32's messaging system is old and quite ugly, but to say it's an inescapable security hazard isn't true. When used properly, there's no vulnerability. Win32 is not X-Windows.
Look up shatter attacks. It's the same idea, and they're inaccurate for the same reasons.

A few choice quotes:

Messages can be sent only between processes that are on the same desktop. In addition, the hook procedure of a process running on a particular desktop can only receive messages intended for windows created in the same desktop. Desktops

Warning There is a significant security risk for any service that opens a window on the interactive desktop. By opening a desktop window, a service makes itself vulnerable to attack from the logged-on user, whose application could send malicious messages to the service's desktop window and affect its ability to function. SetThreadDesktop

For the Windows user interface, the desktop is the security boundary. Any application that is running on the interactive desktop can interact with any window that is on the interactive desktop, even if that window is not displayed on the desktop. This behavior is true for every application, regardless of the security context of the application that creates the window and regardless of the security context of the application that is running on the desktop. The Windows message system does not allow an application to determine the source of a window message.

Because of these design features, any service that opens a window on the interactive desktop is exposing itself to applications that

Oh Lucy! - You Gotta Lotta 'Splainin To Do!

Oh Lucy! - You Gotta Lotta 'Splainin To Do!

What's "inherently" insecure about AD and Exchange ?

Stuff like this?

http://security.tombom.co.uk/shatter.html

I dunno. I still use it, have only a few users, and use the inbuild 'intelligent message filter' which is actually a ripped off spam assasin? Or very similar, being baysian, I believe.

I know exactly what it is, a kludge to enable multiuser use of what was always designed to be a single-user os. Sure they can kludge in support for multiple users, but it was never designed that way and you can still see areas where such design shines through..

For example, shared memory only works with DLL's and not with executeables, so when you load an app several times through terminal services, the dll's are loaded once but the binary is loaded once for each user.. Unix systems will share the code segments of the initial binary too, and only have a per-user copy of any workspace memory..
The windows approach makes sense in a single user environment, where you're unlikely to run the same program more than once, but several different programs are likely to make use of the same libraries. Had windows been designed for multiuser use, they would not have designed it this way..

Another example, c:\ being writeable by any user by default, and the way windows resolves paths.. Try creating "c:\program.exe" on windows, and when some programs (including default windows apps) search for "c:\program files\something\something.exe" the way windows tries to resolve the path (a nasty kludge to handle filenames with spaces and not needing escape chars) it will end up executing c:\program.exe, there are plenty of references to this on google..

Also, search for "windows shatter attacks", an example being: http://security.tombom.co.uk/shatter.html
look at how the windowing system is designed, do you really think anyone designing a multiuser environment would design it this way?

A solid piece of software is just as impenetrable on Windows as it is on Linux or any other platform - it's all about understanding the environment.

Take a look at this paper on shatter attacks. From what I understand any process (owned by any user) can execute arbitrary code as any other user on a desktop system as long as then can find a window owned as that user. They simply tell the administrator owned window to run a function at a particular memory address (by using a timer with a callback).

Apparently this escalation flaw is fundametnal to the design of the Windows messages subsystem and is not easily fixed. Interesting. I wonder if/when exploits for this will appear in the wild.

Ah, bollocks to it - I've been meaning to test how well the Smoothwall traffic shaping / QoS mod works, and I can't be bothered to set up a torrent...

Linky clicky goodness...

What about security?


I'm not usually one for ontological arguments, but in this case....Windows was designed from the ground-up as a single user system. OS X was not. I would agree with you that OS X is not superior in "every aspect" but I wouldn't say that the rest is at most, a wash.

They do. Any vulnerability in Linux-based distributions and/or Fruits gets a lot more spotlight than Windows ones.
However, the fact that you can see a lot more holes in Microsoft products is not accidental.

Also, don't forget that in Linux world, you will get security fixes for a bug that allows one user to mangle a shared scoreboard for a game on a multi-user box. On Windows, you don't get any bugs announced unless they are of the remote access kind.
According to Microsoft, they don't consider ways to crack a local system to be bugs.

Actually the best way is to use Fast User Switching. Have an Admin account and your normal one. Do Adminy stuff in the Admin account and everything else in the normal one. Once you get used to it, it's a couple of keystrokes to flip between the two. Unlike Run As, the two zones are on different desktops, which means that you're invulnerable to Shatter attacks windows running with admin privileges

Here's a good blog with much more info

Some people even prefer this to su.

Remember this?
More details here.
And here.
And is it still a viable attack even for WinXP? (I hear they're replacing the Win32 API for Longhorn, so maybe it won't be a problem there...)

Remember this?
More details here.
And here.
And is it still a viable attack even for WinXP? (I hear they're replacing the Win32 API for Longhorn, so maybe it won't be a problem there...)

There's a much nastier version of this: there is a message WM_TIMER which is meant for callbacks at regular intervals. One of its parameters is the address of a function to be called.

You can send this message to a window on your desktop and it will jump to any address you like! Straight away you could crash the process containing the window, or you could put some code to spawn a shell into an edit box in that program, then jump to that code. Hey presto! Instant shell running as Local System.

The attack is documented at http://security.tombom.co.uk/shatter.html, and can be used to inject code into any window on your desktop.

There doesn't seem to be any easy way to fix this, since security in Win32 messages is only meant to be at the desktop level and not the application level, and anything else would break lots and lots of applications.

Microsoft recommend stopping these attacks by never having a GUI in a service, instead having a separate GUI program that communicates with the service. But even they have made mistakes with this before - the pop-up Messenger windows (not MSN, the built-in Windows service) used to run in CSRSS, the Win32 server process. So you could get Local System access by sending yourself a message (which would cause the dialog to pop up) and then injecting code into CSRSS using that window.

According to http://security.tombom.co.uk/moreshatter.html, you don't even need a process with a window on the desktop - just find a system thread with a message queue and call PostThreadMessage on it.

There's a much nastier version of this: there is a message WM_TIMER which is meant for callbacks at regular intervals. One of its parameters is the address of a function to be called.

You can send this message to a window on your desktop and it will jump to any address you like! Straight away you could crash the process containing the window, or you could put some code to spawn a shell into an edit box in that program, then jump to that code. Hey presto! Instant shell running as Local System.

The attack is documented at http://security.tombom.co.uk/shatter.html, and can be used to inject code into any window on your desktop.

There doesn't seem to be any easy way to fix this, since security in Win32 messages is only meant to be at the desktop level and not the application level, and anything else would break lots and lots of applications.

Microsoft recommend stopping these attacks by never having a GUI in a service, instead having a separate GUI program that communicates with the service. But even they have made mistakes with this before - the pop-up Messenger windows (not MSN, the built-in Windows service) used to run in CSRSS, the Win32 server process. So you could get Local System access by sending yourself a message (which would cause the dialog to pop up) and then injecting code into CSRSS using that window.

According to http://security.tombom.co.uk/moreshatter.html, you don't even need a process with a window on the desktop - just find a system thread with a message queue and call PostThreadMessage on it.

If the windowing system is part of the kernel (and I believe it is), Windows NT is insecure, as already demonstrated so decisively. And yes, the integration of ActiveX has resulted in a huge hole (e.g. the stuff MS Blaster exploits).

That's what I meant by insecure.

I use OpenBSD. I wouldn't use Linux, but I would use another BSD (or perhaps even the NT kernel, if they fixed the two aforementioned holes).

Windows CE doesn't sound like it is so awful now. But if you can still do the shatter exploit, that's shoddy, and I'd wait until they rewrite it again, with feeling.

Shatter attack

It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to. You can also fill the contents of a text box with a message.
Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user.
A creates a window on the interactive desktop (a big no-no) with a textbox in it.
B fills the textbox with exploit code with a message and then sends a WM_TIMER or similar to A with the exploit's address. A is now executing the exploit code.

First, there are ways to divide the window handle space into seperate parts, each securable with desktop and window station objects. Both of these are kernel object types with ACLs: you can't send a message to a window unless you have access to the conaining desktop.
Also, the JOB_OBJECT_UILIMIT_HANDLES flag for Job objects will prevent messages from leaving the job.
MS guidelines specifically forbid the use of windows from a priveleged process from appearing on the interactive desktop, since NT 3.51, for this reason. This doesn't stop many third-party app developers from creating insecure apps (virus scanners esp.) that do just that.
Winlogon's windows (press ctrl+alt+delete) are safe because they are on a seperate desktop that normal users can't send messages to.

The fact is, Windows has a solid, well implemented, priviledge system. ... and they are working on getting people away from running as Administrators.

You named one component. ActiveX is a subset of the IE component. Other than IE, do you have any other insecure components to mention?

Here are some. Some may be a year or so old, and I don't recall what links I sent as examples. Google should help you find all you need.

Microsoft software "riddled with vulnerabilities", trade body claims
30 unpatched holes in IE, says security researcher
Credit card theft feared in Windows flaw | CNET News.com
Microsoft Issues Five New Security Warnings
Microsoft WinXP Update spies on other PC software
Microsoft issues patch for "serious" XP hole
Microsoft Windows Insecure by Design (TechNews.com)
Server attacks stump Microsoft
Windows flaw threatens PC services
Gartner: Worms Jack Up the Total Cost of Windows
CERT recommends anything but IE
Exploiting design flaws in the Win32 API for privilege escalation
Worm Exploits Multiple Windows Vulnerabilities
Unpatched Internet Explorer Bugs

First off, we know you like *nix, but there is not "root" user in windows. Sorry to be surley, but how would you feel if some MCSE told you that you need to be "Administrator" to install a program globally in linux? Just because we don't liked Windows doesn't mean be have to be fucktards.

Thirdly, there is a problem, as i understand it, in the win32 message passing system. This design flaw allows a message to be sent to any running process without it's source being checked. This basically negates any kind of user-level security at the message-passing level. So, yes, any program could theoretically run without any kind of access control on windows. The grandparent's comment that windows is just like Unix if you set up user's and permissions correctly is wrong.

source: here Note also that i just woke up, and i could have made a few errors. In anycase, the site i linked to explains it much better than i.

The program doesn't have to be buggy per se; it only has to be running with enhanced privileges and have a "window" on the desktop. (Any representation on the desktop will do, even a system tray icon, if I understand correctly.) The vulnerability is in the Win32 API and widget set. The antivirus software in question was not buggy in itself (at least, not in a way that is relevant to the shatter attack), unless you count running with enhanced privileges as a bug.

This guy claims to have exploit code for at least 4 different processes on a default installation of Windows 2000. Unless he's full of bologna, I'd rate that as pretty serious.

Shatter is a privilege escalation attack. You have to already have some kind of user-level access to the system in order to use it. But it does allow any user on the system to get privileges. (This is particularly bad for a Terminal Services / thinclient situation, since any user on any of the thin clients can take over the whole server.)

That doesn't mean the local root vulnerability isn't there.

Any process can send any message to any other process. Talk about insecure.

Accourding to http://security.tombom.co.uk/shatter.html it is much worse than just that. Not only can anyone send such a message, but the messages can even force the receiver to execute arbitrary code.

>the NT series turned out to be fairly insecure, fragile, bloated monstrosities

What was the last member of the NT series you used?

XP. I use it fairly often. You are right, it is a great improvement over old NT's, especially in stability. XP very rarely crashes. However, it's still quite insecure. Bloat is a matter of taste; I consider KDE and Gnome to be bloated too, just not as bad as Windows. As for fragility... Maybe it's just my hardware, but I've had the weirdest issues with XP. For example, my sound card dissappearing after suspend/unsuspend, then randomly reappearing several reboots later. I would say that if broken power management handling causes you to lose devices, that's pretty fragile.

>the NT series turned out to be fairly insecure, fragile, bloated monstrosities

What was the last member of the NT series you used?

XP. I use it fairly often. You are right, it is a great improvement over old NT's, especially in stability. XP very rarely crashes. However, it's still quite insecure. Bloat is a matter of taste; I consider KDE and Gnome to be bloated too, just not as bad as Windows. As for fragility... Maybe it's just my hardware, but I've had the weirdest issues with XP. For example, my sound card dissappearing after suspend/unsuspend, then randomly reappearing several reboots later. I would say that if broken power management handling causes you to lose devices, that's pretty fragile.

WTF is NTen? no i cant be bothered to google it. I dont use Outlook dont be stupid, and fact is there are too many serious issues in windows that havnt been addressed just one example

Do you expect the Linux Kernel team to fix problems with Open Office? NO YOU DON'T! So why do you expect it from Microsoft?

The Linux Kernel team have nothing to do with OpenOffice, and the OpenOffice team provide an excellent piece of software for free! I would expect the makers of a commercial software product who also own the OS it runs on to produce bloody tight code, so in answer to your stupid question: YES I WOULD EXPECT MICROSOFT TO FIX OFFICE SINCE THEY CREATED IT!

While I agree that the author is poorly informed and mostly goes on one tangent after the other in this article, there are some problems with Windows that aren't easily fixed. This page, mentioned previously on /., is one example:

http://security.tombom.co.uk/shatter.html

There is a followup to this paper that discusses Microsoft response the it. The author isn't happy with the response.

The root of this issue is the Win32 API, and its origins as a real mode compatible API with no security, and no memory protection between processes. Much of the transition to Win32 seems to have been handled as a massive search and replace operation on the Windows headers, with backwards compatibility being considered more important than security.

Last time I checked, Jim Allchin (VP at MS) talked about "unfixable security flaws" on the stand at the antitrust trial. That alone has made me laugh any time Microsoft starts talking about their security measures. Therefore, I'll take any talk on security Microsoft makes seriously only after they announce a fix for their unfixable flaws -- things like shatter attacks.

I remember reading that they couldn't fix one massive security flaw without redesign on OS from ground up. Thus copping out by saying that if you got physical access to a pc, then you have no security.

As someone who works in security, "insecure by design" has a precise meaning to me, which I've not seen mentioned here yet. The developer's intentions have nothing to do with it. "Insecure by design" means every implementation of a given system will share a common set of security vulnerabilities. In other words, the design (think API or protocol) itself is flawed. No implementation is safe.

Example: The design of the http protocol does not provide any method of running arbitrary code from the client on the server. A perfectly implemented web server will contain no remote vulnerabilities of this type. Flaws in particular web servers like IIS are caused by mistakes in the implementation, not the http protocol itself. The protocol is secure by design with regard to this attack.

Contrast this with a protocol whose design is insecure. Nothing in the SMTP spec addresses the issue of spam. High-volume anonymous message injection is allowed by the protocol. Solutions to spam have to be implemented externally with things like blacklists and filters (which are considered external even when run during the SMTP transaction as they aren't part of the SMTP protocol itself). No SMTP server, no matter how perfectly implemented, can both completely follow the SMTP spec and reject all spam. Thus SMTP is insecure by design with regard to spam.

Nebulous terms like "windows" and "secure" mean next to nothing by themselves. What is "windows"? The NT kernel? The win32 API? The set of programs and services enabled by a default install? Secure against what types of attacks?

For reasonable definitions of the above, the statement "Windows is insecure by design" certainly makes sense. Take "windows" to mean the win32 API and "secure" to mean enforcement of access control. Remember the shatter attacks discovered last year? That's a flaw in the design of the win32 API. No implementation is safe. It fits the definition of "insecure by design" perfectly. And Microsoft has alluded to more such vulnerabilities lurking in the win32 API (remember when they said they couldn't reveal all the APIs for security reasons?).

But the reason it takes so long to fix them is stupid design.

The myth that complexity is only achieved through complicated design is pervasive in computer programming, typified in Windows, and becoming more prevalant in Linux applications as Gnome and KDE become the standards.

The UNIX operating system was highly complex even in the days when it was dominated by small programs that were designed with the The Unix Philosophy. Small programs that did one thing well were the rule and complexity was achieved by utilizing clean well documented interfaces, standard data storage formats (ASCII), and non-captive UIs. The result is that most bugs can be tracked down to a specific small program that can either be fixed relatively quickly by the maintainer, or be replaced with one of a number of equivalent programs (either permanantly, or until the bug is found and fixed).

Windows design is mostly large programs that try to do everything for themselves, although they do share library functions. The result is huge masses of code that can effectively hide bugs indefinately (shatter), cannot be replaced with another program without breaking the OS (integration), and that the company seems to think of as "not our problem".

The issue I have with the desktop environments is that they seem to be following in the footsteps of Windows design, creating a tangled mess of (what should be) unecessary dependancies, huge libraries, and code that no one person is inheirently familiar with. As yet, I am unaware of any security problems inherent in either Gnome or KDE, but I do consider it a bug that installing a spreadsheet requires also requires a sound library to work properly.

Complex ends can be achieved through simple means and complex programs or OS do not need to be complicated.

Man it seems like every day we find out how to define the 'trustworthy' in "trustworthy computing"

First Windows, then the Outlook bugs, then the Hotmail bugs, now the Windows Update security issues - not to mention the Shatter Exploit (fundamental unfixable Win API flaws)

Mmm I love days like today. :)

All the fuss is due to this. Among other things, the GUI of Windows has security flaws acknowledged by Microsoft. This overshadows any of the benefits that could ever be realized. Get rid of it, or replace it with a different, more secure GUI model, and you might have something.

Microsoft Baseline Security Analyzer (MBSA) and Microsoft's version of HFNetChk both failed to detect the presence of the well-known vulnerability in SQL Server exploited by Sapphire, which is one of the reasons so many admins (both inside and outside MS) had failed to install the necessary hotfix. MBSA and HFNetChk are Microsoft's official patch status verification tools meant to be used by all owners of Windows server boxes ...

...In addition to designing MBSA to avoid scanning for SQL Server vulnerabilities, failing to update mssecure.xml reliably and in a timely manner, deprecating HFNetChk by pushing the MBSA GUI as its preferred replacement, and hiding the details of the technical limitation

However, in February, Microsoft signed a pact with Chinese officials to reveal the Windows operating system source code. Bill Gates even hinted that China will be privy to all, not just part, of the source code its government wished to inspect.

Given the evidence suppporting Jim Allchin's testimony, the Microsoft corporation is behaving traitorously, by exposing national security issues to untrusted foreign governments.

Microsoft Baseline Security Analyzer (MBSA) and Microsoft's version of HFNetChk both failed to detect the presence of the well-known vulnerability in SQL Server exploited by Sapphire, which is one of the reasons so many admins (both inside and outside MS) had failed to install the necessary hotfix. MBSA and HFNetChk are Microsoft's official patch status verification tools meant to be used by all owners of Windows server boxes ...

......In addition to designing MBSA to avoid scanning for SQL Server vulnerabilities, failing to update mssecure.xml reliably and in a timely manner, deprecating HFNetChk by pushing the MBSA GUI as its preferred replacement, and hiding the details of the technical limitations

I think a timeframe needs to be established. Those who find exploits in programs have a moral obligation to let the maintainers of the program know first and give them a reasonable amount of time to fix the problem.

But what is reasonable? A week? A month? What if the exploit is a deep flaw in the system, something that cannot be fixed?

So, how long is long enough to keep an exploit from the general public? Does it depend upon the exploit, the company that makes the product, or the person who finds it? Is there a balance to be found?

No. People are praising one group of developers who have been paying extremely close attention to security issues for years because they've released yet another useful to deal with a potential exploit.

On the other hand, people are lampooning M$ for pretending that one measly month of developer work to will address security problems they've been introducing into their application software for years. Really, it's little more than a Band-Aid(tm) to assuage the fears of CIOs.

For what it's worth, Microsoft has it's own very serious local privilege escalation security hole which may not even be possible to fix because it's partially due to a serious design flaw. Read more about it here. (How to "shatter" Windows... funny, eh? :)

It's exactly that kind of gaping security hole that the OpenBSD developers work so hard to avoid. That's why they are praiseworthy, and why we scoff at Microsoft's belated efforts to patch up security issues that should have been accounted for from the very start.

Yeah, as long as you don't consider a Shatter attack.

Microsoft vulnerabilities are almost all in the explicitly internet related microsoft tools.

Shatter Exploit?? Come on. This exploit is worse than any of the ones listed.

Those other flaws are weak in comparison to one where someone can own your university network.

You can't just reinstall IIS when you get '0wned' because people are stupid. If they set their permissions right, then IUSR_MACHINENAME wouldn't have any rights to anything outside of the web root. Therefore, code red would have gotten a big fat access denied when it tried to spread. And yes, that issue is a big one, but you must be AT the local machine. This meens that a couple of middle-school kids will be able to get around the security of their class room Compaqs.