Message-ID: <4E7EDCCEED544CCE95D5D58A24494349@acros.si>
Date: Mon, 17 Jun 2013 15:51:56 +0200
From: "ACROS Security Lists" <lists@...os.si>
To: <Valdis.Kletnieks@...edu>, "'Defence in Depth'" <defenceindepth@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Microsoft Outlook Vulnerability: S/MIME
	Lossof Integrity


Good points, Valdis, but I think we know how to do this right: an
invalid/untrusted/unmatching certificate is not a cause for user-waivable warning but
for a fatal you-shall-not-pass error. By allowing users to even go past the warning
we're nurturing the automation of okaying such warning as well as (I've seen this too
many times) the development of HTTPS web sites with untrusted certs that ask their
users to download and install a root CA cert to remove the warning - and do so over
HTTP.

As much as it would hurt developers who want to get things running by yesterday and
admins who can't find time or money for installing certs that our devices would
trust, the only long-term solution for this is to: (1) not let the user see an HTTPS
website with an incorrect certificate and (2) not let the recipient see an email
signed using an incorrect certificate. This would encourage those building web sites
and those sending email to configure things properly.

We're just being too kind when it comes to security: we can either have security and
be real nit-picky about it or have something that only looks like security but really
just wastes people's time while allowing attackers to easily social-engineer their
way around it.

Cheers,
Mitja

> -----Original Message-----
> From: Full-Disclosure 
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf 
> Of Valdis.Kletnieks@...edu
> Sent: Monday, June 17, 2013 2:53 PM
> To: Defence in Depth
> Cc: full-disclosure@...ts.grok.org.uk
> Subject: Re: [Full-disclosure] Microsoft Outlook 
> Vulnerability: S/MIME Lossof 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.
> 
> 

_______________________________________________
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