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."
Someone discovered Windows is insecure. (Score:5, Funny)
Pot, meet kettle (Score:4, Informative)
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.
Isn't this in the EULA anyway? (Score:5, Funny)
no, no..... (Score:5, Funny)
How do you rescind acceptance of the EULA? (Score:4, Interesting)
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? (Score:3, Funny)
Here is where many people get confused by legal definitions and concepts of property, contracts, and so forth. Allow me to attempt to clear this up: Microsoft does not "own" your box. In legal parlance, Microsoft "0wnz j00!!!!!"
Re:How do you rescind acceptance of the EULA? (Score:4, Interesting)
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.
Like GTK (Score:3, Interesting)
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.
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.
Re:Ummm... 'Kay (Score:5, Informative)
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 (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:Ummm... 'Kay (Score:5, Informative)
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: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.)
Re:Executing untrusted code (Score:3, Insightful)
Well, Java runs on Linux, and
Re:Executing untrusted code (Score:4, Funny)
3) Profit
It had to be said...
Re:Ummm... 'Kay (Score:4, Informative)
Here's the WM_COPYDATA documentation. Read it and tremble in fear. [microsoft.com]
Re:Ummm... 'Kay (Score:4, Informative)
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 (Score:3, Informative)
Maybe so, but there's more Windows messaging system does (by allowing nifty shortcuts) than what typical suid app would. Read the article for god's sake.
Basically, it has similarities with Outlooks "execute anything on sight when user does something". Messaging system allows code to be executed without app having any way to intercept those calls. And those calls come from lower privileged level.
In this particular case it seems perfectly reasonable for the privileged app to expect that GUI components in question just do their UI stuff, instead of providing an instant code execution path. It is once again that Windows really makes thing easier... similar vulnerabilities potentially affect all/most message based GUIs / OSes, but not as easily as with Windows.
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.
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:Yes, but who's fault is it? Not MS'! (Score:4, Interesting)
Re:Yes, but who's fault is it? Not MS'! (Score:3, Informative)
I verified this using Spy++ (from Visual C++) and Proccess Explorer (www.sysinternals.com).
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:4, Informative)
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.
EASY! (Score:4, Funny)
ME) Hello, Mr. Hockenblock?
MR HB) yes?
ME) Our network associates have found a bug in the network system.
MR HB) Oh, really?
ME) Yes, it seems there is a particularly nasty roving virus that when it hits your system through an open port, can cause your computer to get stuck in an n-th complexity infinite binary loop*
*- note blatantly stolen bogus virus description! (see: good times virus warning)
MR HB) Dear lord, no!
ME) any ways, there is a way to fix it.
MR HB) How?!
ME) just got to http://www.eye.0wn.j00.com and download and run the files there.
MR HB) thanks!
ME) please tell all your friends.
MR HB) I will!
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: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.
"Run As" is your friend. (Score:3, Informative)
It works with poorly coded proggies like Palm Desktop. Palm Desktop wants you to be the Admin when it runs. Nine times out of ten "run as" works in cases like these. However, with Nero Burning Rom, it won't work. You have to log in as Admin for that puppy to run right. SuxRoxio also requires this. NTI Professional CD Maker's new version totally eliminates the need to be Admin to burn CDs, which is very cool.
I never run as Admin if I don't have to.
Security from the ground up. (Score:3, Insightful)
Re:Security from the ground up. (Score:3, Interesting)
"In order to avoid this problem, we are restricting running code to ONLY applications that are signed by Microsoft, or signed by a Microsoft-granted key."
How many open-source projects will run out and get one of these keys?
Re:Security from the ground up. (Score:4, Interesting)
I'm sure that good open source developers are responsible enough to apply for a key. The real question is, will an non profit open source project be allowed to get a key, or will Redmond only talk to companies that can wave some cold hard cash in their direction? $50,000 for a application key sounds like a profitable business plan to me.
Re:Security from the ground up. (Score:3, Informative)
I can't imagine enybody suggesting that only Microsoft signed Excel scripts will be allowed to run, for example.
Re:Security from the ground up. (Score:5, Informative)
Or perhaps we can come to understand that some APIs have limits and not use them in sensitive situations. If you read the MS reply, he's saying that they recommend that a system service should not interact with the desktop, and recommends they take this up with Mcafee since they wrote Viruscan. The SecurityFocus article [securityfocus.com] that MS referenced shows that when this type of exploit was found in a MS service, they fixed it.
Re:Security from the ground up. (Score:5, Informative)
The paper indicates that there are a lot of 'windowless' services running as localSystem that the program is able to exploit, and these services are Microsoft-created.
VirusScan was used in this example because it's easy.
sprintf() _is_ safe. (Score:4, Interesting)
You're wrong here. You absolutely can limit field sizes with sprintf().
char buf [8];
sprintf (buf, "%-.3sTEXT", "1234567890");
will write "123TEXT\0" into buf and nothing more. In this case it is always safe to have the buffer be 3+4+1 == 8 bytes in size. It's the responsibility of the programmer to use this. It's not just a feature, it's a MUST if you process input of unknown length.
You can't blame the library if programmers act stupid and produce unsafe code. And this is different from the Windows misconception in the article, since you'd need to patch the format string here first to be able to exploit this in any way. On the other hand, if you already have right to change code of an SUID binary, you don't need an exploit anymore. :-)
And, btw, nobody needs gets() anyway. There's fgets() which even has the advantage that you can redirect the input stream your subroutine (you're using subroutines, aren't you?) is going to read from.
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:Security from the ground up. (Score:5, Interesting)
They are not security measures. They are control measures that can provide security only as a by-product and only to the extent that security can be provided by mandating a single source policy.
Palladium is designed to guard against this exact kind of attack.
No. Palladium is designed to take away general purpose computing from the public.
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.
Physical access is not the point; the point is that in Windows, any program can elevate its privileges if any higher-privileged program is has any windows on the desktop, visible or not.
A program that is ran as a non-privileged user on my FreeBSD machine is certainly not supposed to be able to raise its privileges, under any circumstances. If it can, it's considered a bug, and rightly so.
In Windows, the distinction between physical access and untrusted programs does not exist and the boundary between programs is not sufficient to enforce different privilege levels if they both use the desktop.
It now also becomes perfectly understandable why they want to treat the person with local access, even if that's the owner, with the same level of trust as any program running on it: none whatsoever. Simply because Windows can't make the distinction, by design. Sadly, it also means that the owner of the computer is not anymore in control either.
It just proves the point that all versions of Windows are essentially still single-user operating systems.
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: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:Security from the ground up. (Score:3, Interesting)
You mean like checking the 'Supported Hardware' list before installing a Linux distro?
I think its pretty much accepted that the Unix community ingored security until the Morris worm in 1988- it was not designed with security at its core. Most people would also consider most *nix variants today fairly secure.
Fixability (Score:4, Interesting)
Re:Fixability (Score:4, Insightful)
Re:Fixability (Score:3, Insightful)
Re:Fixability (Score:3, Interesting)
Correct me if I'm wrong but I'm pretty sure that PostMessage puts a message on the queue whereas SendMessage skips the queue and gets handled straight by the application without examination. Of course, an application could handle every message but in practice 99% of applications will leave the default windows handling of most messages. (Handling all manually is not feasible).
cap the WPARAM at some small value
I think you misunderstand that. WPARAM is a fixed size double word (4 bytes). The problems is that it is often used as a pointer to a memory location. Obviously, you can't cap the target of a pointer since no information is possed in the length
Most applications won't use the callback feature of WM_TIMER anyway
AFAIK, if you don't handle the callback feature (99% of apps), you get the default handling which is to execute the code as the article describes
Re:Fixability (Score:3, Informative)
No. Both place messages in the queue, the difference is that PostMessage does not give you the return value of the message (and hence does not block).
I think you misunderstand that. WPARAM is a fixed size double word (4 bytes)
Exactly, but for the message EN_SETLIMIT, this is not a pointer.
AFAIK, if you don't handle the callback feature (99% of apps), you get the default handling which is to execute the code as the article describes
Which is why we would block timer messages with a callback parameter
Re:Fixability (Score:3, Informative)
The callback function has the following prototype:
LRESULT CALLBACK CallWndProc(int nCode, WPARAM wParam, LPARAM lParam);
nCode specifies handling semantics.
wParam specifies whether the message was sent by the current thread.
lParam is a pointer to a CWPSTRUCT structure.
The CWPSTRUCT contains the following:
typedef struct
{
LPARAM lParam;
WPARAM wParam;
UINT message;
HWND hwnd;
} CWPSTRUCT, *PCWPSTRUCT;
There is nothing of use here that would permit a filter to determine the origin of a message. At most it could kill all inter-thread messaging, seriously breaking multi-threaded applications.
-Hope
Won't work because of multi threaded/process apps (Score:4, Informative)
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.
Re:Fixability (Score:5, Funny)
Read the BugTraq replies first (Score:4, Informative)
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:Don't Do That (Score:4, Insightful)
Some Windows apps are not secure. News at /.
Re:Don't Do That (Score:4, Funny)
Windows is insecure. Linux is insecure. PROGRAMS are insecure.
Re:Don't Do That (Score:5, Informative)
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: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: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?
Re:Don't Do That (Score:3, Interesting)
Sure about that? What if it runs on a system where an int is 128 bits? If your answer is "that will never happen", consider that that same logic led to billions of dollars spent fixing Y2K bugs.
yet you want to have me replace it with an ugly mess of seperate calls
snprintf(strVal, 120, "val is: %d (decimal), %x (hex), %o (octal)", val1, val1, val1 );
Re:Don't Do That (Score:4, Interesting)
Isn't this precisely the set of programs that need to be broken, so they don't allow root?
sprintf (Score:3, Informative)
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.
Re:sprintf (Score:3, Informative)
As the original poster said, snprintf is good, sprintf bad.
Re:Don't Do That (Score:3, Informative)
You mean, like antivirus software?
Almost all programs on Windows have an integrated MVC design - I can't think of one that uses your (better) separated M/VC design. This is a flaw in more than "some" applications.
Re:Don't Do That (Score:3, Funny)
patient: Doctor, it hurts when I do this.
doctor: Well then, don't do that!
Re:Don't Do That (Score:5, Interesting)
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 (Score:4, Informative)
Err, pipes have been in Windows since NT 3.1, in August '93.
Evolving Concepts at Microsoft are Frightening (Score:5, Funny)
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 (Score:4, Insightful)
"We don't trust you."
There is advantages... (Score:3, Interesting)
You can make a program that can take any window on your screen, study it, and use it. Imagine the testing possibilites. I think WinRunner and Rational Robot both use message hooks in order to run their regression testing utilities.
Is there anything like that in linux? AskSlashdot [slashdot.org] encountered someone trying to find this...
the basic problem (Score:3, Interesting)
Q: I understand security was not your original calling, so to speak.
A: I'm a lawyer by training, so I'm a little bit like a fish out of water, although I'm more technical than most lawyers. I started my career as a prosecutor in Bronx County, New York. Then I joined the feds and went to Honolulu for three years. So, I haven't exactly had the normal career path. But it's been a very interesting ride.
So what exactly qualifies this guy to be a security guru, let alone THE HEAD of security at the software company that sells the most widely used OS on the planet?
If you ask me, I find that frightening.
I've said it here before a zillion times over the years and I'll say it again. Nearly every problem in the software industry today can be traced back to handing over an engineer's job to a non-engineer.
True- if you take a company of nothing but engineers, you'll have a product nobody understands how to use, and nobody can sell. But if you have a company of nothing but MBA's and Lawyers, you have a company that sells nothing but a lot of vapor and hype. This is the personification of Microsoft.
window messages a privilege boundary? (Score:5, Informative)
An application that needs to provide a window interface to the user should do so through another process running as the user and not system. That process should then communicate to the higher privileged process using a mechanism such as COM or named pipes.
A similar problem was found by Dildog quite a while ago, "NetDDE Message Vulnerability":a dvisories/2001/a0 20501-1.txt
http://www.atstake.com/research/
The method of exploit described in Shatter is new: putting shellcode into memory through edit controls and then using timer messages. But the fundemental problem is not a new class of problem. It is with the application's design not windows.
-weld
Face it, it's a flaw in Windows. (Score:3)
Fundamentally, I'd like to agree with you that Windows is not to blame, but its API fosters apps which are written in the Windows tradition--that is, where the GUI and app are one. Windows also fosters the belief that only a user with administrator access can do useful work (ie. installing programs), so almost all home users log in as the administrator, or turn automatic logging in on, entirely bypassing security.
Clearly, the exploit only affects companies with higher security aspirations, and shows their efforts are in vain. Corporations with tighter security needs will have to reconsider who gets access to their machines now, though, because their software investments are substantial and non-refundable.
Now that would be something: a class action lawsuit by large companies using Windows, holding Microsoft liable for damages as a result of their products failing to provide data security while claiming that as a feature, and willfully refusing to repair the problem.
Re:window messages a privilege boundary? (Score:3, Informative)
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...
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:It's not even this hard (Score:3, Interesting)
Oh I agree. I don't think fixing this would provide much 'security' anyway. The main reason that Windows gets beat up by trojans is not so much flaws in the system, but clever ways of executing features in malicious ways. The problem is never ending. The more features you add to any product (not just computers), the more ways you have of exploiting them in a negative way.
Look at Slashdot. Lots of steps (such as filtering the HTML...) are taken to keep trolling to a minimum. But, they still get through. As a matter of fact, somebody recently posted the Goatse pic in ascii. Heh.
The best approach you can take towards 'security' is to make the worst case scenario cause minimal damage. That's essentially what Slashdot has done with the karma system. People are always going to come up with amusing ways to use
In an ideal world posting a rule saying 'Dont post notti pictures' would be the end of it. In the real world, people think the problem should be solved by making the system incapable of displaying notti pictures. The best thing to do is to make the display of 'notti' pictures as unthreatening as possible.
High opinion (Score:4, Funny)
Re:High opinion (Score:4, Funny)
Re:High opinion (Score:4, Funny)
Window "shattering" utilities (Score:3, Informative)
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++ [microsoft.com], 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
The problem is developers not used to multi-user (Score:3, Informative)
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...
Virus in his code (Score:3, Informative)
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.
Windows Exploit - most dangerous! (Score:5, Funny)
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. (Score:4, Interesting)
The method in the article seems like a lot of trouble.
This software provides you a new administrator password: Locksmith. [winternals.com]
What a load of tripe. (Score:5, Informative)
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 [tombom.co.uk], 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. (Score:4, Informative)
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. (Score:3, Informative)
By the same token, is it a UNIX or Linux vulnerability if I run an insecure daemon suid root and someone buffer overflows it to get root privs?
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.
I'd disagree with you there. Viruscan's assuming that nobody will fuck with its code (the worst mistake you can make when dealing with crackers) and that it'll never get more than 4 characters. Maybe it's just me, but I automatically check length whenever I do ANYTHING with a buffer, and usually I make a quick call to IsBadWritePtr(buf, len) or IsBadCodePtr(callbk) while I'm at it.
Yes, technically you can't prevent him from changing the text box's maxlength, short of subclassing the text box with a custom WndProc after initializing that discards said messages. But that doesn't mean you can't write your code in a robust manner.
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.
I grant you that - MSFT fucked up by writing DefWindowProc() to blindly execute a callback. However, while tricky, I don't think it's fair to say that it's an unfixable problem, or that this is any different from some of the assumptions made in glibc's functions.
Fortunately, the community tends to be able to fix these things by patching the source. There is no fix for this problem.
Yep.
No no no... you've cheated. As a system service, you already have priveleges
I was being sarcastic by that point. ^_^
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.
Re:What a load of tripe. (Score:4, Informative)
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.
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.
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.
Don't worry too much (Score:3)
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.
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
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: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
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:Take control? (Score:3, Interesting)
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
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: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:Is this really a security risk? (Score:3, Interesting)
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.
not just physical access (Score:4, Informative)
the terminal server may be behind 8 inches of steel and plexi-glass. but this compromise shatters that, too.