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."
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
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.
The method in the article seems like a lot of trouble.
This software provides you a new administrator password: Locksmith.
"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."
/. in a way that they shouldn't, but at least moderations help keep the noise level down and filterable. Frankly, I think this is a much better approach than trying to 'secure' Slashdot by trying to write an 'ascii-art detection algorithm'. (That's just an example, don't beat me up over it.)
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.
"Derp de derp."
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?
sprintf() can't be removed without breaking literally thousands of stupidly-written apps which depend upon it.
Isn't this precisely the set of programs that need to be broken, so they don't allow root?
Log onto your w2k box as "guest". Open the "computer management" window. Go down to users and attempt to add a new one. The dialog opens up. Yes, even guests can at least open the dialog. This dialog runs as system. I can use this exploit now. Thank you.
Actually, probably not - I researched this when writing Shatter. When you hit CTRL+ALT+DEL you actually switch desktops from the "Default" desktop to the "Winlogon" desktop. A program on one cannot interact with a program on another. There are functions to "open" a desktop and interact with it - however the Winlogon desktop is tightly restricted, and any attempts to open it are met with an Access Denied error.
Either way, there's numerous windows (normally hidden) on a standard desktop that run as localsystem - it's possible to exploit some of them using the same techniques.
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!
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 );
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
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
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.
Not just "pot, meet kettle".
The warning comes from a 23 year old "genius" who describes himself as knowing a couple hundred languages on x different platforms and capable of learning any new language in 3 days, but who doesn't know that this "issue" has been known for years, and isn't a security flaw in windows, but in the application software (in this case, viruscan).
The same flaw (letting a process that runs at system level interact directly with the desktop, against warnings in MS docs never to do that), also exists in HP printer drivers (to name just an example), and is a thousand times more easily exploitable there -- all you need is physical access to the machine.
I'm including a description below. This made me raging mad at HP a few years ago and is the reason why I'm forbidding the use of HP printers anywhere in the company.
After being sent from phone to phone when I reported it, when I finally reached someone who understood what I was talking about after having talked to support people in 3 different countries, it appeared that (a) HP was aware of the issue and (b) they found fixing it to be too much of a hassle, since there was an easy workaround: disable bidirectional support on the parallel port, so the driver can't detect printer errors.
That guy actually made it sound as if I was stupid for not having thought of that "fix" myself.
I ran into the problem on a system where my own app was running as shell, but below is an easier way to reproduce it.
It worked (works?) under NT4, but I wouldn't be surprised at all if it's still the same in XP:
- You need a PC with a HP printer attached, with the drivers installed from HP's CD (not the drivers that came from MS on the windows CD, those are safe). It was confirmed to work with deskjets in the 600 and 800 series.
- Open notepad. Type in some random characters.
- Click Start/Shutdown, and hold down ctrl+shift+alt while clicking "Cancel": this closes the shell, while notepad keeps running (a less known, yet documented trick to close explorer.exe as the shell while remaining logged on).
- Remove all paper from the printer, then print the document from notepad.
- A tabbed dialog will pop up with a message about the printer being out of paper, and diagnostic and help tabs. That dialog also gives access to the help file that came with the driver, from there you can go to the printing problem solver, and there you can open the printers control panel.
- Do that. The printers control panel will be opened in explorer, but because explorer.exe is also the shell and no other instance is running, it will start as the shell instead and your desktop and taskbar will reappear.
Congratulations. You are now logged in with system privileges, because the HP driver displays the error message under the system account, the help file inherits the privilege, and so does explorer in its turn.