Forgot your password?
typodupeerror
Security

Shattering Windows 965

Posted by timothy
from the fundamentalism dept.
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:
    • Pot, meet kettle (Score:4, Informative)

      by sql*kitten (1359) on Wednesday August 07, 2002 @05:30AM (#4023906)
      You know, I remember when you could do all sorts of fun stuff with X11. For example, you could layer a transparent window on top of a display, that passed keypresses and mouse events to the window beneath it - and capture everything the user did. You see, most people used xhost for security - which meant that you gave control of your display to anyone who had access to the machine your X client application was running on.

      Due to this, we now have xauth and MIT Magic Cookie. Anyone who says a security hole "can't" be fixed is naive - even if the fix is a kludge. MIT Magic Cookie is easily snoopable, so that's another security problem. The X11 protocol itself is easily intercepted, so we have to tunnel over SSH.

      I could go on, but I've made my point. Linux users who take it on faith that they are secure are sadly misguided - as are those who believe that Windows is inherently less secure. Ultimately, it comes down to the skill of the sysadmin to secure any OS.
  • by Dynamoo (527749) on Tuesday August 06, 2002 @03:58PM (#4020529) Homepage
    "Essentially, they allow you to take control of any window on your desktop".. sounds like it's straight out of Microsoft's new EULAs.
    • no, no..... (Score:5, Funny)

      by Lord_Slepnir (585350) on Tuesday August 06, 2002 @04:20PM (#4020764) Journal
      Their EULA reads "Essentially, you will allow us to take control of any window on your desktop." Glad I could clear that up.
    • by burgburgburg (574866) <splisken06 @ e m ail.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?

      • Or if Microsoft has somewhere noted your initial agreement, is it in perpetuity? Does Microsoft permanently own that box?

        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!!!!!"

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

    • Like GTK (Score:3, Interesting)

      by 0x0d0a (568518)
      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.
  • Ummm... 'Kay (Score:4, Insightful)

    by handorf (29768) on Tuesday August 06, 2002 @03:59PM (#4020538)
    So basically you're saying that if you can get a user to run arbitrary code and that user has access to applications with higher access rights, you can get those access rights.

    If you can get the user to run arbitrary code, they're already dead.

    Not to say that windows is secure, but this seems to be picking nits to me.
    • Re:Ummm... 'Kay (Score:5, Informative)

      by ptomblin (1378) <ptomblin@xcski.com> on Tuesday August 06, 2002 @04:03PM (#4020583) Homepage Journal
      You misunderstand. He's talking about NT/2000/XP, where you have privilege and non-privilege accounts, and where even as a non-privilege account, you can have stuff running as the Windows equivalent of "root", and you can use any window that "setuid root" application pops up to root the box yourself.

      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)

        by handorf (29768)
        Right... a non-priveleged user has access to a window running a more-priveleged account.

        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)

          by davebooth (101350) on Tuesday August 06, 2002 @06:08PM (#4021667)

          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:Ummm... 'Kay (Score:3, Insightful)

        by MisterBlister (539957)
        Yeah but in any case, software companies could work around this without breaking the Win32 API just by seperating out the parts of the code that need special privledges from the user interface code and use a secure message passing system (not based on standard windows message passing) between the two.

        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.

      • by Otis_INF (130595) on Tuesday August 06, 2002 @04:19PM (#4020747) Homepage
        When I put a service on Win2k, running under 'System' and that service listens to a port and executes all the crap that is posted to that port, is it MS' fault? No. It's the fault of the developer of the service.

        Now, under win32, the application you start, runs under the user you log in with. The virusscanner window in the example, SHOULD run under the user that is logged in, but instead, it's a GUI created from the service, running under 'System'.

        Bad programming. Not from Microsoft, but from the Virusscanner developer. They should have created, AS stated by MS, a GUI less service (the virusscanner engine) and a GUI application which talks to that service via a named pipe or any other process communication mechanism. That GUI should then be started by the logged in user (since that user sees the gui and works with it), so there wouldn't have been ANY flaw like this, since the GUI isn't ran under 'System', but under the user who's logged in, in the example the 'guest' account.

        It sounds serious, it's absolutely nothing.

        Oh, and it takes a local user to exploit it. Get a huge hammer and give it to the local user. Ask that user to smash the computer. There ya go, a DoD attack which isn't fixable, you can get that attack-script at any hardwarestore.
        • 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.
          • I'm not sure how you determined this, but on my computer the "New User" window on my system is put up by mmc.exe, which is being run by me.

            I verified this using Spy++ (from Visual C++) and Proccess Explorer (www.sysinternals.com).
          • Ummm NO (Score:4, Insightful)

            by spacefrog (313816) on Tuesday August 06, 2002 @08:24PM (#4022409)
            How are you arriving at the conclusion that this dialog runs with system priviliges?

            IT DOESN'T

            The GUI comes from a DLL running inside the process space of MMC.EXE. It uses a fairly secure RPC/IPC mechanism to talk to Windows.

            A simple trip through spy++ will even tell you the owner process in about 5 seconds.
        • by Doomdark (136619) on Tuesday August 06, 2002 @05:38PM (#4021455) Homepage Journal
          that service listens to a port and executes all the crap that is posted to that port, is it MS' fault?

          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)

      by mekkab (133181) on Tuesday August 06, 2002 @04:04PM (#4020586) Homepage Journal
      (RING!)

      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!

    • First of all, the equivalent problem exists on X:

      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.

  • by scorpioX (96322) on Tuesday August 06, 2002 @03:59PM (#4020547)
    This just goes to show that security has to be DESIGNED into the very core of any code and not as an after thought (10 years later in the case of the Win32 API). Taking a month off from new features to implement "Trustworthy Computing" isn't going to fix anything.
    • 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?
      • 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.

      • This won't even solve the problem, since this exploit should work from any environment that has access to enough of the Win32 API to enumerate windows and call SendMessage(). Things like VB, VBA, etc.

        I can't imagine enybody suggesting that only Microsoft signed Excel scripts will be allowed to run, for example.
    • by kawika (87069) on Tuesday August 06, 2002 @04:28PM (#4020844)
      Oh, absolutely. Whoever designed sprintf() and gets() should be shot since there's no way to specify the buffer size. We should all stop using the C library since it's fatally flawed.

      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.

      • by Chmarr (18662) on Tuesday August 06, 2002 @04:59PM (#4021083)
        I think you missed an important part of the paper:

        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)

        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.

    • by cheezedawg (413482) on Tuesday August 06, 2002 @04:28PM (#4020847) Journal
      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.

      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.
      • 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.
        • You are right, Palladium is about control. Security in general is about control. Palladium seeks to control untrusted applications. From everything Microsoft has released, it does not dictate what is trusted any more than your browser decides which SSL certificates are trusted.

          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.
      • by Znork (31774) on Tuesday August 06, 2002 @04:51PM (#4021033)
        Exactly how would Palladium guard against this kind of attack? The 'shatter' application is already prevented from accessing the memory of VirusScan through ordinary protected memory. The attack works through ordinary communications channels that have to work with or without Palladium and it does nothing that violates any (flawed) builtin security. The code once injected will run as the 'signed' code of VirusScan and Palladium couldnt prevent that either or it'd open a whole can of worms with self-modifying executables.

        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.
  • 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
    • Re:Fixability (Score:4, Insightful)

      by erasmus_ (119185) on Tuesday August 06, 2002 @04:12PM (#4020663)
      Finally, a constructive response to the problem. However, since you still don't have the capability of seeing what the source of the message is, I don't see how you can drop all of those messages with 100% certainty. Those API calls are there and are used legitimately as well, for better or for worse. So although your way coulf fix things, I wouldn't be surprised to see it breaking some applications along with it.
      • Re:Fixability (Score:3, Insightful)

        by Wrexen (151642)
        The basic idea would be to install a WM_GETMESSAGE hook. Contrary to what the writer believes, all messages must go through the queue. No two ways about it. At the hook level, we just examine the message and look for suspicious activity. Simplistically, all that really needs to happen is to look for EM_SETLIMIT and cap the WPARAM at some small value. It might also be good to remove callback addresses from WM_TIMER, or add verification (is the destination address part of the loaded executable space?). Most applications won't use the callback feature of WM_TIMER anyway.
        • Re:Fixability (Score:3, Interesting)

          by Glorat (414139)
          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
          • Re:Fixability (Score:3, Informative)

            by Wrexen (151642)
            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
            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)

      by HopeOS (74340)
      A cursory look through the hook API does not suggest that one can block messages based on the calling process. There appears to be a way to determine if the current thread made the call, but that is largely useless. Threads post inter-thread messages all the time. The real question is whether that thread belongs to the same processes as the receiving window.

      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
    • by Vicegrip (82853) on Tuesday August 06, 2002 @04:49PM (#4021023) Journal
      Many applications actually use Windows messages to synchronize themselves between threads and processes.

      In fact, there is also an API called PostThreadMessage that will post any windows message to any win32 application (all you need is the thread handle) with a message pump.

      Out of process COM interfaces using windows messages will also be broken by removing this functionality.

      Microsoft's excuse that having physical access to a machine is required is abysmal.
    • by b0bd0bbs (592231) on Tuesday August 06, 2002 @05:22PM (#4021317)
      AFAIK you can still allocate ring 3 descriptors via windows DPMI calls, change them to ring 0 descriptors via an LDT mapping (which is legal in pmode the way windows sets things up), then execute any code in your program as ring 0. Woohoo. That *feature* has been around for at least 6 years.
  • by pbemfun (265334) on Tuesday August 06, 2002 @04:04PM (#4020589)
    Before jumping to conclusions, read the reply to the "vulnerabilities" on the BugTraq mailing list here [securityfocus.com]. Doesn't look like its something unknown to the public and its really more of a vendor problem, not MS one.
  • Don't Do That (Score:3, Insightful)

    by cperciva (102828) on Tuesday August 06, 2002 @04:05PM (#4020593) Homepage
    This "vulnerability" only effects poorly-written applications, running with system priviledges, which create windows in user-space.

    You're not supposed to do that.

    If you want to have a service which is user-configurable, create two separate programs (one service & one gui) and communicate via a named pipe.

    This isn't a flaw in the win32 API. This is a flaw in some applications which run under windows.
    • Re:Don't Do That (Score:4, Insightful)

      by Rick the Red (307103) <Rick@The@Red.gmail@com> on Tuesday August 06, 2002 @04:20PM (#4020761) Journal
      Exactly! You could write a similarly flawed Linux application that someone could exploit to gain root access.

      Some Windows apps are not secure. News at /.

    • Re:Don't Do That (Score:5, Informative)

      by rjh (40933) <rjh@sixdemonbag.org> on Tuesday August 06, 2002 @04:22PM (#4020789)
      This isn't a flaw in the win32 API. This is a flaw in some applications which run under windows.

      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)

        by cpeterso (19082) on Tuesday August 06, 2002 @04:52PM (#4021046) Homepage

        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)

          by pclminion (145572) on Tuesday August 06, 2002 @05:28PM (#4021363)
          Why can't glibc help make the world a better place by dropping dangerous functions, such as gets()

          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:4, Interesting)

        by bwt (68845) on Tuesday August 06, 2002 @05:20PM (#4021291) Homepage
        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?
    • Re:Don't Do That (Score:3, Informative)

      by Anonymous Coward
      > This "vulnerability" only effects poorly-written applications, running with system priviledges, which create windows in user-space. You're not supposed to do that.

      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.
  • by guttentag (313541) on Tuesday August 06, 2002 @04:09PM (#4020637) Journal
    We're doing this thing called "Trustworthy Computing." It's an evolving concept.
    It starts out meaning "We are worthy of your trust."

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

  • 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 weld (4477) on Tuesday August 06, 2002 @04:14PM (#4020682)
    Where is it documented that windows provides a privilege boundary at the message interface? There is none. The example application was poorly designed.

    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":
    http://www.atstake.com/research/a dvisories/2001/a0 20501-1.txt

    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

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

      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.

      ...and the same company wants to bring us Digital Rights Management to the desktop. Hell, they can't even lock down root. :-)

  • by Ryan_Terry (444764) <MessEdUp@violent ... m minus caffeine> on Tuesday August 06, 2002 @04:15PM (#4020705) Homepage
    --Flaimbait--

    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...
  • by leshert (40509) on Tuesday August 06, 2002 @04:18PM (#4020731) Homepage
    If you have physical access to the box, there are n ways to get your code executed in a Windows app. WM_TIMER (the callback version) is one, as are window hooking, CBT hooks (computer-based-training, although I've never seen it used for this purpose) forcible DLL loading (if you have access to the Registry), debug process attachment, CreateRemoteThread, thunking well-known DLLs (which is why Red Alert 1 won't play on Win2K without a patch--they can't thunk kernel32), etc., etc., etc.

    Windows programmers have been using these methods for non-evil reasons for many years--the "3D look" of MS Office apps before Windows 95 was done this way.

    The insecurity of the desktop model for Windows shouldn't surprise anyone. It wasn't designed to be secure OR multi-user, and patching after the fact doesn't make it so. It's comparable to complaining that telnet and ftp send passwords in clear text. Well, no kidding, they weren't designed to be secure, so they're not.

    And like the case of telnet, making a secure but still 100% backwards compatible solution is pretty much impossible, as the article states.
    • "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 timothy_m_smith (222047) on Tuesday August 06, 2002 @04:21PM (#4020769)
    Here is what the author had to say about himself at the end of the paper:
    Foon, AKA Chris Paget, first started programming on a ZX81 at the age of 4. He's been working with computers for longer than most of the bosses he's had. After extending a BBC B to include an ADC capable of filling the machine's memory in less than 2 seconds and scaring the cleaners with automated voice warnings when they entered his room, he got bored and moved onto PC's and Windows, where the majority of his skills lie. Able to program in 23 languages on 14 platforms, Foon takes an average of 3 days to learn a new programming language. He's currently available as a freelance security consultant - his CV is available on request.
    Aren't we the most important programmer ever!
    • by Anonymous Coward on Tuesday August 06, 2002 @04:33PM (#4020884)
      He also has never talked to, nevermind had sex with, a woman. He finds that he has trouble making friends, partially because of his inability to talk about anything besides the 23 languages and 14 platforms he can program for, and the onion-like smell which lingers behind is unshaven, rarely cleaned body. In order to make up for his indescribably small penis, Chris brings up debate in favor of technologies to boost his ego such as functional programming, UNIX, and any one of the 23 languages on 14 platforms already mentioned twice before that he can program for and you can't.
    • by greygent (523713) on Tuesday August 06, 2002 @04:54PM (#4021062) Homepage
      This poster finds it narcissistic and silly that the author wrote about herself in the 3rd person.
  • by Anonymous Coward on Tuesday August 06, 2002 @04:23PM (#4020794)
    Any application on a given desktop can send a message to any window on the same desktop, regardless of whether or not that window is owned by the sending application, and regardless of whether the target application wants to receive those messages.
    Without this "flaw", programs such as RtvReco [clearlight.com] which automate closing dialogs and sending text, etc., would not exist. In fact, 4 years ago (gosh, its been a long time), at the curious age of 12, I wrote an extensive software suite to mess around with other applications' windows. Since then others have caught on -- Password Revealer [rekenwonder.com], anyone?

    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:

    The final message that we're going to make use of is WM_TIMER. This is a slightly odd and very dangerous message, since it can contain (as the second parameter) the address of a timer callback function. If this second parameter is non-zero, execution will jump to the location it specifies. Yes, you read that right; you can send any window a WM_TIMER message with a non-zero second parameter (the first is a timer ID) and execution jumps to that address. As far as I know, the message doesn't even go into the message queue, so the application doesn't even have the chance to ignore it. Silly, silly, silly...

    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

  • For example, the virus scan writer probably tests, develops and uses windows while logged into the "administrator" account interactively, as do most users. In Win98, it's not even a question -- you're always the "root" of the box. I'd wager that "What access could a non-administrator user obtain through our GUI/message interface?" hardly occurred to the GUI programmers for this particular virus scan software, even though their interface ran at LocalSystem (geeez).

    As mentioned elsewhere, there are ways to avoid these problems: If you really need to use gui elements as administrator, run them under a separate desktop or windowstation where the interactive user can't touch it. Run the GUI interface impersonated down to a lower level, such as that of the interactive user. If you have to be administrator or local system, treat all input as untrusted, including (especially) window messages! Don't use edit box constraints as buffer limits. Don't use the default window procedure. etc etc etc.

    It's true, however, that the default behavior for WM_TIMER is a pretty big security flaw (IMHO). But contrary to what this writer inaccurately claimed, you can still intercept the WM_TIMER message and handle it yourself, and any security-conscious program should never pass unexamined WM_TIMER functions to the default window procedure. This makes me start to wonder about other flaws in the default window procedures... as Microsoft wants you to think that the defaults it gives you are safe and secure. hmmmm...
  • Virus in his code (Score:3, Informative)

    by agrounds (227704) on Tuesday August 06, 2002 @04:35PM (#4020899)
    In the shatter exploit he's linking on his website, there is a virus in the sploit.bin file. It's a W32.Beavuh, and Norton Corporate flagged it immediately. So, surfer beware! It's hard to take security fame-seekers seriously when their code is trojaned.
    • by silentbozo (542534)
      In his notes he mentions "Yes, I know that I should have written my own shellcode."

      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...
    • by kawika (87069) on Tuesday August 06, 2002 @05:09PM (#4021184)
      Duh! The exploit is *intended* to be malicious code that causes a buffer overrun in an application and could be used to break into a system. That's the point!

      Hint to moderators: Try "Funny" next time.
  • by teamhasnoi (554944) <teamhasnoi&yahoo,com> on Tuesday August 06, 2002 @04:37PM (#4020927) Homepage Journal
    Look for a period by itself on the bottom left of the screen. It looks like an off-pixel. Hold down "Shift", then click on it.

    Bam! Root access.

    This works on the systems of the DMV, FBI, DOD, Equifax, Telephone and Utillity companies.

    I couldn't believe it myself! I said, "This is so easy, even Sandra Bullock could hack this!"


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

    This software provides you a new administrator password: Locksmith. [winternals.com]
  • by Uller-RM (65231) on Tuesday August 06, 2002 @05:00PM (#4021088) Homepage
    I'm really, really disgusted that this even got posted. This isn't a Win32 vulnerability, it's a Virusscan vuln. (Watch my karma burn, I'm actually defending MSFT... but hear me out.)

    For those of you who aren't familiar with Windows programming, here's what he's doing. Viruscan's GUI is very poorly written and doesn't check for a maximum length on a text box's input. So, he adjusts the size of a textbox using an outside program to 4GB. (Windows unfortunately allows this, since the message format doesn't include a "sender" field to check against the owner handle.) He then inserts shellcode in it, attaches a debugger to the process and searches all of memory for the start of the shellcode. Real efficient, this one.

    He then sends it a WM_TIMER message to trigger it. WM_TIMER is usually sent to your window on a regular interval when you've called SetTimer(), and contains either an integral ID or a pointer to a callback in memory. So, he sends it a fake WM_TIMER, and Viruscan executes the callback blindly.

    You know what, I use WM_TIMER too in my apps - but, there's two simple ways to defend against it.

    if ((void *) msg.lparam != known_cb_address)
    {
    return false;
    }

    if (0 != IsBadCodePtr((FARPROC) msg.lparam))
    {
    go_fuck_yourself();
    }

    And if I'm not using it, special-case it so that it doesn't fall through to DefWindowProc().

    Seriously, all this guy is doing is buffer overflowing a poorly written program to get Administrator privs. That's like claiming that glibc is insecure and should be thrown out because it has sprintf() or gets(). Ya know, I can buffer overflow a poorly written suid app too, but that doesn't make the libc to blame, nor have we published articles lambasting the GNU Project for not putting bounds checking into those functions.

    This guy's just trying to sell himself [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.
    • by Glorat (414139) on Tuesday August 06, 2002 @05:56PM (#4021583)
      Sorry, I disagree with many of your comments here. While you've successfully tried to be objective without flamebait, some of the facts you have aren't true. I will try to be equally objective

      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,
      • by Uller-RM (65231)
        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.

        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)

      by RelliK (4466)
      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.

      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.

  • Nice try (Score:3, Insightful)

    by The Bungi (221687) <thebungi@gmail.com> on Tuesday August 06, 2002 @05:01PM (#4021095) Homepage
    This is very interesting reading (not). This dude is a 30-something loser wannabe hacker that throws away all measure of the respect he was trying to obtain by peppering his "paper" with 1337 speallingz like "0wn" and "sploit" to feel more in the know.

    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.

    1. Paper
    2. ???
    3. Recognition! Fame! Fortune! Girls! Coverage! Beer! Girls!
  • This is a flaw (Score:3, Insightful)

    by ChaosDiscordSimple (41155) on Tuesday August 06, 2002 @05:30PM (#4021382) Homepage

    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.

  • by p3d0 (42270) on Tuesday August 06, 2002 @06:04PM (#4021639)
    This guy is so full of himself, I don't know how he could be taken seriously. He wants us to think he's David for MS's Goliath, and he has just discovered his sling. Well, I'll believe it when I see it.

    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.

  • Look... I'm in no hurry to defend Microsoft but being as I develop for their OS on a daily basis - its common knowledge (or should be) that anybody who runs a service under system privileges that presents a GUI to any old user - is a fucktard that simply needs to die. Yes this problem can be fixed by MS using the 2nd option indicated in the paper and yes it would mean these crappy designed apps written by third parties would have to be rewritten.

    Microsoft specifically reccommends that you do not run services and allow them to interact with the local desktop. Doing so is security suicide. Thats how VirusScan was running. Therefore its a McAfee issue since there are about a bazillion better ways to write this app.

    J
  • by tlambert (566799) on Tuesday August 06, 2002 @07:43PM (#4022240)
    Why are people pretending that this is not a problem with the design of Windows?

    It seems perfectly obvious to me that all you would have to do to fix this would be to associate applications credentials with messages as they are passed around, and not permit messages from a process with a lower priviledge to be sent to a process with a higher priviledge, unless a security association is established.

    This would mean changing the messaging API, but it's fixable. It would merely mean recompiling all third party code that needed t communicate across priviledge boundaries, and adding code to programs designed to operate at higher priviledges to accept the new message type, rather than dropping it on the floor (making that the default), and make a decision based on that.

    This is the standard "capabilities" security model, and is the same model that used for NT file permissions, in terms of a hierarchical inherited rights arrangement.

    There would be a significant impact on "remote control", some install tools, and other packages that are not written with the idea of priviledge domain seperation, but it's *possible* to fix.

    -- Terry

Reference the NULL within NULL, it is the gateway to all wizardry.

Working...