Shattering Windows 965
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."
Ummm... 'Kay (Score:4, Insightful)
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.
Security from the ground up. (Score:3, Insightful)
This is not new (Score:1, Insightful)
have some responsibility to address the problem you describe) the chief blame lies with the vendor of the software whose bad programming you are exploiting. There is no excuse to put a window for a process with the LocalSystem security context on a user's desktop. I am not aware of any Microsoft application that makes such a mistake.
Re:Take control? (Score:4, Insightful)
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
Don't Do That (Score:3, Insightful)
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.
Re:Is this really a security risk? (Score:5, Insightful)
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...
Re:Ummm... 'Kay (Score:3, Insightful)
But the window must be in the user's workspace. You can impersonate the user, or, if the software in question has bugs in it (buffer overruns, etc), you can exploit those.
If the user doesn't have any access to these programs (which they probably shouldn't in a truly secure environment) it isn't an issue. Turn off the user component.
Look at it this way... if you have a X window to a SUID program running and you run arbitrary code... you could well be screwed. This isn't any different.
Still, I'm back to my "If the user runs unknown code, they're screwed". There will always be SOME bugs in ANY operating system which can be exploited if you can get a user to run arbitrary code. Which is why encouraging good user habits are so important.
Re:Fixability (Score:4, Insightful)
Re:Devil's Advocate... (Score:2, Insightful)
Do you people read? (Score:3, Insightful)
I'm sorry, and I hate to be a stickler, but did you people even read part of the article?
The e-mail he recieved outlines where the danger lise, and also outlines the fact that this is not necessarily an MS problem but a vendor related issue. I am very pro-linux, and I will support it till I die, but this blatent MS bashing makes linux users look like morons.
Just for once I wish people would read the articles before the "M$ Sux0rs, I will 0wne any M$ Boxen" jibberish begins...
Re:Take control? (Score:1, Insightful)
Jerk. (it crashes for me too)
Re:Ummm... 'Kay (Score:3, Insightful)
Of course, the fact that apps aren't doing this goes to show that at the very least Microsoft has some education to do when it comes to developing secure 3rd party apps, but its not nearly as earth-shatteringly broken with no hope of being fixed as the paper author lets on.
It's not even this hard (Score:3, Insightful)
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.
Re:you're totally missing the point (Score:2, Insightful)
Yes, but who's fault is it? Not MS'! (Score:4, Insightful)
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:Is this really a security risk? (Score:3, Insightful)
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.
Re:Don't Do That (Score:4, Insightful)
Some Windows apps are not secure. News at /.
Re:Fixability (Score:3, Insightful)
Re:Take control? (Score:5, Insightful)
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)
Re:Security from the ground up. (Score:4, Insightful)
I liked Microsoft's response to him- his "attack" already requires that 2 of the top 10 security requirements be violated. Guess what? If somebody has physical access to your FreeBSD machine, they can root you also.
And security was most definately NOT designed into the very core of *nix operating systems. For the first 15 years of Unix, security was very much an after thought.
Re:you're totally missing the point (Score:4, Insightful)
this means that if that bad code knows about this exploit, i might as well have been running the code as root, because viola, it's now root.
another thing -- this also works on terminal services systems, so mr. joe recently-fired can fire this up and destroy the shared server.
Re:Is this really a security risk? (Score:2, Insightful)
Remove floppy drive, disable floppy drive in BIOS and then password it, or simply configure the ACL to not allow floppy or CD access for anyone who is not an administrator.
Re:Security from the ground up. (Score:5, Insightful)
The only thing that Palladium could do would be to prevent the code from running at all, which would mean Palladium preventing any and all unsigned executables to run at all. Goodbye to legacy applications. Windows Palladium, now with three applications available. I'm sure that would be immensly popular.
Re:Don't Do That (Score:4, Insightful)
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!
Re:Executing untrusted code (Score:3, Insightful)
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.)
Nice try (Score:3, Insightful)
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.
Re:Don't Do That (Score:2, Insightful)
The simple fact is that Microsoft KNOW that they cannot fix these flaws. The mechanism used is the Win32 API, which has been fairly static since Windows NT 3.5 was released in July 1993. Microsoft cannot change it. The only way they could stop these attacks is to prevent applications from running on the desktop with privileges higher than those of the user logged on. Microsoft believe that the desktop is a security boundary, and that any window on it should be classed as untrusted. This is true, but only for Windows, and because of these flaws. Either way, Microsoft break their own rules; there's numerous windows on a standard desktop that run as localsystem. Use my shatter tool to verify this - there's a whole load of unnamed windows which might be running as Localsystem, and a few invisible windows (like the DDE server) that definitely are. Security boundary my arse.
------ (emphasis mine)
When ms quits writing desktop apps that are vulnerable, I guess everyone else will follow suit?
Re:Virus in his code (Score:3, Insightful)
I'd take that to mean he's "borrowed" a portion of the W32.Beavuh exploit to show that remote shell priveliges can be granted using his window messaging exploit. Of course, since this looks like it's live, I wouldn't recommend running it on a production machine hooked up to anything...
Re:Virus in his code (Score:5, Insightful)
Hint to moderators: Try "Funny" next time.
Re:Security from the ground up. (Score:3, Insightful)
Microsofts response to him summed it up well- the services that run with higher priveledges are not supposed to interact with the desktop. If a user installes a program that ignores this advice, then they are opening themselves up to a security hole.
Re:Don't Do That (Score:5, Insightful)
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 a flaw (Score:3, Insightful)
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.
Re:Executing untrusted code (Score:3, Insightful)
Well, Java runs on Linux, and
Re:Take control? (Score:2, Insightful)
This is not a commentary on XP's stability. I wouldn't know (and I have trouble believing 26 re boots in a day... that's insane). I just find your argument a little bit disingenuous.
reply to this: (Score:3, Insightful)
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.
This is the absolute stupidest thing Ive ever hear (Score:4, Insightful)
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
This does not seem to be that much of a problem (Score:3, Insightful)
He says you can't get at the widgets on X, but on Windows you can't do so unless the program uses the Win32 child window "widgets". A LOT of programs don't do this, for instance ones written with Qt. They are the same as X appliations as far as this goes.
You don't need to the widgets, a hacker can certainly feed a string of tabs, arrows, and characters, and get all the fields filled in exactly the way they want. This will work on either Windows or X. X has a "send_event" field in the events that is set on all program-generated events (one of his proposed solutions) but it is ignored by most modern toolkits because it breaks some I18N input methods and breaks record & playback tools, though xterm does ignore keystrokes with this field.
I think there are several fixes that Windows can do:
One is to fix the thing so *ALL* events go through the message queue, so a program could ignore any events it wants to. This would also eliminate a huge number of bugs where a programmer assummes their state will not change during a system call but in fact it calls back into their event handler (ie code like "destroy(handle); handle = 0;" can fail badly if your event handler causes that handle to be used.
You can add extra "fields" without breaking the Win32 API by just adding another call that says "who made this event". However, like the X send_event, I think you will find most programs will ignore this.
Windows could remove the ability to send huge numbers of events, for instance all the ones that create or destroy windows, without breaking any programs. It could also further restrict the ability to send events between programs with different priveledge levels (something X cannot do because the server is unaware of exactly what process owns a window).
Programs with these priveledges should be rewritten to independent tasks with different priveledges. On X you do the same thing, seperating the GUI from the setuid portion, if you really want security. This is because there are likely to be many more exploitable bugs in the GUI than in the other part. I'm unsure if Windows allows you to do this easily (they don't have fork()).
Windows could eliminate the stupid things in the systems that forces people to send these events. For instance at work here we have a process running on our NT render machines that just hits the "OK" button on any dialog box that pops up, otherwise the machines wedge when a program gets an error. My recommended solutions would probably break this program, but it would be better if they fixed this stupidity so such a program is not needed.
Re:This is a flaw (Score:2, Insightful)
The simple (and obvious) way to write such software, is to write the privileged bit as a service (somewhat analogous to a daemon in Unix), and the GUI as a separate unprivileged user-land app. The service runs with whatever privileges are granted it, independent of the priviledge of the user logged in. The separate GUI application, running in the user space, communicates with the service by whatever method is convenient (defined strictly by the service). The service then checks all communications it receives for validity etc before processing any of it. This means that as long as the service checks its inputs properly, no malicious GUI app can force it to do things it shouldn't be doing.
The point is, Windows NT does not make this impossible. It does make it possible to write crap software that compromises security, but hey that's the case with any operating system. It's quite possible to write a 'su' replacement that doesn't check passwords, for example - there's a command line app idea that the OS won't protect you against, and it'd be handful of lines of C code.
It takes administrative rights to install the software; that's when it gets its privileges. In this case, it takes admin rights to install VirusScan, and that's when the security got compromised - the installation gave privileged rights to an application which opens windows on the user's desktop. I'm also not convinced that X isn't susceptible to the same issue; as far as I'm aware X uses a message queue to communicate between windows, the user etc - there's nothing in X to say you can't cause a buffer overflow in an application by sending it a malicious message, it's up to the application to check its inputs, and that includes its messages.
One thing this does show, is that closed-source software can't be trusted in the same way that open source can. It's a lot harder to perform a useful security audit on your system if you don't have the source code to the privileged applications you want to install. How would you determine that VirusScan violates the design guidelines for secure services, short of cracking it (which presumably violates the DMCA of course)?
Of interest, I wonder if the McAfee stuff has the same basic design flaw...
Why are people pretending this is not a problem? (Score:3, Insightful)
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
Re:Evolving Concepts at Microsoft are Frightening (Score:4, Insightful)
"We don't trust you."
Ummm NO (Score:4, Insightful)
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:Yes, but who's fault is it? Not MS'! (Score:2, Insightful)
Which is exactly why MS boxes get hammered over and over and over, or they act as platforms for DoS attacks over and over and over.
It's not the drunk's fault, someone keeps putting curves in the road.
Re:Security from the ground up. (Score:2, Insightful)
If an OS kernel does not have a properly defined system of rights, then it is, and will always be, fundamentally insecure. To depend on a particular key signing of an application is little more than security through obscurity.
How long do you think it will take someone to find a security hole in the key management system that allows arbitrary keys to be authorized? Or before someone steals a valid key. It only takes one such breach to completely eradicate any gains that this system adds.
Security must be built into an OS design from the beginning. The original poster was exactly correct in that statement. This is an idiotic attempt to mask a fundamental design flaw by simply hiding the flaw. It's like fixing a rusted out Pinto by giving it a new paint job. No matter how you look at it, it's still a rusted out Pinto.
Re:sprintf is the wrong analogy (Score:2, Insightful)
I'll throw my hat in too I guess... (Score:3, Insightful)
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...
Shoddy work, mistake in the whitepaper! (Score:3, Insightful)
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
Re:What a load of tripe. (Score:2, Insightful)
Actually your WndProc will never be called in response to a WM_TIMER message. WM_TIMER messages are handled by a special case inside DispatchMessage, which is where the jump to the callback occurs. If you want to intercept WM_TIMER messages, you need to intercept them prior to calling DispatchMessage.
D
Re:WARNING Virus in article download!!!!!!! (Score:1, Insightful)
which your anti-virus software probably matches to the
signature of a known virus.
Re:Ummm... 'Kay (Score:3, Insightful)
The real point is that the only apps that are insecure are the ones at the same privilege level as the user, or poorly written services that the administrator never should have installed.
This is because you can copy arbitrary data into another process but only if it's got a thread on your desktop.
Which applications would those be?
A closer look at the "Overview" section of the white paper reveals that it opens with "In this example, I will be exploiting Network Associates VirusScan v4.5.1...", so this whole article looks like the case of the unwisely configured service.
This is all very simple, and it's been this way for years: if it runs as LocalSystem, uncheck the "Allow service to interact with desktop" box. Then there's no risk. You can't copy arbitrary data into the process, and you can't send it WM_TIMER messages. If you install a service app and it turns that option on, maybe you should look for a vendor with a higher quality product. And just to be on the safe side, set NoInteractiveServices to 1 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Windows.
(By the way, you're right that the bit about WM_TIMER in the white paper isn't even correct. The app that receives it has the opportunity to drop the message without dispatching the callback function, contrary to the white paper, whose author didn't even bother to investigate that claim before blurting it out.)
D