Shattering Windows

ChrisPaget writes: "I've just released a paper documenting and exploiting fundamental flaws in the Win32 API. Essentially, they allow you to take control of any window on your desktop, regardless of whether that window is running as you, localsystem, or anywhere in between. The technique has been discussed before, but AFAIK this is the first working exploit. Oh, did I mention it's unfixable?" You may want to read this CNET interview with Microsoft security head Scott Charney to learn even more about "trustworthy computing."

Comments

Someone discovered Windows is insecure.

[SpanishInquisition]

Film at 11

Isn't this in the EULA anyway?

[Dynamoo]

"Essentially, they allow you to take control of any window on your desktop".. sounds like it's straight out of Microsoft's new EULAs.

Ummm... 'Kay

[handorf]

So basically you're saying that if you can get a user to run arbitrary code and that user has access to applications with higher access rights, you can get those access rights.

If you can get the user to run arbitrary code, they're already dead.

Not to say that windows is secure, but this seems to be picking nits to me.

Re:Ummm... 'Kay

[ptomblin]

You misunderstand. He's talking about NT/2000/XP, where you have privilege and non-privilege accounts, and where even as a non-privilege account, you can have stuff running as the Windows equivalent of "root", and you can use any window that "setuid root" application pops up to root the box yourself.

The example he gave is the anti-virus program that runs with administrator privs (because it has to do stuff to the registry), when you're logged in as Joe User without admin privs. The anti-virus program pops up a window, and bam, you've hijacked the window, given yourself admin privs, made a new administrator login for yourself, and you're away to the races.

Re:Ummm... 'Kay

[Wumpus]

Actually, with careful timing, you might be able to pull this attack off on an app that doesn't have ANY windows. If the application in question makes use of the WM_COPYDATA message, this might prove to be trivial. Even if it isn't, you can still map arbitrary data into an application's memory space using WM_COPYDATA.

Here's the WM_COPYDATA documentation. Read it and tremble in fear.

Re:Ummm... 'Kay

[Wumpus]

You missed the point, I'm afraid. Once the data has been copied into the exploited app's address space, nothing the developer does can secure it 100%. The described exploits relies on two properties of the Win32 API:

1) It lets you copy arbitrary data into another process.
2) It lets you force another process to jump to an arbitrary address by faking a WM_TIME message. It's actually the default window procedure that does this.

So, in theory, there should be a certain class of applications that would allow you to inject an exploit into their address space, using WM_COPYDATA, and then jump to that data (from another thread, possibly, introducing the delicate timing issues), and executing it. Note that this can be done before the application code gets a chance to look at the WM_COPYDATA message.

Upon closer reading of the WM_TIMER message documentation, several things come to mind that could make this attack less problematic. The OS could filter all WM_TIMER messages, and discard the ones whose LParam doesn't contain an address that was previously registered as a timer callback.

Re:Ummm... 'Kay

[davebooth]

The point remains that it isnt a question of "a user runs unknown code, they're screwed" - in this scenario the USER is the attacker.. they already have a legit account but it doesnt have administrator privs. They want to get past some restriction on their account - like maybe locate and disable any nasty corporate keyloggers that might get them fired for pr0n-mining, or plant some nasty stuff on a shared PC to grab other accounts credentials so somebody ELSE gets fired for it? Lots of attacks come from inside and lots of *nix attacks are described as "local root" compromises - thats what we have here.

To rephrase your statement its more a question of "if a user can get localsystem privs by running arbitrary code, you (as the sysadmin) are screwed."

This isnt specific to windows or any other OS for that matter. If any user can get arbitrary code to run with a higher privilege level than their own, this kind of hole exists.

Re:Take control?

[Moridineas]

Why on earth is it crashing? Check your event logs. That should NOT be happening--sounds for sure like a hardware failure.

Here's the output from the "systeminfo" command on my work computer fyi:

Original Install Date: 3/15/2002, 11:24:37 AM
System Up Time: 60 Days, 6 Hours, 36 Minutes, 21 Seconds

