GDI Vulnerabilities: An Open Letter to Microsoft
UnderAttack writes "Tom Liston, the guy that brought us the LaBrea Tarpit, wrote an open
letter to Microsoft regarding the GDI JPEG vulnerability, and Microsoft's scanning tool for this vulnerability, which he calls 'worse then useless'. Tom, who wrote his own scanning tool, ends his letter with 'Please stop treating your customers like idiots and give us information; information that we can use.' Like Tom explains, the official Microsoft scanning tool misses a lot of vulnerable DLL's installed by third parties, and Microsoft fails to explain if these libraries are a problem or not."
When you need this tool, we will tell you and provide it for you. Until then, please continue buying our other tools.
Bill
Hrm... the Internet Storm Center... slashdotted... that'd be interesting. Somewhat poetic. But doubtful.
My blog. Good stuff (when I remember to update it). Read it.
The argument is that these companies need permission from MS, who should then have a master list of who asked for permission and why.
But, I'll bet that MS gives developers permission to distribute these with Visual Studio, which would mean there is no way that MS has a master list--moreover, much of the software may be for internal applications and the developer is long gone.
So, any VB program that does image manipulation may be poetentially vulnerable.
Most users ARE idiots. It seems completely appropriate that they should be treated this way. I very much mean this.
Yes, the slashdot crowd and others might do well to receive more information regarding vulnerabilities and fixes for them, but the average user would be overwhelmed.
I once mentioned to a gentleman that the standard encryption on an 802.11b WAP wasn't entirely secure and he panicked. He asked if hackers would steal his credit card and social security numbers. I asked if he ever shopped online or transmitted those numbers across the internet to which he replied emphatically no (he didn't even store them on his computer for that matter). He still did not understand that a "hacker" can not steal his information from a WAP if it was never there in the first place. He promptly switched to using a ethernet based network.
Most people are too stupid to be told even the fisrt thing about security. Better a patch is provided that works and they use it. Seeing as how the patch was not complete in this case, that'd differenty, yet the users should still be treated like morons.
-dave
http://millionnumbers.com/ - own the number of your dreams
Any valid points the author has about the uselessness of the tool, or the general state of affairs with security at Microsoft, are dimished by his pompous attitude and snide remarks.
Why not write a technically detailed letter about the code you find (since he read it so many times) and perhaps offer some constructive alternatives to improve it?
Not only would it be more interesting to read, but they might actually be more willing to consider it.
I spent about 45 minutes reading docs at MSDN/MSKB trying to find an explicit statement that IE6SP1 on Win98 is vulnerable, and I swear that they don't actually state that fact (explicitly) anywhere! I eventually was able to read between the lines and conclude that Win98 isn't vulnerable, but Win98 + IE6 is, so you should run Windows Update to DL the patch.
Am I certain? No. Like I said, it's very difficult to find answers to very simple questions in their docs sometimes. I especially hate reading their security bulletins because it's like they were written by very technical lawyers who are trying to maintain the illusion of releasing information without actually doing so. As often as is possible, I try wait a day or two for the DHS CERT to issue their bulletins because they do a slightly better job of relaying useful information.
"Lawyers are for sucks."
- Doug McKenzie
His letter might as well read:
Has anyone ever sent a closed letter?
Indeed, Netscape, which also uses that code for its JPEG decoding had that flaw (but it was fixed earlier, and of course, it did not make the news nearly as much as this Microsoft issue, owing to its much smaller market share.)
http://www.openwall.com/advisories/OW-002-netscape -jpeg/
There's 10 types of people in this world, those who understand binary and those who don't.
So, is Linus going to put out an advisory that there may be some random explit in the Gimp that allows user level access to hackers? I know there must be some random buffer overflow in the Gimp somewhere. Linus should point this out according to your logic, shouldn't he?
.so file (installed into a special directory for each application that uses it, for no good reason that anyone could gather, and Linus insists that they aren't allowed to modify it in any way), and there was then an update to that .so file, I would expect the update that Linus issued to fix all copies of it, yes.
/lib or /usr/lib and you only have one copy of each of them. An update would ensure that the single copy you depended on had the vulnerability eliminated.
If Linus wrote the code, and told the application authors that they were only allowed to use it by accessing a
Of course, nobody behaves like this in the Linux world. Shared libraries are installed to
Back in the day, it was recommended to put all system DLLs into the main system folder and all your custom DLLs into the app folder. But, Windows' awkward design and poor installation utilities led to many system DLLs being overwritten with old or broken versions. You would find yourself with a broken app and really no way to tell what caused it.
So, to stop the headache, we started putting system DLLs locally, thanks to the path priority built into Windows - it always checks local folders first. And it worked, most of the time. If you asked for a DLL by name and another app was using an incompatible version, you would get still the stinky one. But, if you were first to the call then you knew you would get yours.
But, the trend had taken root and like any good weed it is hard to get rid of.
I don't even think this tool is checking for the other sneaky developer trick of renaming the DLLs, either to hide the fact that it's not licensed or other legal yet obscure reasons.