New Windows exploit: "Shatter"
 

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

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

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.

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.

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.

"if it ain't broke, hit it again"
 

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). :mad:

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?

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. :-)

It's a fragging big hole. That it's in the core of the architecture doesn't make things better, it makes things worse.
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.

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.

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'.

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.

Bass-ackwards
 

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).

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.

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

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?

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.

Re: Bass-ackwards
 

I'll make my case once more and then let this die. They did not rebuild Windows for 2000. They didn't rebuild it for XP. One could argue that the original Windows NT was rebuilt, but that was hardly "from the ground up", since it had to have a considerable degree of backwards compatibility with previous Windows versions.

The low-level API message passing structure, which is the cause of this problem, remained largely the same when they wrote NT. It had to be, and has to be, because otherwise Windows programs would stop working.

But regardless, my point is that your frustration at Microsoft not "plugging this hole" is unfounded. Be pissed because they wrote a crappy OS with such a shaky foundation. Be pissed because they try to extend thier desktop-OS monopoly into every other market. Be pissed that there's no OS-level mechanism for preventing crappy programs like AOL from spewing shit all over your desktop and rearranging your file extensions. But you can't be pissed that they're not fixing this problem, because as the article points out, it's pretty much unfixable.

If you still want to state that they rewrote Windows from scratch, please provide links to the articles you're using for reference.

btw maggie, this HAS to be a blackbag job - it requires physical access. Although you could *in theory* i *think* do it over some kind of remote desktop app, but i wouldn't be sure.

<b>This particular exploit</b> requires physical access. That doesn't mean that a program downloaded from CNET's download.com couldn't do it too. And I'm sure a remote desktop app would work just dandy.

Who knows how this flaw can and will be exploited...

You'd be sure if you'd actually read the whole paper.

Appropos of some of the dismissive attitudes about this paper, I'm including a response from the editor of the reasonably authoritiative NTbugtraq...
<blockquote>
From: Russ <Russ.Cooper@RC.ON.CA>
Subject: Re: White paper: Exploiting the Win32 API.

Boy what a flurry.

Most people posting are saying;

a) This is a non-issue, its entirely due to poor programming practice. Bad Vendors write services marked as SERVICE_INTERACTIVE_PROCESS, install as LocalSystem and autostart, then add a GUI or any other sort of message receiver. The bind to WinSta0 and, as a result, open themselves to attack. Bad Bad Vendors.

b) But, since we've known about this issue for so long, nobody ever does this (note exception in point #1 above).

c) Oh, and since you need to get code onto the system in order to do this, *this* stuff is irrelevant, if I can get code on your system you're already owned.

Since dullien@gmx.de decided to post saying that this FUD was, in part, my fault for allowing it through, my observations follow;

1. There are far too many Bad Bad Vendors.

2. How you going to check to see if a Vendor is Bad or not? Look to see if his service installed as LocalSystem?? That's no answer. Look to see if he has a Window as part of his interface? That's no answer. Ask them?? Yeah, right! Paget has, at least, provided a tool and explanation sufficient to start checking. Certainly not a solution, but I have a stinking suspicion most of you weren't checking before this paper...despite it being so old and, for some, so well known.

3. Am I the only one who noticed Paget's reference to DDE Server??? Did I miss that reference in the past research others have pointed to?

4. To the bit about owning a machine because you got code on it...come on. You can't own a machine until you get code on it, whether that's via a flawed ISAPI filter, malicious email, web page, or virus. When exploitation of AEDebug was discovered it wasn't deemed a non-issue. If every virus ran in the context of LocalSystem, viruses would cause far more damage than they do today. Its also worth considering auditing in all of this.

5. More than a few people have said he hasn't proven his contentions wrt the OS being vulnerable (e.g. DDE Server or something else that ships as a default component of an OS). I, for one, am glad that he has, so far, chosen not to provide a sample exploit prior to MS' analysis. Be skeptical all you want, but some of the messages I've read could be poster children for the reasons some discoveries come out as 0day exploits attacking you en-masse.

IMO the dismissive attitude towards Paget's work comes from his contention its an "entirely new class of attacks". Fine, argue that if you want, make him humble himself before all those who previously discussed these issues, but thank him for a tool and recent analysis that brings it to our attention again.

At the very least his paper held the tool, a security vulnerability in Viruscan, and an indication that DDE Server may be vulnerable.

Cheers,
Russ - NTBugtraq Editor

</blockquote>

'Entirely new class'
 

Well, it's true that it's NOT an entirely new class of attack. It's somewhat similar to the old TIOCSTI/TIOCNOTTY (a.k.a ttydev) attack on UNIX, and related attacks against x-windows (ask a certain UMCP sysadmin about xhost -- I think his systems were rooted by every hacker at the place)

This one's even broader in scope, though -- those only gave you control of the running program. This gives you full access AS the running program.

Ill read over it again. The first time i was replicating it as i went.

Dham the way i see it you need to have a remote desktop app running, physical access to a way of executing arbitary code on the machine. If you've alredy used another exploit to run code this woudl not be the most efficient way to raise your privliges.

The key thing is you need to have a window you can enter text and you need to know its window handle. I'm not familiar enough with the windows API to know if you could get the handle without a desktop but you could open a window up by opening a new process. Either way you need to be able to execute code on the machines which requires some privliges.
For corperate networks its gonna be hell, we're gonan be installing a few things at school in the near futures as it is but its not a remote exploit the same way a hole in OpenSSH is.