Fixability

[Wrexen]

What's to prevent an administrator from installing a Message Hook that eats all EN_* or WM_TIMER messages sent between processes? Since your DLL would be living in each process space, you could detect inter-process message sending and block the attack from ever leaving the Shatter process. I don't see any reason why this shouldn't work

Re:Fixability

[erasmus_]

Finally, a constructive response to the problem. However, since you still don't have the capability of seeing what the source of the message is, I don't see how you can drop all of those messages with 100% certainty. Those API calls are there and are used legitimately as well, for better or for worse. So although your way coulf fix things, I wouldn't be surprised to see it breaking some applications along with it.

Re:Fixability

[b0bd0bbs]

AFAIK you can still allocate ring 3 descriptors via windows DPMI calls, change them to ring 0 descriptors via an LDT mapping (which is legal in pmode the way windows sets things up), then execute any code in your program as ring 0. Woohoo. That *feature* has been around for at least 6 years.

Read the BugTraq replies first

[pbemfun]

Before jumping to conclusions, read the reply to the "vulnerabilities" on the BugTraq mailing list here. Doesn't look like its something unknown to the public and its really more of a vendor problem, not MS one.

Evolving Concepts at Microsoft are Frightening

[guttentag]

We're doing this thing called "Trustworthy Computing." It's an evolving concept.

It starts out meaning "We are worthy of your trust."

Then it evolves to mean "You trust us."

Then it evolves to mean "You trust only us."

Then it evolves to mean "All your base are belong to us."

Re:Evolving Concepts at Microsoft are Frightening

[rseuhs]

Actually, the most important part of Microsoft-trustworthy computing is:

"We don't trust you."

Re:Is this really a security risk?

[topham]

A user opens a damn attachment, which you've told them not to do a hundred times, but one of them does it anyway...

No problem right, the attachment runs as that user and the damage is restricted? Only it isn't, because the attachment escalates itself to localsystem privledge and now starts really screwing around.

With any luck it drops itself on the network somewhere and some other soul mistakenly runs it and it gets domain privledges...

Yes, but who's fault is it? Not MS'!

[Otis_INF]

When I put a service on Win2k, running under 'System' and that service listens to a port and executes all the crap that is posted to that port, is it MS' fault? No. It's the fault of the developer of the service.

Now, under win32, the application you start, runs under the user you log in with. The virusscanner window in the example, SHOULD run under the user that is logged in, but instead, it's a GUI created from the service, running under 'System'.

Bad programming. Not from Microsoft, but from the Virusscanner developer. They should have created, AS stated by MS, a GUI less service (the virusscanner engine) and a GUI application which talks to that service via a named pipe or any other process communication mechanism. That GUI should then be started by the logged in user (since that user sees the gui and works with it), so there wouldn't have been ANY flaw like this, since the GUI isn't ran under 'System', but under the user who's logged in, in the example the 'guest' account.

It sounds serious, it's absolutely nothing.

Oh, and it takes a local user to exploit it. Get a huge hammer and give it to the local user. Ask that user to smash the computer. There ya go, a DoD attack which isn't fixable, you can get that attack-script at any hardwarestore.

Re:Yes, but who's fault is it? Not MS'!

[jasen666]

Log onto your w2k box as "guest". Open the "computer management" window. Go down to users and attempt to add a new one. The dialog opens up. Yes, even guests can at least open the dialog. This dialog runs as system. I can use this exploit now. Thank you.

Re:Yes, but who's fault is it? Not MS'!

[Doomdark]

that service listens to a port and executes all the crap that is posted to that port, is it MS' fault?

One more commenter who didn't even read the article aren't you? The exploit doesn't require app to blindly trust the user. App unfortunately does trust Windows API not to do stupid stunts like allowing certain messages (that may or may not originate from another app -- there's no way to tell either way!) to get to execute stuff without app having a clue as to what hit it. It's like opening a socket for doing basic network communication and Windows API allowing certain pre-determined 'helper' messages to be handled by OS before your app has any say to handling.

