> what stops them from generating a new SHA-1 or MD5 hash? The hash is communicated through a different channel. If somebody forges Microsoft's announcement message or intercepts and changes it during delivery (omnipotent MITM) then a fake hash can be planted as you suggest. However, the omnipotent MITM is far less likely than the DNS hijacking/spoofing/poisoning MITM. The latter can only do harm to outbound requests; inbound traffic doesn't pass through the hands of the DNS hijacker. Consider also that in the real world people have friends. Friends also receive announcements from Microsoft. With hashes friends can cross-check against each other, whereas this is not practical with signatures. The only way a malicious attacker could fool everyone is to send forged communications on a large scale that fools even Microsoft into believing that the forged message was in fact authentic. If Microsoft fails to monitor, from an outside vantage point, the communications that appear to be originating from its corporate identity, then this too is a severe vulnerability; one that we can be certain somebody will exploit successfully. > While hashes can verify the integrity of a file, it doesn't do anything > to verify the authenticity of a file. That can only be done through a > signature. Signatures do not accomplish authenticity verification. The very definition of authenticity refers back to my previous paragraph: did Microsoft really send out the e-mail announcement that caused you to click the supplied hyperlink? You have no way to know. Suppose you rely on signatures attached to e-mail and there are no bugs in the software that produces and verifies these signatures. How do you know that Microsoft really sent the signed e-mail? You have no way to know. It is possible that a malicious attacker gained access to the computer on which Microsoft's digitally-signed communications originate. Even without access to Microsoft's private key per se, such attacker could send a perfectly convincing digitally signed message with instructions that you would have no reason not to follow. The protection you get from the fact that a community of your peers and friends also receive the same communication from Microsoft, and the protection you get from the presumption that Microsoft knows when they send out communications so that they could detect unauthorized transmissions, combined with the community-based incident response in the event of forged or unauthorized signed communications together represent the true security in this whole scenario. The security is NOT based on technology, but on common sense and intelligent, informed, alert people who are aware of the potential risks. Microsoft and other vendors have convinced you that digital signatures eliminate risks, and this is an outright lie that results in the elimination of our only real defenses. If Microsoft really does monitor the communications that appear to originate from its mouth(s) and they have a master list of authentic communications, why on earth won't they share that list with the public? It would look a heck of a lot like a list of authentic hashes of known-good authentic communications (and code) that Microsoft believes they originated on purpose. A secure channel (not foolproof-secure, simply secure-by-a-different-dependency) giving you access to Microsoft's master list of authentic hashes (a Web site employing SSL, for instance) would be extremely valuable to the ultimate goal of proving authenticity. It would also rely on a non-technical mechanism for its operation: human literacy. > In a perfect world, MS would make their white papers available in an > widely adopted standard like PDF or PS files, and sign them To "sign them" Microsoft would presumably utilize their own Portable Executable file format to attach signature data as they do presently. Unfortunately, PDF and PS files are not PE's thus they cannot be signed in this manner. It would appear that one of the reasons Microsoft distributes executables rather than PDF and PS files is that they have not built any non-PE mechanism for managing signatures applied to files. Distributing a block of signature data separate from the signed file poses the very same circular logic problem you point out regarding authentic hashes. Sincerely, Jason Coombs jasonc@science.org -----Original Message----- From: Frank Knobbe [mailto:fknobbe@knobbeits.com] Sent: Monday, April 28, 2003 7:53 PM To: jasonc@science.org Cc: bugtraq@securityfocus.com Subject: RE: Windows Server 2003 Security Guide available On Fri, 2003-04-25 at 16:27, Jason Coombs wrote: > [...] > For every .exe that Microsoft distributes, it should consider publishing a > known good full-file hash code so that a hash verification tool of the user's > choice can be used, on a platform of the user's choice, to verify that the > file received over the network is the file they expected -- BEFORE attempting > to use a tool like Windows Explorer to read structured information such as > digital signature data out of the PE file's header sections. > [...] Jason, I'm not sure how much a file hash will do to alleviate your concern about MITM attacks. If for example MS web site gets hijacked, or somehow else someone is able to replace the downloadable files, what stops them from generating a new SHA-1 or MD5 hash? While hashes can verify the integrity of a file, it doesn't do anything to verify the authenticity of a file. That can only be done through a signature. Of course that requires you to actually trust such a signature/signer and trust in the method of verifying these signatures. It sounds like you find flaws in the signature verification of Explorer. While I agree that is substandard (how many patches are unsigned, but people install them anyway?), I do believe that only signatures can correct the deficiency you outline. In a perfect world, MS would make their white papers available in an widely adopted standard like PDF or PS files, and sign them using PGP/GPG. But since this is not a perfect world, and we have to accept proprietary .doc files or OS dependent executables, why not use a sub optimal verification process? Regards, Frank
