This is my first post to./ since checking it out a few months ago and reading daily. Go easy on me if I say something dumb. My mother always said, go with what you're good at.
mwood: Trust shouldn't go too far.
Is it me, or is this vulnerability so terrible that you (we, anyone) would be better off fixing it at all costs, even if it breaks something else? I remember all too well the days of ANSI bombs.
A client of mine has vulnerable versions of the DLL (what client of mine doesn't?) in SxS directories (side by side) and also released with Sonic's RecordNow which shipped with their Dell machines.
Having read and read and read on the topic and seen the question voiced as to whether having vulerable versions of the DLL on your machine is dangerous, and seeing no answer posted, I have to assume that it IS dangerous to have any vulnerable DLL present anywhere on the system. I'd feel better if Microsoft's little "you may be vulnerable" tool would tell me "you're not vulnerable" or failing that, that no red lines appear on GDIscan.
I have an idea as to how one might deal with this on an automated basis but I find myself wondering whether it's really a great idea. So I thought I'd post the idea and see what you guys think.
Several messages here have provided links to the GDI scan tool, and I saw that there were two versions, one for the command line and one GUI.
Why not write a series of batch files or even a compiled program (Preferably compiled in something that doesn't require distribution of Microsoft DLLs ) that could be placed in a login script, which would take the following steps:
1) Use the command line GDI-scan tool to create a list of DLLs;
2) Use a grep-like utility to find the lines and therefore the local paths of those vulnerable files;
3a) Rename, mangle, zip, erase, or otherwise disable those files, or;
3b) Replace those files with the Microsoft-supplied replacement for GDIplus.DLL;
4) (I assume this is a good idea but haven't investigated how - I remember something about a register command) de-register the old DLL and re-register the new;
5) Re-run the scan to a text file;
6) Create a report of activity on some shared drive or send it somewhere so as administrator, you can review what was done on all machines and alert users as to possible problems with apps that require the DLL.
7) Wait for whatever breaks to break, as opposed to waiting for whatever random attack from whoever might somehow get a foothold.
My client is a law firm and just doesn't care about Sonic RecordNow, and probably doesn't care about whatever software caused the old DLL to be placed in WinSxS. But, even if one of these apps were in use, a replacement or upgrade could be procured or an intelligent and timely decision could be made about what to do to solve the problem.
So... what do you guys think?
Slashdot Mirror
Or do something dumb like post with no line breaks. Even.
This is my first post to ./ since checking it out a few months ago and reading daily. Go easy on me if I say something dumb. My mother always said, go with what you're good at.
mwood: Trust shouldn't go too far.
Is it me, or is this vulnerability so terrible that you (we, anyone) would be better off fixing it at all costs, even if it breaks something else? I remember all too well the days of ANSI bombs.
A client of mine has vulnerable versions of the DLL (what client of mine doesn't?) in SxS directories (side by side) and also released with Sonic's RecordNow which shipped with their Dell machines.
Having read and read and read on the topic and seen the question voiced as to whether having vulerable versions of the DLL on your machine is dangerous, and seeing no answer posted, I have to assume that it IS dangerous to have any vulnerable DLL present anywhere on the system. I'd feel better if Microsoft's little "you may be vulnerable" tool would tell me "you're not vulnerable" or failing that, that no red lines appear on GDIscan.
I have an idea as to how one might deal with this on an automated basis but I find myself wondering whether it's really a great idea. So I thought I'd post the idea and see what you guys think.
Several messages here have provided links to the GDI scan tool, and I saw that there were two versions, one for the command line and one GUI.
Why not write a series of batch files or even a compiled program (Preferably compiled in something that doesn't require distribution of Microsoft DLLs ) that could be placed in a login script, which would take the following steps:
1) Use the command line GDI-scan tool to create a list of DLLs;
2) Use a grep-like utility to find the lines and therefore the local paths of those vulnerable files;
3a) Rename, mangle, zip, erase, or otherwise disable those files, or;
3b) Replace those files with the Microsoft-supplied replacement for GDIplus.DLL;
4) (I assume this is a good idea but haven't investigated how - I remember something about a register command) de-register the old DLL and re-register the new;
5) Re-run the scan to a text file;
6) Create a report of activity on some shared drive or send it somewhere so as administrator, you can review what was done on all machines and alert users as to possible problems with apps that require the DLL.
7) Wait for whatever breaks to break, as opposed to waiting for whatever random attack from whoever might somehow get a foothold.
My client is a law firm and just doesn't care about Sonic RecordNow, and probably doesn't care about whatever software caused the old DLL to be placed in WinSxS. But, even if one of these apps were in use, a replacement or upgrade could be procured or an intelligent and timely decision could be made about what to do to solve the problem.
So... what do you guys think?