You are of course right about UI separation part -- as long as Microsoft really has made it totally clear that's what has to be done, for the security reasons article explains.

And as to needing a local user... yes. It's not a perfect remote hack. But that hardly invalidates the claim this is a serious issue, esp. for certain applications.

Re:Don't Do That

[Rick the Red]

Exactly! You could write a similarly flawed Linux application that someone could exploit to gain root access.

Some Windows apps are not secure. News at /.

no, no.....

[Lord_Slepnir]

Their EULA reads "Essentially, you will allow us to take control of any window on your desktop." Glad I could clear that up.

High opinion

[timothy_m_smith]

Here is what the author had to say about himself at the end of the paper:

Foon, AKA Chris Paget, first started programming on a ZX81 at the age of 4. He's been working with computers for longer than most of the bosses he's had. After extending a BBC B to include an ADC capable of filling the machine's memory in less than 2 seconds and scaring the cleaners with automated voice warnings when they entered his room, he got bored and moved onto PC's and Windows, where the majority of his skills lie. Able to program in 23 languages on 14 platforms, Foon takes an average of 3 days to learn a new programming language. He's currently available as a freelance security consultant - his CV is available on request.

Aren't we the most important programmer ever!

Re:High opinion

[Anonymous Coward]

He also has never talked to, nevermind had sex with, a woman. He finds that he has trouble making friends, partially because of his inability to talk about anything besides the 23 languages and 14 platforms he can program for, and the onion-like smell which lingers behind is unshaven, rarely cleaned body. In order to make up for his indescribably small penis, Chris brings up debate in favor of technologies to boost his ego such as functional programming, UNIX, and any one of the 23 languages on 14 platforms already mentioned twice before that he can program for and you can't.

Re:High opinion

[greygent]

This poster finds it narcissistic and silly that the author wrote about herself in the 3rd person.

Re:Don't Do That

[rjh]

This isn't a flaw in the win32 API. This is a flaw in some applications which run under windows.

No to the former; yes to the latter. The reason why this is a critical flaw in the Win32 API is because it means that in order for code to be secure it is essential that every existing piece of software be carefully checked to make sure it separates interface from back-end.

If you're talking about a large enterprise installation with lots of closed-source apps and a vendor turnaround time on security issues which runs into the months--and there are a lot of them out there, make no bones about it--then your boxes are at critical risk. In that case, you're essentially guaranteed to have at least one app an attacker can root the box through. Sure, it may be the app's fault for not separating interface and back-end sanely, like most of us who give a damn about good engineering learned (sometimes the hard way)... but it's also the Win32 API's fault for not requiring separation of interface and back-end [*], it's the Win32 API's fault for being so shoddily designed that an attack like this becomes possible in the first place.

A good analog in the UNIX world is sprintf(), which has been responsible for more stack-smash attacks than probably any other thing. Even though we have snprintf(), most people don't know snprintf() exists or why it should be used. Like the Win32 window exploit, our sprintf() vulnerabilities will continue for as long as people write stupid code. Like the Win32 window exploit, we can't fix the problem by removing sprintf() [**]. All we can do is provide snprintf() and hope and pray that people use it.

sprintf() is a flaw in the UNIX/C API which has led and continues to lead to attacks against the system, facilitated by stupidly-designed software which uses the call even when snprintf() is available. sprintf() can't be removed without breaking literally thousands of stupidly-written apps which depend upon it.

This Win32 attack is a flaw in the Win32 API which has led and continues to lead to attacks against the system, facilitated by stupidly-designed software which doesn't separate interface and back-end. This Win32 attack can't be removed without breaking literally thousands of programs.

Hey, guess what, world? We've found Win32's version of sprintf(). Oh, happy day.

My condolences go out to any security engineers working in Win2K land. You guys have got your work cut out for you minimizing this exploit.

