286960 - Address spoofing trick using messages with multiple From: headers

Status: NEW

(Thunderbird :: Security, defect)

Description

[Thomas Henlich]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Thunderbird 1.0 (20041206)

With a (specially crafted) e-mail message containing two or more From: headers,

1. in message listing window the last From: header is displayed
2. In TB mail filtering rules only the last From: header is used
3. In message preview and message window (with "normal" headers view activated)
the FIRST From: header is displayed

This can lead to all sorts of address spoofing, e.g. bypassing of TB filters or
making a user open messages which show a familiar From: address.

Reproducible: Always

Steps to Reproduce:
1. Create a file like this:
================
From - Sun Mar 20 12:39:26 2005
From: [e-mail]
From: [e-mail]

Must see! Buy now!
================

2. Open this file as mailbox
3. Setup a filtering rule like this: "From: contains 'spammer'"
4. Test this filter

Actual Results:  
In message listing, sender shows as "[e-mail]"

In message window and preview, sender shows as "[e-mail]"

The message is not filtered according to rule "From: contains 'spammer'"


Expected Results:  
Displayed addresses in message listing, message window and preview should match.

Message filtering should work for multiple "From:" fields

Comment 1

[Thomas Henlich]

Confirmed this bug for:
Thunderbird Version 1.0.2 (20050317)

Comment 2

[Thomas Henlich]

Attachment: Testcase using S/MIME signature

When you hit REPLY, you are NOT replying to the address that's displayed (and
that is in the certificate). That makes this bug even worse.

Comment 3

[Daniel Veditz [:dveditz]]

Confirming that there is some confusion about which "From" header to use (does
the spec say? We should at least be consistent), but I don't think this needs
the security confidential flag. There are lots of ways to spoof.

For unsigned mail this is pretty pointless, if someone's trying to spoof they'd
just forge whatever they wanted to get past filters.

CC'ing Nelson and Bienvenu for an S/MIME opinion.

I'm not troubled that the reply goes somewhere other than the person who signed
it, the mail could do that just as easily with a Reply-To header. The difference
with signed mail is that if the reply goes off to the wrong person you can later
know just who set you up (assuming they've kept their cert secure).

At the point we show the "This is signed" icon we're showing the "from" address
we've validated the signature against. The fact that we might filter the mail
into a different folder based on the wrong from address *might* help a spoof if
you knew enough about the victim to know what filters they were likely to have.
And if the filtered identity said something really outrageous you'd think the
recipient would double check the From line, which at that point says the actual
signer.

Is it true that S/MIME only signs the contents? I know MTA's and MUA's munge and
add various headers so not many could be used, but I was surprised I could edit
the Subject line without invalidating the signature. Seems like you could really
stir up trouble by sending validly signed mail from someone like a boss with the
subject "You're fired!" or profanity, regardless of the non-matching content.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Dan, 
Yes, it's true that S/MIME only signs/encrypts the contents, not the headers.  
So, a MITM can change the From and Reply-To headers, and you (recipient) 
DON'T know who did that to you.  All you know is whose message was 
victimized in that way.  
IIRC, mozilla's S/MIME code (and I presume TB's also) will look for an email
address in the signature cert, and attempt to match it to the From address
(er, one of them) and will display an icon that reflects that the signature
is not known to be that of the alleged sender.  If you click on that icon,
you get a dialog box that explains that the email address in the signature
cert doesn't match the address in the header.  I think it displays both.
I'm not sure if TB does those things or not.  

In any case, the user can see the signature cert's subject name and that 
will tell him who wrote the message content.  That's probably what he 
really cares about.  

By altering the headers, an attacker might get a valid email to be treated
like spam, but that's a DOS attack, and any attacker who can alter the 
message in transit can presumably just discard it, so that's not much of 
an attack.  

I doubt that spammers are going to send signed messages with faked headers
to get you to read them.  But they might, if they could get falsified 
certs from some low assurance CA.  That's an issue for consideration in the
trusted CA policy debate.

Comment 5

[timeless]

i intend to declassify this bug the next time i see it. nelson didn't object, bienvenu had well over a year, and other than being consistent about which from field to use, i don't see much of a security bug here, clearly S/MIME was designed not to sign headers and was ok with them being changed.

Comment 6

[timeless]

well dveditz got back to me sooner, so here i am. bug meet sunshine.