MD5s of Unofficial patches and other mistakes
Now that the official patch is out, I feel better about wondering
a few things in public.
The unofficial patch from Ilfak Guilfanov was a great service, I think.
I did not apply it. I got too paranoid, for good reason. People who
should have known better did a lot of questionable things....
1. Intense, breathless coverage of how new and bad
and quickly expoited a newly disclosed vector is, and how
you MUST CERTAINLY DO SOMETHING FAST, makes me careful. (Not that
I am not careful otherwise, but I tend to make mistakes when
rushed. Anyone else like that?)
2. When a really clever patch appears by someone I never heard
of, AND it is touted as the best "must apply", I get paranoid....Especially
when unregistering the Windows Picture and Fax DLL seemed so reasonable
a work-around to reduce my exposure surface.
3. When I saw the source code, which works patching a DLL at run-time based
on opcode pattern matching including WILDMAT, I start to think about how many
different versions of DLLs there are and how could anyone have possibly been
sure that the sequence works only as it was documented, and not any other
way on every DLL?
It would take a lot of work to determine that, and I expect that anyone making
the claim would have a paper-trail of documentation to go along with the
statement of "We have reviewed it and verified it works as intended, trust us."
4. Then the originators website gets slashdotted. Understandable,
but that detaches the originator's claims of white-hatness from
the mirroring sites claims of fidelity to the originator's code.
5. I'm offered an MD5 from the SAME distributing site (SANS ISC) that serves the
patch installer.
Sorry, that's SOOO unprofessional, both because it is an MD5 which is
a mickey mouse hash, it's 2005 you know, and because you can't trust
an MD5 from the same site as you get the package.
The fact that "professionals" were asking me to accept both of
those fallacies condemns their choice of methods, even if their intents
were honest and good.
6. OK, I don't have to trust MD5, because there is a detached PGP sig!
The problem is it is using a group-owned key, a key which is not in the MIT
keyserver, even though previous versions of the SANS ISC key are.
(NOTE: the MIT key server has the 0x9C0EC441 key now, but it did not when
I looked before.)
The OLD (0x9B0E6F13) AND NEW isc@xxxxxxxx keys on the mit keyserver have NO
external signatures (as reported by the MIT key server.) (All the signatures
are also @sans.org.)
I'm way paranoid now. Knowing how small my exposure surface is after
unregistering the DLL, I'll wait a week, which wasn't a week anyway.
OK, a few simple things I expect Security Professionals to do better next time,
and they are easy and simple.
1 - MD5 collisions are easy to generate now. Don't offer them as assurance
of integrity. They aren't, so it makes you look foolish. SHA-1 is
probably also not a good choice.
2 - Use trustable keys.
If you want to sign with a group key, sign with your personal keys
too. Sign with previous versions of unrevoked keys if possible.
Use a key available on a public key server. Sign new keys with
previous keys (at least SANS ISC did do that.)
Sign something that is offered for however many windows users
signed with 1024 bit keys? What's wrong with larger keys for
something so important?
(Probably some other key management things here too, since that
isn't my area of expertise.)
3 - If you make statements like "we verified the patch does what it is
supposed to" then PGP sign the notes you made when doing the analysis,
and publish the notes along with your statement of "trust us."
Then the community can verify your statement and thoroughness.
Other than that, Way to go Team. I felt pretty in control of my
options on this one, and got enough information from BugTraq to
ignore the breathless main stream media coverage and do something
safe and sane.
Forrest J Cavalier III
Mib Software