[*] Not that I have any idea how they could do this.
[**] sprintf() is defined in C89. Good luck getting rid of it.

Re:Take control?

[MORTAR_COMBAT!]

completely agree. nearly ever XP and 2K blue screen i had was due to:

1) faulty hardware, e.g., bad memory chip
2) incredibly bad driver (which admittedly shouldn't crash the OS... but that's another discussion)
3) incredibly, incredibly bad software (which again shouldn't crash the OS... but that's yet another discussion)

Windows Exploit - most dangerous!

[teamhasnoi]

Look for a period by itself on the bottom left of the screen. It looks like an off-pixel. Hold down "Shift", then click on it.

Bam! Root access.

This works on the systems of the DMV, FBI, DOD, Equifax, Telephone and Utillity companies.

I couldn't believe it myself! I said, "This is so easy, even Sandra Bullock could hack this!"

Have local access? Try Locksmith.

[Futurepower(R)]

The method in the article seems like a lot of trouble.

This software provides you a new administrator password: Locksmith.

Re:Don't Do That

[handorf]

How dare you have a reasonable opinion on slashdot! My army of trained flamemeisters has been dispatched to beat you about the head and neck with copies of "The Road Ahead"

Windows is insecure. Linux is insecure. PROGRAMS are insecure.

Won't work because of multi threaded/process apps

[Vicegrip]

Many applications actually use Windows messages to synchronize themselves between threads and processes.

In fact, there is also an API called PostThreadMessage that will post any windows message to any win32 application (all you need is the thread handle) with a message pump.

Out of process COM interfaces using windows messages will also be broken by removing this functionality.

Microsoft's excuse that having physical access to a machine is required is abysmal.

not just physical access

[MORTAR_COMBAT!]

it works across terminal server, also, which means you bring in a terminal client and plug in, get access to a user account (think there aren't any giant post-it notes of "my login/password" on half the desks in any given office?), and viola. they have rooted the terminal server and can do whatever the hell they want.

the terminal server may be behind 8 inches of steel and plexi-glass. but this compromise shatters that, too.

Re:Don't Do That

[cpeterso]

sprintf() is defined in C89. Good luck getting rid of it.

Why not? GNU prides itself in being "not Unix" and has been known to write code with identifiers like POSIX_ME_HARDER. Why can't glibc help make the world a better place by dropping dangerous functions, such as gets(), sprintf(), strcpy(), strcat(), etc. Safer alternatives to these functions exist and their use should be forcefully encouraged.

If glibc does not want to break source compatibility so drastically, they could move the dangerous functions to a new header such as "bufferoverflow.h". Or require the user program to #define GNU_BUFFER_OVERFLOWS_PLEASE before including stdio.h.

Sure this makes porting to GNU slightly more difficult, but I think GNU can pull this off because they have enough clout with developers and no profit motive to worry about!

What a load of tripe.

[Uller-RM]

I'm really, really disgusted that this even got posted. This isn't a Win32 vulnerability, it's a Virusscan vuln. (Watch my karma burn, I'm actually defending MSFT... but hear me out.)

