Slashdot Mirror
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."
Film at 11
Je t'aime Stéphanie
"Essentially, they allow you to take control of any window on your desktop".. sounds like it's straight out of Microsoft's new EULAs.
Never email donotemail@WeAreSpammers.com
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.
-- IANAEG - I am not an elder god.
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
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
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.
This "vulnerability" only effects poorly-written applications, running with system priviledges, which create windows in user-space.
You're not supposed to do that.
If you want to have a service which is user-configurable, create two separate programs (one service & one gui) and communicate via a named pipe.
This isn't a flaw in the win32 API. This is a flaw in some applications which run under windows.
Tarsnap: Online backups for the truly paranoid
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."
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...
If you have physical access to the box, there are n ways to get your code executed in a Windows app. WM_TIMER (the callback version) is one, as are window hooking, CBT hooks (computer-based-training, although I've never seen it used for this purpose) forcible DLL loading (if you have access to the Registry), debug process attachment, CreateRemoteThread, thunking well-known DLLs (which is why Red Alert 1 won't play on Win2K without a patch--they can't thunk kernel32), etc., etc., etc.
Windows programmers have been using these methods for non-evil reasons for many years--the "3D look" of MS Office apps before Windows 95 was done this way.
The insecurity of the desktop model for Windows shouldn't surprise anyone. It wasn't designed to be secure OR multi-user, and patching after the fact doesn't make it so. It's comparable to complaining that telnet and ftp send passwords in clear text. Well, no kidding, they weren't designed to be secure, so they're not.
And like the case of telnet, making a secure but still 100% backwards compatible solution is pretty much impossible, as the article states.
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.
Never underestimate the relief of true separation of Religion and State.
I've got news for you: local priviledge escalation exploits are still exploits.
Sure, it isn't as serious as a remote exploit. However, if you take the stance that once a user logs on to your system then you are 0wned, you don't have a real multi-user O/S. What is the point of having multiple user accounts with priviledge separation if you don't fix local exploits? Would you give every user on a system you admin root (Adminstrator) privs?
The fact that Microsoft is dismissing a local priviledge escalation as "not a problem" just tells me they still don't understand how to make a real multi-user enterprise O/S.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
Their EULA reads "Essentially, you will allow us to take control of any window on your desktop." Glad I could clear that up.
I can't share my work because of bandwidth problems, but it was indeed groundbreaking. Through raw HWND handles or Microsoft's (or my own version) of the WinFinder control found in Spy++, one is able to select any existing window in the system. Arbitrary messages can be sent or posted. One can draw pixels over windows, enable disabled controls (as often found in shareware), send text to edit controls (I developed a simple scripting language to automate this process), right/left/middle/double click at any position (useful in closing annoying dialogs, like the dialup reconnection message for those on 56k), and even move or kill any window one choses.
As for the vulnerability itself...its well worth the read. Basically, shellcode is injected into an edit box by removing the CEdit's length restrictions. This is a valuable lesson to all Windows programmers out there -- do not rely on a control's restrictions to validate data! Its as dangerous as using JavaScript to validate web forms. Always in all cases check for buffer limits in the application code.
Of course, not all flaws can be blamed on the application developer:
I've only skimmed the article, but this is the first documented exploit I've heard of in my half a decade of Windows programming. But its worth mentioning that these fundamental flaws have existed since Windows 95, and Foon is correct in that there's absolutely nothing Microsoft can do about it, except ditch the current Win32 API and start anew. Guess we'll have to wait until Longhorn. -sr
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)
MORTAR COMBAT!
For example, the virus scan writer probably tests, develops and uses windows while logged into the "administrator" account interactively, as do most users. In Win98, it's not even a question -- you're always the "root" of the box. I'd wager that "What access could a non-administrator user obtain through our GUI/message interface?" hardly occurred to the GUI programmers for this particular virus scan software, even though their interface ran at LocalSystem (geeez).
As mentioned elsewhere, there are ways to avoid these problems: If you really need to use gui elements as administrator, run them under a separate desktop or windowstation where the interactive user can't touch it. Run the GUI interface impersonated down to a lower level, such as that of the interactive user. If you have to be administrator or local system, treat all input as untrusted, including (especially) window messages! Don't use edit box constraints as buffer limits. Don't use the default window procedure. etc etc etc.
It's true, however, that the default behavior for WM_TIMER is a pretty big security flaw (IMHO). But contrary to what this writer inaccurately claimed, you can still intercept the WM_TIMER message and handle it yourself, and any security-conscious program should never pass unexamined WM_TIMER functions to the default window procedure. This makes me start to wonder about other flaws in the default window procedures... as Microsoft wants you to think that the defaults it gives you are safe and secure. hmmmm...
The following sentence is true. The preceding sentence was false.
In the shatter exploit he's linking on his website, there is a virus in the sploit.bin file. It's a W32.Beavuh, and Norton Corporate flagged it immediately. So, surfer beware! It's hard to take security fame-seekers seriously when their code is trojaned.
Actually the attack seems to involve getting a handle to a window running in a process with higher privledges, which is trivial in windows. There is a nice function call WindowFromPoint that given a point on the screen, it returns the window handle under that point. After I have the window handle, a simple call to GetWindowThreadProcessId will give me the thread and process id that's in that window handle. After getting the process id, it's not that much more difficult to see what the userid/security class of the application is.
My point is that there doesn't have to be any user interaction at all, and that the program can determine which windows have a higher priority and escalate their privledges via this exploit. Also, it's not all that difficult anyways to just iterate through all the toplevel windows in the system (via the EnumWindows function) and check them that way instead of using WindowFromPoint.
Things you think are in the Constitution, but are not.
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!"
The method in the article seems like a lot of trouble.
This software provides you a new administrator password: Locksmith.
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.
Do not spread "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" over the internet, thank you.
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.
MORTAR COMBAT!
Why this is only a Unix problem I don't understand, as sprintf is defined in ANSI C, so I would think it'd be a problem on any system with a C compiler.
Hopefully someone more knowledgeable will explain.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
then Dotnet will be in place and the party will be well and truly over.
yes and no. MS will (probably) eventually bring down the number of security bugs (though with their insistence on features,features,features and their gratuitous changes to APIs and protocols used to foil competition, it will never be 0 or even real low), but the real problem with Microsoft is not the stuff they do accidentally, it's the stuff they do with full knowledge and intention.
For example, if your files are in some proprietary format and you lose the right to run the software that reads that format, who owns your data? Before you scoff, remember that MS was one of the drafters and promotors of UCITA, which would/will permit software manufacturers to turn off software that they believe is not licensed correctly. (aka "electronic self help" - there are numerous ways to accomplish this even if you're behind a firewall.)
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
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.
His "technique" is kidde fare, nothing any experienced Windows developer doesn't know. His whole premise is based on the idea that "running as SYSTEM" is bad - SYSTEM is designed to be used to run non-interactive services such as SMTP or MSMQ. Installing a service requires administrative rights, as does telling the SCM (Service Control Manager) to allow a given service to interact with the desktop. Microsoft's response is the one I expected to see given how long this "vulnerability" has been known. If you must run a service that interacts with the desktop, run it under a local account which can be locked down and prevented from doing specific things. If anything, this is more the AV vendor's stupid mistake than anything else.
There are tons of actual, real vulnerabilities and problems in Windows (outside of IIS), and most of them reside in the shell code. But those are significantly more difficult to get at than this.
So Mr. "Foon" has proved himself a real bofoon, showed us he sorta kinda understands the process messaging architecture and he knows how to use a debugger and, h^xx0r him, netcat. Woopdedoo!
Not to criticize the editor's "integrity" of course. Who would even consider posting this article for half a million people to see before checking the facts.
Hey, I know! I'll get a website, a kewl IRC handle like "boon", post some techie-sounding text related to some vague problem with Windows and then call it a paper.
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?
At lot of people are saying that this is an application level problem and not a flaw in Windows. That is wrong.
The core result of the attack is that it is impossible for a high privilege program to display a GUI interface to a low privilege user. That is a silly limitation, certainly one that that other GUI systems like X Windows do not share. Sure, you can work around the weakness by having a low privilege GUI talk to a high privilege service over a local socket, but it shouldn't be necessary. This gross "fix" will complicate the situation, potentially opening additional security holes.
Microsoft tried to deflect the issue by hiding behind, "If the user is local to the machine, or can run his own binaries, he owns your machine." It sounds nice in theory, but falls apart when the "user" in question is actually an opportunistic virus looking to add the machine to a distributed denial of service cluster. Many corporate environments lock down the machines not for fear of user attack, but to limit the damage of viruses and other malware. If the malware can exploit this technique to gain elevated privileges, your security steps are worthless.
Ultimately, with a bit of care, a high privilege program should be able to safely interact with a user through any means, be it command line, GUI, network, or otherwise. If the operating system makes this impossible, the operation system has a flaw.
Dotnet (and Java) represent a quantum leap in the "securability" of a platform and one to which Linux has no answer
.Net is being implemented on Linux, so we can use the same answers. Also, User Mode Linux lets you run a full environment in a sandbox, with no modification to existing programs. That's better than anything Java or .Net offers.
Well, Java runs on Linux, and
Every blue screen on win2k pro I've ever had was a direct result of an ISAPI filter apparently crashing the kernel.
:)
your first mistake was using a kernel-privileged web server (IIS).
I was developing the filter, and in its early stages, it had memory leaks, dangling pointers, double free()s, etc.
your second mistake was writing bad code.
but i'll agree that writing bad code shouldn't crash the OS. but when you're developing on windows, that's the modus operandi (sp?). but who am i to kvetch? i learned my C code on UNIX, where i got segmentation faults, bus errors, all kinds of evil crap, and the program terminated, and the OS chugged along.
but try playing a bit with framebuffer programming on linux, and see how fast you bring down the OS
MORTAR COMBAT!
If you have the patience to read through his smarmy instructions on how to reproduce the defect, you'll discover that he has indeed hit upon a rather serious security flaw. He then proceeds to give three strawmen--er, I mean possible solutions to the problem--and argues that since these three things can't fix it, nothing can. Well, I'm not convinced.
What if Windows' messaging were changed so that certain messages that are considered insecure (like WM_TIMER) can only be sent to windows owned by the sending process? What if the text inside an edit control were held in some piece of memory with no execute priviledges? These are two things that, I think, could solve this problem immediately, with little inconvenience to users.
Also, check out this guy's pompous letter to Microsoft, in which he states, "Since Microsoft already know about this issue, and any of your programmers will be able to replicate and verify the issue in less than an hour given the information in my advisory, I'm not prepared to wait very long." Clearly this, er, fellow has no experience in large software companies. Even good software has perhaps hundreds of defects outstanding at any given moment, at various levels of urgency, competing for developers' attention. Apparently he either thinks he's so important that he can jump the queue, or else he imagines that these armies of developers are sitting idly at their desks waiting for people like him to give them something to do.
Well, that's enough ranting. The upshot of it is, I wouldn't be too woried. He has not done a Jenga on Windows.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
The author has addressed Microsoft's response in his writeup. Given that there are numerous windows running as LocalSystem on any desktop, Microsoft's response is a load of tripe.
___
If you think big enough, you'll never have to do it.
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
I love idealists not because I am one, but because they make life bearable for pragmatists such as myself.
Why are people pretending that this is not a problem with the design of Windows?
It seems perfectly obvious to me that all you would have to do to fix this would be to associate applications credentials with messages as they are passed around, and not permit messages from a process with a lower priviledge to be sent to a process with a higher priviledge, unless a security association is established.
This would mean changing the messaging API, but it's fixable. It would merely mean recompiling all third party code that needed t communicate across priviledge boundaries, and adding code to programs designed to operate at higher priviledges to accept the new message type, rather than dropping it on the floor (making that the default), and make a decision based on that.
This is the standard "capabilities" security model, and is the same model that used for NT file permissions, in terms of a hierarchical inherited rights arrangement.
There would be a significant impact on "remote control", some install tools, and other packages that are not written with the idea of priviledge domain seperation, but it's *possible* to fix.
-- Terry
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.
GTK+ has the same issue. It was a *huge* deal when people started fighting about this, and eventually the decision was to just not let GTK apps run suid root.
Given the huge outcry about GTK+, I'm impressed that MS has had the same flaw, but for so much longer, with no one talking about it.
May we never see th
You forgot
3) Profit
It had to be said...
Enigma
Windows NT/2000/XP all have problems with applications running at 'System' or another level below 'Administrator' ( root ).
For example:
1. Setup a win2k box with a user, and make it so that this user can only run the app MS Word using your little GUI profile editor.
No write access to drives, no shell, etc.
2. Log in as that user.
3. Now run MS Word and...
Press Alt+F11
Press F5
Enter "wolf" as the procedure name
Enter "Shell "cmd.exe", vb.normalfocusfoo"
Press F5
Now using commands like 'control userpasswords' you can fuck up your nice little system.
Also using command.com ( 'NT DOS' ) with your macros you can get beyond kernel rescrictions, which is like the ntsd kernel debugger bug a while back that the patch didn't fix.
Basicly you can still 'own' a network with your garden varity macro virus still.
Hell, I consider it a feature -- you forget your admin password or want to install something by sending a 'macro agent' around the network.
Also don't forget XML+IE+Outlook, DDE, and OLE holes. Btw I never report these exploits I find... I guess BugTraq hates me.
--
Yes, this is why you have to reimage windows so often besides dll hell...
C'mon, people! This is nothing new. We all should know by now that writing priviledged applications is way different from writing normal user-mode apps. In this case, we have an example of how a poorly written priviledged app that interfaces with a local user might give the local user a chance to escalate priviledges. How is this different from the fact that a poorly written SUID app gives the user a chance to escalate?
Knowing what this guy brought up in his paper, it seems a lot more obvious why you are NOT SUPPOSED TO INTERACT WITH THE DESKTOP AS "SYSTEM" if you are running as a service. This has been common knowledge among Win32 programmers for a LONG time.
The UNIX model has some exploits to which Windows is immune, due to structural/design differences. And the reverse is just as true. If you don't understand the security practices required on your platform of choice, you shouldn't be programming apps on systems that need to be secure.
Time flies like an arrow. Fruit flies like a banana.
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.
This white paper makes several allegations, not the least among which is that there is no way for a user-mode app to mitigate the security risk it presents. This is untrue, however, and appears to be the result of a failure to investigate properly on the part of the author! User mode applications can be rewritten to guard themselves against malicious Win32 message-based attacks. That's because every user-mode app has full say in how every message is handled, contrary to the white paper.
From the paper: "As far as I know, the message [WM_TIMER] doesn't even go into the message queue, so the application doesn't even have a chance to ignore it."
The previous post follows the theme with: "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."
Dave at Microsoft did a thorough investigation with the developers who were familiar with the relevant code and replied to the author before he released his white paper (8/5/2002): "It is the implementer of a program that decides what messages to handle and how to handle them."
The author could possibly have arrived at his erroneous conclusion by writing a test app and monitoring calls to a message handling routine when certain types of messages were sent to the app. Observing that a WM_TIMER message sent to the app was processed without the application-supplied message handler being invoked, one might conclude that it is therefore impossible for an application to guard against WM_TIMER-triggered attacks. This test is flawed.
The standard message dispatching pattern you'll find in common Win32 programming books (e.g. "Teach Yourself Windows 95 Programming in 21 Days" by Charles Calvert) and even in sample code from Microsoft goes like so:
No message is processed until the application calls DispatchMessage. DispatchMessage contains special-case logic which handles WM_TIMER and WM_SYSTIMER events *without* invoking the application-supplied message handler, which is why tests similar to the case I mentioned above don't show a call to the message handler for WM_TIMER messages. However, the message will only be processed if the app calls DispatchMessage.
Applications can guard themselves by inserting a (possibly non-trivial) step 2.5 into the pattern above: security filtering of messages prior to dispatch.
So, the basic Win32 thread messaging API calling patterns are flawed when used in situations where applications with different privilege levels coexist on the same desktop. Dave already pointed this out in his email response to the white paper author on 8/5/2002. Message filtering needs to be added to those specific applications in those cases if there is to be any measure of security.
Also, the most privileged service applications (those that run as LocalSystem) can't create windows on the interactive desktop by default, which means that they aren't vulnerable unless someone checks a box that says that they should be! That feature must specifically be enabled (see the "Allow service to interact with desktop" checkbox in the Services UI). Services that run in security contexts other than LocalSystem don't even support the "interact with desktop" functionality.
The conclusion of the whitepaper -- that there is no way to write a service to be secure -- was not proven. The author should have done a better job of investigating his claims before publishing this paper.
This really boils down to a case of poorly written services exposing more "services" to users than they intended to. Several good posts on this /. topic echo that too. At least we've raised awareness.
D