Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Microsoft Security

MS Message Security Flaw Explained 48

Posted by timothy from the the-fix-is-in-and-waddles dept.
Geoff Shively writes "Canadian security researcher Oliver Lavery published a fantastic paper on Win32 Message Vulnerabilities. The paper touches on a the Shatter problem that received much attention almost 1 year ago regarding the fundamental flaws in the Win32 API. Oliver's research demonstrates that the Shatter vulnerability is still very much in existence and quite a threat. Vendors need to wake up and work towards fixing this problem in their applications."
This discussion has been archived. No new comments can be posted.

MS Message Security Flaw Explained More

MS Message Security Flaw Explained

Comments Filter:

  • Venders problem? (Score:3, Insightful)

    by Trevelyan ( 535381 ) on Saturday July 12, 2003 @10:46AM (#6423803)
    Why should venders fix this it an OS problem and Microsofts fault. Working around bugs only lead to more bugs and problems.

    Reminds me of a CS class I once had, the lecture (admittedly a unix advocate) was explaining a problem with software deadlines. ie release now (for market reasons) and fix problem later:
    -MS build next version of Windows and Office at same time, so that they can release together.
    -Office is tested on beta versions of windows, which obviously has bugs, the Office peeps work around the bugs.
    -mean while the windows peeps fix the bugs
    -near release office found not to work right because it is trying to work around bugs which aren't there. (Why they let an Office app play voodoo with the OS is up to you to decide)
    -need to release on time, so put bugs back in windows problem sorted.

    It will be difficult for MS to fix the message system w/o breaking old apps.

    • Re:Venders problem? (Score:2, Informative)

      by pldms ( 136522 )
      Why should venders fix this it an OS problem and Microsofts fault. Working around bugs only lead to more bugs and problems.

      I agree absolutely. Letting any app call any function as described in the paper isn't a smart idea (I assume it predates multiple users in windows, but still...).

      However Microsoft's advice is sound. Having setuid apps is always hairy - anyone remember Apple's moment of shame [securemac.com]? There's a little bit of guilt on the vendor side, too.
  • Y'know, I've had the shatter attack paper on my bulletin board since the original slashdot article, and I've seen few references to it since.

    Anyone know if this has been successfully used in the "wild"? Is Microsoft even taking this seriously?

    Enquiring mind wants to know.

    SB
  • Looks like the event model for Win32 was flawed from the beginning and should have changed long ago. Looking at the Mac event model (Carbon Events and even the WaitNextEvent/GetNextEvent), there is no passing of functions to the event handler at all so why did M$ design it that way back in 1993 I do not know.
    • Obviously to be backward-compatible with legacy apps that go back a lot further than 1993. Even in 1993 most PC's were not connected to the Internet, so the risk was pretty remote at that time. It's still fairly remote even now.
    • AFAICT, the model could be "fixed" by preventing applications from sending events to unrelated applications. (You'd need to permit threads and processes to send events to the thrreads and processes that spawned them, I guess.) Of course, this only works if events aren't supposed used for general IPC.

      • Allowing "ad hoc" messaging between programs is one of the best methods for allowing users to customize interactions between seperate applications. This was applied with great success using ARexx on the Amiga, and some using OSA/Applescript on Mac OS.

        So I do not believe it would be a good general solution to limit messaging to those paths pre-envisioned by the vendors themselves. Letting the reciever know what authority context the sender was operating in would be a better approach.

        • Providing an authority context in the message solves the problem by putting the burden on vendors. Remember, vendors were s'posed to be avoiding this problem already, by using a non-privelaged UI (like, say, SSH does).

          Since vendors don't place a high enough priority on security, it seems like someone is going to have to take care of it for them. If a program wants to accept messages other programs it should declare so explicitly.

          Otherwise, what's to prevent a trojan from using QuickBooks to find out you
        • table seems like a fairly simple solution, maybve too simple I am sure I am overlooking somthing
    • The reason why MS event handling is the way it is, is simple, the Win32 API uses common dlls so that programmers do not have to re-write functions. The problem lies when malloc gets mis-appropriated and function calls leave buffer overflows. This often happens because the programmer is essentially writing blind and trusting that their code will not conflict with a call to system dll. You are expected to code for Windows essentially blind as to how proprietary functions allocate.

      The strength of open source

  • Here we go again (Score:1, Offtopic)

    by The Bungi ( 221687 )
    Here's my response [slashdot.org] to that "article".

    Leave it to Slashdot to try and wring every last drop of blood from anything that even remotely smells like a "vulnerability", right up there with JavaScript that changes my wallpaper at the behest of evil Romanian hackers - I've always wondered why all those Unix/Linux exploits I see in Bugtraq and SecurityFocus and RedHat advisories don't get so much publicity.

    • Er, um. Did you RTFA? The author noted that the vulnerability existed but was not as serious as originally described. The author also noted that in some fault lies with the developer for not following MS guidelines for security. The article did point out that some serious vulnerabilities that *could* exist with similar Win32 API calls and demonstrated how these would work. Overall, the tone of the article was informative not zealot.
    • Pity I ran out of mod points yesterday evening. :(.. mod parent, anyone..
  • is not mentioned in the article. This new framework is claimed by MS to be much more secure, but we still have to live for a long time with "old" WIN32 applications.

    How will "old" style WIN32 message passing be affected by .NET managed code respective to this security hole?

  • Why are we doing MS' work for them? Pointing out these flaws only helps MS to fix them.

    If anything, we should be pointing out flaws in FS/OSS software so that we can make that better.
    • Pointing out these flaws only helps MS to fix them.

      Microsoft? ... fix? ... vulnerabilities? I understand the individual words, but somehow they don't seem to make a comprehensible sentence.

    • Why are we doing MS' work for them? Pointing out these flaws only helps MS to fix them.

      You don't understand. Here on Slashdot we all understand those issues and we all know that we shouldn't use any software written by Microsoft. But that's not the point. Unfortunately Slashdot is not the whole world. There are people who use this software and they would have no idea about those flaws if we didn't talk about them. We cannot ignore people just because they are uneducated or incompetent, because they

      • or perhaps... (Score:3, Insightful)

        by dh003i ( 203189 )
        it's that we want to see the flaws in MS because we dislike their software for practical and ethical reasons.

        However, pointing out flaws in MS software only helps MS. Very few people will change from MS to anything else, no matter how many flaws there are on it. It came with their computer, and they are of course too stupid (or so they think) to do anything else without borking their computer. So, by act of god, they're stuck with MS.

        And, of course, MS can take any criticism of its software and use that t

        • And, of course, MS can take any criticism of its software and use that to better its software. When confronting an opponent, you don't tell him of all the weaknesses you see, do you?

          An "opponent"? Well, I don't actually know you, you are apparently a CEO of Apple, I don't know, if Microsoft is your "opponent." This, or you are one of those "leat" Linux cheerleaders I've been hearing so much about. No, Microsoft is not an "opponent" for free software movement. In fact, look at where Microsoft was bac

          • Sure, if MS released everything under the EULA, it would not longer be the enemy. The superiority of software for GNU/Linux is another issue, entirely separate.

            But that's not -- ever -- going to happen. So, since MS will never release FS/OSS, they are the enemy, and always will be.

  • I'm glad to see other discussion of this. (Score:5, Informative)

    by Futurepower(R) ( 558542 ) on Saturday July 12, 2003 @02:17PM (#6424662) Homepage

    I had a section on the shatter attack and the messaging vulnerabilities in my paper, Windows XP Shows the Direction Microsoft is Going [hevanet.com], but I got so much hostile feedback on message boards from people who said it did not exist, or it was not the fault of Windows, that I took the section out.

    The shatter attack is a local attack only, that allows a logged-on user to elevate to administrator. Microsoft has recently (July 9, 2003) documented one messaging exploit: Flaw in Windows Message Handling through Utility Manager Could Enable Privilege Elevation (822679) [microsoft.com]. But what does Microsoft know, right?

    Apparently only two or three exploits of Windows messaging have been published. However, it seems reasonable that there are others.

    The whole question gets some people very upset. They say that it is the fault of whoever wrote a vulnerable application. But look at what's in Windows memory at any one time. There is a huge amount of stuff written by numerous people. It seems to me that it doesn't matter to the user how the vulnerability got there, a vulnerability is a vulnerability. If you use Windows, you are trusting numerous programmers to know how to pass messages because there is no authentication system.

    Consider this post by Uller-RM [slashdot.org]. He says, "... he [the attacker] 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.)".

    Yes, it is unfortunate. And fixing it requires a rewrite of Windows that breaks all present applications. Am I wrong about any of this?

    I'm not saying I understand everything about this, but I don't have time to investigate it further. I have to go back to writing a letter to a customer.
    • How hard and how crippling would it be to disallow non-privileged apps from sending to priviliged apps. That shoud fix the problem. And if for some reason two apps accross the boundary need to talk to each other, it could be designed to let the administrator link their message queues.
      • One problem is that an old application would not be prepared to deal sensibly with the denial of access. Maybe Windows could put a message on the screen.
      • But... Does the mouse pointer and keyboard qualify as a 'priviledged app' ? If no, then the privileged apps would not be able to get interactions via mouse and keyboard. If yes, then we still have all sorts of problems.

        Maybe the real issue is that 'privileged apps' should not have a gui! Take a look at how Mac-OS X handles the same concepts. The gui can not run as root, it can only execute another specific program as root if the appropriate authentication is passed.

        --jeff++

    • Re:I'm glad to see other discussion of this. (Score:1, Insightful)

      by Anonymous Coward
      An authentication system is entirely the wrong approach. That's like requiring authentication among all the SMTP servers in use on the Internet. Free communication is the point, not the problem.

      Every application within a user's space has always been fully accessible to everything else in that space. This concept exists nearly everywhere in the common computing world. Think about it: what does a debugger do? Where can you use it?

      The only security issue here is when application designers don't think ab

      • Re:I'm glad to see other discussion of this. (Score:1, Insightful)

        by Anonymous Coward
        ...however, as a followup, there is something Microsoft could set up that would have minimal impact on existing, properly designed applications.

        Message space filtering. By default, configure messages such as edit box length settings to be private to the application, and filter them when sourced from external threads.

        • This seems very sensible. I was thinking in broader, and maybe not completely technically accurate, terms. I was thinking of message space filtering as a kind of automatic authentication. This would not break existing applications.

          It has been claimed that it is possible to use the shatter attack against a clean install of Windows XP. It has been claimed that system processes are vulnerable to this attack. What do you think?

          • Re:What do you think? (Score:1, Interesting)

            by Anonymous Coward
            IIRC a couple of updates have been released for Windows XP to correct the system processes that were vulnerable. I don't have the details, but I seem to remember those appearing shortly after the initial Shatter paper.

            NT does have a very nice security model for nearly all kernel objects, and it extends to things like process handles (IDs, interfaces). I don't believe it currently extends to the messaging framework, but it probably could be without too much difficulty. That would allow processes to easil
        • And some proper limits should be enforced too.

          IMHO, a GUI should only give a program a window. Why should a program be able to mess with other programs that are running, or to read my screen? It should have its window, and that's it. For example, if Windows required you to confirm that you allow a program to read your screen or get a process list, then things like BackOrifice would become considerably more difficult.
  • the damn thing and get it over with.

    M$ is such a broken peice of crap that there is no repairing it.

    Everything M$ puts out is virusware.

Slashdot Top Deals

Garbage In -- Gospel Out.

Close