Message-ID: <134643.1371473607@turing-police.cc.vt.edu>
Date: Mon, 17 Jun 2013 08:53:27 -0400
From: Valdis.Kletnieks@...edu
To: Defence in Depth <defenceindepth@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Microsoft Outlook Vulnerability: S/MIME Loss
	of Integrity

On Sun, 16 Jun 2013 00:51:10 +0930, Defence in Depth said:

> Microsoft Outlook (all versions) suffers from an S/MIME loss of integrity
> issue.
> Outlook does not warn against a digitally signed MIME message whose X509
> EmailAddress attribute does not match the mail's "From" address.

Congrats on the technical side, for spotting this.

On the flip side, there are a number of cases where the signer address
legitimately does not match the From: address. For instance - if the signer is
listed in Sender: instead of From:, if it has passed through a mailing list
that rewrites the From: line, or some combinations of resends and forwards. And
yes, a lot of this sort of crap is only semi-legit because it's coming from
misconfigured servers - but operational reality dictates that you have to
deal with the fact that there's a *lot* of  (And we'll overlook the additional
fun and games available due to the distinction between an RFC821 MAIL FROM:
and and RFC822 From: line).

I suppose it could be worse - it's been a few years since I last saw a %-hacked
address in an e-mail.

A few operational notes regarding alerts in user-facing software:

1) A lot of browsers used to display broken padlocks when SSL failed. They
don't do this anymore because users *will not* look at that sort of subtle
warning.

2)  They'll look at a big pop-up that obstructs their view - but only if it
happens so rarely that they have to call somebody and ask "wtf is this?". If it
becomes a "oh it does this once every week or two" click-through, it's now
become "worse than useless".

As you noted, most browsers will notify the user if the browser detects a CN
mismatch.

What you gloss over is that browsers *totally suck* at presenting that warning
in a way that is both understandable and actionable to a general user. Just
yesterday I had Firefox alert on a SLL certificate mismatch, and it gave me the
helpful info that the certificate presented was only valid for *.akamai.net.
Now, *I* know exactly what happened there, and *you* know, and the guy who
pushed some content to Akamai without looking to see if there were https: links
pointing at the content will go "D'Oh!" when he finds out - but if you're Joe
Sixpack and don't know if Akamai is a box in your ISP's server room or a box in
a server roomin the Ukraine, you got nothing.  And if you get enough of these
totally annoying pop ups, you'll just learn to click through without thinking.

Bottom line:  yes, it would be nice if all this sort of stuff was more widely
deployed and enforced.  But given that we've tried this with dismal results
with Windows UAC alerts, firewall alerts, browser alerts, and A/V alerts,
there's no real reason to expect that *this* time we'll actually get it right
for MUA alerts.

Bonus points for the most creative suggestion for how to leverage a *fake*
From:/signature mismatch alert into a compromise (a la fake AV alerts that get
you to download actual malware).

Really - Outlook may do this wrong, but I don't think we as an industry have
a frikking clue how to actually do this right.


Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists