New Windows exploit: "Shatter"

[MaggieL]

This is a pretty severe hole. Read the white paper, then let's discuss:

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

[jaguar]

Interesting, but it requires access of some sort, so its not going to worry me. On the other hand i'm going to have fun in IT tomorrow if i can find debugger without install.

[Tobiasly]

Exactly. No longer will I have to wait for the helpdesk to give me administrator access!

This looks like it could be huge. Sure, it requires access, but as it mentions, so many corporations focus on restricting access for particular users, not as much in preventing anyone from getting in by any means.

Of course I'm not too familiar with such low-level Win32 API calls, but everything the author describes seems to make sense. Windows does seem to be pretty lax about what certain processes can do with other processes' windows. I remember a couple years back, there were various "password revealer" programs that would un-hide passwords in on-screen windows. All it had to do was grab the h_wnd and change the attribute for "password" to false.

MICROS~1 fixed their libraries so that passwords were hidden differently, and so the revealer programs no longer work. But that was just covering up one particular side effect of this bigger problem. It will be interesting to see how this plays out.

[jaguar]

Its been known for ages, this is just the first as-easy-as-BO-is sploit for it. Personally i think the biggest use is blackbag jobs, drop a cd into a drive on a corperate workstation, get root, install phone home software and get the hell outa there.

[headsplice]

Isn't it interesting that if M$ knows (and has known) about this, why do they continue to build WinBlows with this same kind of messaging? They completely rebuilt Xp (from the ground up), why not plug holes along the way? (Oh yeah, becuase they don't HAVE to).

[Tobiasly]

This isn't a "hole". It is the very heart of how the Windows operating system works, as explained in the article. Did you get to the "Fixing the Problem" section? Which of those solutions would you suggest?

[MaggieL]

Originally posted by jaguar
Interesting, but it requires access of some sort, so its not going to worry me. .

Right...nobody ever got hostile code running on their Windows machine without a black-bag job. *Not*!

The problem here is that *any* hostile code can privilege-escalate to any level owned by any window on the desktop...visible or not. As a side note, it can manipulate any window present on the desktop too.

I like the passagne in the "response" from MSFT:
<blockquote><i>
In our essay, the "Ten Immutable Laws of Security", these are Law #1-- "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore..."
</i></blockquote>

That would apply to the new EULA for XP SP1 too, I guess.
It's Bill's computer, now. :-)

[MaggieL]

Originally posted by Tobiasly
This isn't a "hole". It is the very heart of how the Windows operating system works, as explained in the article.

It's a fragging big hole. That it's in the core of the architecture doesn't make things better, it makes things worse.

Did you get to the "Fixing the Problem" section? Which of those solutions would you suggest?

As the author points out, none of them are viable. This is why Allchin was holding forth that they can't open the Windows source...he was afraid people will find this...and probably some other stuff they've been hiding too.

[Tobiasly]

You're misinterpreting my reply, Maggie. Headsplice asked "why not plug holes along the way", as if this were simply a buffer overflow or other such common "hole" in Microsoft's software. When I say "this isn't a hole", I mean this isn't something they can just apply a simple patch for.

So yes, it's a friggin' big <I>security</I> hole, but it's not a hole in the sense of a bug, or an inadvertent side effect of a particular operation that a program performs. It's the very underpinnings of the way processes communicate with the OS. They designed the OS to operate this way. It just turns out it's not a very good design.

And my "Which of those solutions would you suggest?" was rhetorical. Again, pointing out that the notion of Microsoft "fixing" this problem in a simple service pack isn't gonna happen.

[headsplice]

Tobiasly,
you're misinterpreting what I said. Windows was completely rebuilt. They started from scratch, with no reused code (though the same underlying architecture). When I said 'plugging the holes' like this messaging problem, I should have stated 'not recreated the same holes by reusing the same crapass architecture'.

[Tobiasly]

They did nothing nowhere near rebuilding Windows from scratch. Windows XP uses the NT kernel. True, this is the first <I>consumer</I> version of windows that uses the NT kernel -- 95, 98, and ME were all just glorified DOS programs -- but they didn't rebuild it at all.

That would have required years of man-hours in coding time, not to mention breaking the functionality of any program written for previous versions of Windows that wasn't rebuilt to use a new Application Programming Interface. This message-passing architecture is how Windows works, and it's how programs written for Windows communicate with it. As the article points out, if they "fixed" this problem, all previous programs written for Windows would stop working.

[headsplice]

Actually, it was Windows 2000, now that I look back at articles and discussions. My apologies for the error. Yes, it took lots and lots of man-hour-years to rebuild Windows.
But, the point still remains that they are the single largest software provider in the world, and their product has undergone at least two major revisions in its lifetime (or more, depending on your criteria). They could have gone out on a limb and made the necessary changes in the underlying architecture with the release of Windows 2000 (since they had so many compatiblity problems anyway). Arguably, they should have made those changes had they known about the possiblity for this kind of exploit (and I find it hard to believe that they didn't).

[russotto]

I already have machine admin access, but this sort of thing should give full access, to e.g., clearcase. All I have to do is get it to pop up an error window and _shazam_, I can operate as the Clearcase user.

[MaggieL]

Originally posted by Tobiasly
You're misinterpreting my reply, Maggie. Headsplice asked "why not plug holes along the way"

Sorry...but my first post opening the thread was "This is a pretty big hole." Thought you were replying to me. :-)

So yes, it's a friggin' big security hole, but it's not a hole in the sense of a bug..."

Well, there are two major kinds of software defects: failures to implement the design as intended, and failures *of* the design to meet requirements. This is one of the latter.

One could argue (pointlessly) about whether that's a "bug" or not. Certainly MSFT's public response to the report is "working as designed". Of course their private response was "Shit, I hope nobody notices what a nasty vuln this is, because it will be incredibly difficult to do anything about it".

And ultimately, it will serve as one more excuse to tighten the restrictions on what code is allowed to run on Windows. Ultimately I expect to see nothing permitted to run that isn't signed by MSFT....and that only if they think your licence is current.

How long before you start paying by-the-drink to use Windows?

[jaguar]

Maggie i agree its serious but it does not worry ME personally about access to my computer. There are no servers running, i'm behind a tight firewall, up to date antivirus, IDS on firewall, IDS on here. Firewall exploit patched daily. If someone wants to break into my house and get access this would be a rather small worry. but for corps etc yes i agree its very serious, i'm taking tools today to attempt it on our school network.