[kmail2] [Bug 359425] New: CSS from HTML mail interfers with header layout

[Dominik George via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359425

            Bug ID: 359425
           Summary: CSS from HTML mail interfers with header layout
           Product: kmail2
           Version: 4.14.10
          Platform: Debian unstable
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: UI
          Assignee: kdepim-bugs at kde.org
          Reporter: nik at naturalnet.de

I just saw an HTML message that style html and body interfer with the
message headers (in that case, the message heraders got centered along
with the rest of the message).

On first glance, this is a cosmetic issue. On second thought, it is
imaginable that this can be abused to hide or inject information into
the headers, thus easing phishing or scamming or even tricking the user
into assuming a different sender, replying with confidential
information.

I am not certain that the latter will actually work; if you agree with
my thoughts, please take the relevant steps to make this a security bug.



Reproducible: Always

Steps to Reproduce:
The attached mail completely replaces the default header view in KMail.

Of course, most of this can be done by simply spoofing e-mail addresses as 
well, or even better. I still see a minor attack vector bcause it might be 
possible to bypass spam checks by sending mail from a valid address. The 
default list view of messages in KMail only displays the sender's full name, 
so injecting a name of a trusted sender together with a valid e-mail address 
may ease forging the message quite a bit, because I can use any old freemail 
provider for that and my change will go unnoticed (see attached example 
message). I can even use corporate mail infrastructure that normally does 
sender checks, because noone really tries to authenticate senders' full names.

So what do I get from that?

 1. The recipient sees my injected full name in the email list and does not 
find anything suspicious.

 2. The recipient opens the message, gets the correct headers along with the 
HTML mail warning.

 3. Here is a short instance where the recipient might catch the wrong sender 
address.

 4. If they don't and accept the HTML warning, the headers are replaced, and 
we're done.

As you can see, there actually *is* an easy way to catch this as a recipient. 
I cannot say how many users would actually notice, and one could even say it's 
their fault for not being cautious enough, but then again, we all know how 
humans work, so it shouldn't be so easy to manipulate the message view.

-- 
You are receiving this mail because:
You are the assignee for the bug.