Slashdot Mirror
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."
In my SUS server at my corporation, I disabled this stupid tool because all it does it pop up with some confusing error message that the end user does not understand. Then they would all just call me asking about a weird popup they got on their screen. I am deploying the windows patch via SUS and the office pack via scripts, so there is nothing for the end user to do anyways.
They are actually 3rd party products that distribute Microsoft DLLs as part of the runtime code. The argument is that these companies need permission from MS, who should then have a master list of who asked for permission and why.
Learning HOW to think is more important than learning WHAT to think.
No, MS IS checking third party software, but not updating it, and still warning you about it. And warning you without telling you exactly what is wrong, the worst kind of error message, one that Windows is quite fond of.
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.
I totally agree with the 'worse than useless' statement. In my office, I had to disable it on the corporate SUS server because all it did was pop up and worry users. It gives no meaningful information. It does not patch all the dll's that it may or may not find. It merely scares users into thinking they had a virus. This is the only thing in my SUS list that is not approved and it will stay that way forever as far as I am concerned.
While Microsoft isn't responsible for 3rd party DLLs, this is a different situation. They are partially responsible, and if they were interested in making the client systems secure they would handle things differently for what is really a simple file update.
Reasons: They designed a system that requires 3rd parties to distribute DLLs that Microsoft created. If the DLLs were set in a well organized location, the updates of the system DLLs would automatically 'fix' the other programs. Versioning -- something that Windows DLLs support and programs can take advantage of -- would handle compatability issues that are not directly incompatable with this fix.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
So it gets worse, _then_ it is useless?
So far, everyone else responding seemed to have missed your point. The article correctly uses "worse than usless". It is the submitter and/or our ever so thorough Slashdot editors to blame for the "worse then useless" grammar mistake.
And for all of you that missed the grammar mistake and are debating the meaning of "worse than useless", yes, things can be worse than useless. Things can be harmful. They can cause additional harm or frustration, as opposed to a useless item which just does not do anything useful.
When will Windows be ready for the desktop?
http://www.microsoft.com/downloads/details.aspx?Fa milyId=6A63AB9C-DF12-4D41-933C-BE590FEAA05A&displa ylang=en
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.
There are no trails. There are no trees out here.