Date: Mon, 28 Apr 2003 21:49:59 -1000
From: "Jason Coombs" <jasonc@...ence.org>
To: "Frank Knobbe" <fknobbe@...bbeits.com>
Subject: RE: Windows Server 2003 Security Guide available


> 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@...ence.org

-----Original Message-----
From: Frank Knobbe [mailto:fknobbe@...bbeits.com]
Sent: Monday, April 28, 2003 7:53 PM
To: jasonc@...ence.org
Cc: bugtraq@...urityfocus.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

Powered by blists - more mailing lists