Slashdot Mirror
MS Message Security Flaw Explained
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."
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.
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.
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 to better its software. When confronting an opponent, you don't tell him of all the weaknesses you see, do you?
social sciences can never use experience to verify their statemen
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 about privilege spaces. For old-hat Windows people working on desktop applications, this is a new concept compared to the 9x days. Most of them aren't trained to think in terms of privileges anyway.
As a vulnerability, this problem quite simply DOES NOT EXIST when application designers follow the security boundaries properly. This is not something Microsoft should address in the Windows API.
...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.
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 your credit card number? Both programs probably have the same privilages, but QuickBooks has access to data that no other program should have. Ad hoc scripting, by definition, permits this possibility.
Finally, I seriously question the value of accepting messages from other programs that cause you to execute a function of the other program's choosing. I can't see any legitimate use for this that justifies the risk.