For those of you who aren't familiar with Windows programming, here's what he's doing. Viruscan's GUI is very poorly written and doesn't check for a maximum length on a text box's input. So, he adjusts the size of a textbox using an outside program to 4GB. (Windows unfortunately allows this, since the message format doesn't include a "sender" field to check against the owner handle.) He then inserts shellcode in it, attaches a debugger to the process and searches all of memory for the start of the shellcode. Real efficient, this one.

He then sends it a WM_TIMER message to trigger it. WM_TIMER is usually sent to your window on a regular interval when you've called SetTimer(), and contains either an integral ID or a pointer to a callback in memory. So, he sends it a fake WM_TIMER, and Viruscan executes the callback blindly.

You know what, I use WM_TIMER too in my apps - but, there's two simple ways to defend against it.

if ((void *) msg.lparam != known_cb_address)
{
return false;
}

if (0 != IsBadCodePtr((FARPROC) msg.lparam))
{
go_fuck_yourself();
}

And if I'm not using it, special-case it so that it doesn't fall through to DefWindowProc().

Seriously, all this guy is doing is buffer overflowing a poorly written program to get Administrator privs. That's like claiming that glibc is insecure and should be thrown out because it has sprintf() or gets(). Ya know, I can buffer overflow a poorly written suid app too, but that doesn't make the libc to blame, nor have we published articles lambasting the GNU Project for not putting bounds checking into those functions.

This guy's just trying to sell himself, and you guys were more than helpful. Maybe I should write a system service that subclasses MSIE's WndProc with a single function that calls ExitProcess(1), and see if Slashdot will find me a security job.

Re:What a load of tripe.

[Glorat]

Sorry, I disagree with many of your comments here. While you've successfully tried to be objective without flamebait, some of the facts you have aren't true. I will try to be equally objective

This isn't a Win32 vulnerability, it's a Virusscan vuln
It is a Win32 vulnerability in that it is even possible to have this kind of elevation of priveleges by "poorly written" services. Basically, any system service that interacts with the desktop is vulnerable (virus scanners). McAfee interacts with the desktop. This is bad too.

Viruscan's GUI is very poorly written and doesn't check for a maximum length on a text box's input
It does, it has a set a maxlength of 4. Unfortunately, the vulnerability allows this to be bypassed. I'm sure the GUI will complain when you press the OK button but since we never get that far, the app never gets a chance to check the length change.

He then sends it a WM_TIMER message to trigger it... but, there's two simple ways to defend against it
That's good practice but the real problem is where you comment yourself... And if I'm not using it, special-case it so that it doesn't fall through to DefWindowProc(). It's too much to ask any app that doesn't use WM_TIMER to put in this handler in all their apps. Further, I bet WM_TIMER isn't the only message he could use to trigger code.

Seriously, all this guy is doing is buffer overflowing a poorly written program to get Administrator privs
Not any poorly written program but all desktop interactive services in existance.

Ya know, I can buffer overflow a poorly written suid app too
Fortunately, the community tends to be able to fix these things by patching the source. There is no fix for this problem

This guy's just trying to sell himself
OK, I will agree with you here... a little

Maybe I should write a system service that subclasses MSIE's WndProc
No no no... you've cheated. As a system service, you already have priveleges. The exercise of this paper was to do with with Guest priveleges

Regards,

Re:What a load of tripe.

[Uller-RM]

Every window's internal structure includes a pointer to a function called a WndProc. The function reacts to messages, and effectively defines how and what that window does.

The problem is that the vast majority of apps out there look like this, mainly since Microsoft uses this structure in their own books and help files:

switch(message_type)
{
case WM_CREATE: ...
case WM_LBUTTONDOWN: ...
etc...
default:
return DefWindowProc(hwnd, iMsgType, lParam, wParam);
}

Microsoft provides a moderately reasonable default procedure to fall out to, so that programmers don't have to write a case for every single one of the myriad standard messages.

The problem is that DefWindowProc doesn't check the validity of a code pointer before executing it, it just automatically jumps to any function specified in a WM_TIMER message.

So, without changing that function, any program that doesn't explicitly check for WM_TIMER is vulnerable... if there is a way to insert shellcode into the process' memory space. The exploit in the article can do it because Viruscan doesn't sanity-check their text boxes, so he can paste up to 4GB of material into the box, and tada.

How do you rescind acceptance of the EULA?

[burgburgburg]

When the Windows Media Player patch came out, I installed it on a box that I sometimes use. It was only later that I found out about the DRM component of the EULA. I immediately removed WMP. But does that legally rescind my agreement?

I'm asking a legal question: does removal of the software constitute rescinding your agreement? Or if Microsoft has somewhere noted your initial agreement, is it in perpetuity? Does Microsoft permanently own that box?

Re:How do you rescind acceptance of the EULA?

[DavidBrown]

Well, if you violate the EULA, you are in breach of contract. If you remove the software, you will be limiting your damages to the damage you caused prior to the removal. But the real question is this: Is Microsoft going to sue you? No, unless there are damages.

Is Microsoft damaged if you use their products to steal music? No, unless Microsoft gets sued by RIAA for providing software that facilitates your violation of copyright and then loses, after which they'll come after you in an action for indemnity. Until then, Microsoft isn't going to get anything from you in a courtroom because you haven't caused them any damage at all - and that means until RIAA and the MPAA sue Microsoft, you don't have anything to worry about.

Re:Virus in his code

[kawika]

Duh! The exploit is *intended* to be malicious code that causes a buffer overrun in an application and could be used to break into a system. That's the point!

Hint to moderators: Try "Funny" next time.

Re:Don't Do That

[bwt]

sprintf() can't be removed without breaking literally thousands of stupidly-written apps which depend upon it.

Isn't this precisely the set of programs that need to be broken, so they don't allow root?

Re:Don't Do That

[ChrisPaget]

Actually, probably not - I researched this when writing Shatter. When you hit CTRL+ALT+DEL you actually switch desktops from the "Default" desktop to the "Winlogon" desktop. A program on one cannot interact with a program on another. There are functions to "open" a desktop and interact with it - however the Winlogon desktop is tightly restricted, and any attempts to open it are met with an Access Denied error.

Either way, there's numerous windows (normally hidden) on a standard desktop that run as localsystem - it's possible to exploit some of them using the same techniques.

Re:Don't Do That

[pclminion]

Why can't glibc help make the world a better place by dropping dangerous functions, such as gets()

Because that's ANSI/POSIX standard.

sprintf()

Because that's ANSI/ISO/C99 standard.

strcpy()

Because that's POSIX/ISO standard.

strcat()

Because that's POSIX/ISO standard.

Are you done ripping on GNU now?

This is the absolute stupidest thing Ive ever hear

[gamorck]

Look... I'm in no hurry to defend Microsoft but being as I develop for their OS on a daily basis - its common knowledge (or should be) that anybody who runs a service under system privileges that presents a GUI to any old user - is a fucktard that simply needs to die. Yes this problem can be fixed by MS using the 2nd option indicated in the paper and yes it would mean these crappy designed apps written by third parties would have to be rewritten.

Microsoft specifically reccommends that you do not run services and allow them to interact with the local desktop. Doing so is security suicide. Thats how VirusScan was running. Therefore its a McAfee issue since there are about a bazillion better ways to write this app.

J

Re:Don't Do That

[cperciva]

use a pipe. Oh wait, thats only available in linux...

Err, pipes have been in Windows since NT 3.1, in August '93.

Ummm NO

[spacefrog]

How are you arriving at the conclusion that this dialog runs with system priviliges?

IT DOESN'T

The GUI comes from a DLL running inside the process space of MMC.EXE. It uses a fairly secure RPC/IPC mechanism to talk to Windows.

A simple trip through spy++ will even tell you the owner process in about 5 seconds.

Re:Executing untrusted code

[Enigma2175]

You forgot

3) Profit

It had to be said...

Pot, meet kettle

[sql*kitten]

You know, I remember when you could do all sorts of fun stuff with X11. For example, you could layer a transparent window on top of a display, that passed keypresses and mouse events to the window beneath it - and capture everything the user did. You see, most people used xhost for security - which meant that you gave control of your display to anyone who had access to the machine your X client application was running on.

Due to this, we now have xauth and MIT Magic Cookie. Anyone who says a security hole "can't" be fixed is naive - even if the fix is a kludge. MIT Magic Cookie is easily snoopable, so that's another security problem. The X11 protocol itself is easily intercepted, so we have to tunnel over SSH.

I could go on, but I've made my point. Linux users who take it on faith that they are secure are sadly misguided - as are those who believe that Windows is inherently less secure. Ultimately, it comes down to the skill of the sysadmin to secure any OS.