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