Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security

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."
This discussion has been archived. No new comments can be posted.

Shattering Windows

Comments Filter:
  • Fixability (Score:4, Interesting)

    by Wrexen ( 151642 ) on Tuesday August 06, 2002 @04:03PM (#4020580) Homepage
    What's to prevent an administrator from installing a Message Hook [microsoft.com] 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
  • Devil's Advocate... (Score:2, Interesting)

    by d_force ( 249909 ) on Tuesday August 06, 2002 @04:04PM (#4020590)
    It seems this exploit allows local users to escalate their privelages through processes running as LocalSystem. So, I could either do this or open up the system, take out the hard drive, re-write the OS, and put the drive back in the system. Yes, these problems do exist when you're forced to trust local users.

    Simple fix: require each user to wear a straightjacket with their legs and arms bound to the chair; have them type via the mouth-to-pencil-to-keyboard method.

  • by FortKnox ( 169099 ) on Tuesday August 06, 2002 @04:11PM (#4020657) Homepage Journal
    Having a message-hook has a great advantage side effect.
    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)

    by jafac ( 1449 ) on Tuesday August 06, 2002 @04:12PM (#4020661) Homepage
    Okay, here's the problem, spotted it in like the first response of the CNET article:

    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.
  • by bokmann ( 323771 ) on Tuesday August 06, 2002 @04:14PM (#4020694) Homepage
    The scary thing is the way they will fix it...

    "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:Take control? (Score:2, Interesting)

    by Steve Franklin ( 142698 ) on Tuesday August 06, 2002 @04:19PM (#4020748) Homepage Journal
    Depends on what you mean by "bad hardware." If you mean hardware that XP hasn't been well designed for, you may be right. I have had similar problems, specifically, an external serial modem that XP loses track of when I reboot, and a SCSI card it intermittently loses the driver for. I haven't had the kind of constant crashing I had with 98SE--but considering how long this series of OSes has been around, that's not saying very much--and I do have to reboot every now and then because it loses track of the location of the IP address server. Don't even get me started on why they rewrote the USB part of the OS so every USB equipment manufacturer had to extensively rewrite their drivers.

    Get back under your bridge.
  • by JordoCrouse ( 178999 ) on Tuesday August 06, 2002 @04:24PM (#4020809) Homepage Journal
    How many open-source projects will run out and get one of these keys?

    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.

  • by Mr. Sketch ( 111112 ) <<moc.liamg> <ta> <hcteks.retsim>> on Tuesday August 06, 2002 @04:35PM (#4020902)
    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.
  • Re:Don't Do That (Score:2, Interesting)

    by Wakkow ( 52585 ) on Tuesday August 06, 2002 @04:37PM (#4020923) Homepage
    I'm not a 1337 coder and don't pretend to be one so please excuse my ignorance.. What exactly is the exploit with sprintf? I've never used it but now you've sparked my curiosity.

    Anyone have any links or posts describing the issue would be appreciated.
  • by Futurepower(R) ( 558542 ) on Tuesday August 06, 2002 @04:38PM (#4020932) Homepage

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

    This software provides you a new administrator password: Locksmith. [winternals.com]
  • Re:Don't Do That (Score:2, Interesting)

    by Heffe Llama ( 38645 ) on Tuesday August 06, 2002 @04:39PM (#4020944)
    Even if they are not supposed to do that, I suspect that this could even happen with the CTRL-ALT-DEL handler that Microsoft put in, write a program that sends CTRL-ALT-DEL, then wait a few seconds, get some window handles and then have fun.
  • Re:Fixability (Score:3, Interesting)

    by Glorat ( 414139 ) on Tuesday August 06, 2002 @04:43PM (#4020976)
    Contrary to what the writer believes, all messages must go through the queue.

    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
  • by evbergen ( 31483 ) on Tuesday August 06, 2002 @04:50PM (#4021031) Homepage
    You cant have it both ways. You can't complain about Microsoft's lack of security, and then whine when they decide to implement security measures.

    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:Oh really? (Score:2, Interesting)

    by dzym ( 544085 ) on Tuesday August 06, 2002 @04:52PM (#4021045) Homepage Journal
    I'll step out on a limb here and say that not a single one of them is set to interact with the desktop.
  • by limekiller4 ( 451497 ) on Tuesday August 06, 2002 @04:52PM (#4021050) Homepage
    cheezedawg writes:
    You cant have it both ways. You can't complain about Microsoft's lack of security, and then whine when they decide to implement security measures. Palladium is designed to guard against this exact kind of attack. His 'shatter' application would be prevented from accessing the memory of the VirusScan.

    Clearly, the Slashdot crowd does not object to Palladium because it's secure, we object to Palladium because it's a standard MS ploy to make themselves the standard.

    Because we object to thing A does not mean we have to accept everything that isn't A.
  • by NanoGator ( 522640 ) on Tuesday August 06, 2002 @05:03PM (#4021118) Homepage Journal
    "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."

    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 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.)

    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.

  • by burgburgburg ( 574866 ) <splisken06NO@SPAMemail.com> on Tuesday August 06, 2002 @05:04PM (#4021128)
    When the Windows Media Player patch came out, I installed it on a box that I sometimes use. It was only later that I found out about the DRM component of the EULA. I immediately removed WMP. But does that legally rescind my agreement?

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

  • by cheezedawg ( 413482 ) on Tuesday August 06, 2002 @05:17PM (#4021259) Journal
    I don't want their lousy software saying what my hardware has to look like.

    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.
  • Re:Don't Do That (Score:4, Interesting)

    by bwt ( 68845 ) on Tuesday August 06, 2002 @05:20PM (#4021291)
    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?
  • by jasen666 ( 88727 ) on Tuesday August 06, 2002 @05:24PM (#4021330)
    Log onto your w2k box as "guest". Open the "computer management" window. Go down to users and attempt to add a new one. The dialog opens up. Yes, even guests can at least open the dialog. This dialog runs as system. I can use this exploit now. Thank you.
  • Re:Don't Do That (Score:5, Interesting)

    by ChrisPaget ( 229422 ) on Tuesday August 06, 2002 @05:26PM (#4021350)
    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.
  • sprintf() _is_ safe. (Score:4, Interesting)

    by Antity ( 214405 ) on Tuesday August 06, 2002 @05:57PM (#4021589) Homepage

    Whoever designed sprintf() and gets() should be shot since there's no way to specify the buffer size.

    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:Take control? (Score:3, Interesting)

    by MORTAR_COMBAT! ( 589963 ) on Tuesday August 06, 2002 @06:02PM (#4021624)
    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 :)
  • by Anonymous Coward on Tuesday August 06, 2002 @06:22PM (#4021784)
    The fellow that wrote this paper lacks an understanding of how X works. Using Xlib I can do essentially what this does in Windows with XSendEvent in X. People have known about this exploit for years in X. You need this capability for things like drag and drop and it comes in handy for application testing/automating. XTerm actually has a resource to enable/disable events sent via XSendEvent. I don't consider it much of an issue. As long as the programs you are running are trusted then you should be safe. I sincerely hope that this doesn't encourage kids to start writing awful hacks that end up deleting the files of a user. I don't consider this a flaw in Windows, because disabling this feature would severely limit Windows.
  • Re:Don't Do That (Score:3, Interesting)

    by bnenning ( 58349 ) on Tuesday August 06, 2002 @06:38PM (#4021874)
    There's no way for that to overflow the allotted 120 chars. No way at all.

    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 );

  • by dark druid ( 325782 ) on Tuesday August 06, 2002 @06:46PM (#4021918)
    This is not a security vulnerability in windows. In windows the security boundary for GUI objects is the window station/desktop. Within the same winstation or desktop you can send any message to any window you want. You can set ACLs on the window station to prevent low privileged users from accessing a window station or desktop. Services by default run in an isolated winsta/desktop on a per user basis (i.e. all the SYSTEM services share a winsta/desktop). No low privileged app can send anything to that desktop. If you check the let this service interact with the desktop option for a service then it is moved into the main user window station and desktop. That service can then present UI to the first user which logs into the system if it wants. The service also gets all the security risks of running in that desktop. If you choose that option then you get what you asked for and need to secure that code for running in the interactive session. Running this way also doesn't work with fast user switching or terminal server since you can have multiple users logged in at the same time. If a service wants to present UI to the user then it needs to run in a client server model and a process running in the user session and communicate back to the parent using COM/RPC/whatever.
  • Like GTK (Score:3, Interesting)

    by 0x0d0a ( 568518 ) on Tuesday August 06, 2002 @08:38PM (#4022463) Journal
    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.
  • by DavidBrown ( 177261 ) on Tuesday August 06, 2002 @09:22PM (#4022614) Journal
    Well, if you violate the EULA, you are in breach of contract. If you remove the software, you will be limiting your damages to the damage you caused prior to the removal. But the real question is this: Is Microsoft going to sue you? No, unless there are damages.

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

  • What about wine? (Score:1, Interesting)

    by Anonymous Coward on Wednesday August 07, 2002 @12:31AM (#4023274)
    I am wondering if this exploit will work with
    Wine (as in "Wine Is Not an Emulator")?
    If so does it mean wine is a vulnerability in
    linux?
  • by cookd ( 72933 ) <douglascook&juno,com> on Wednesday August 07, 2002 @12:52AM (#4023368) Journal
    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.
  • Re:Pot, meet kettle (Score:3, Interesting)

    by Anonymous Coward on Wednesday August 07, 2002 @02:30PM (#4026574)
    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.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...