> “However, you are still not convinced, so you call your manager to ensure that the email is legit. He confirms, so you transfer the money.”<p>I feel like it’s a HUGE (silly) assumption you’d ask generically “did you send this email” instead of something more specific like “do you REALLY want me to transfer you money like this?” to which the manager would obviously be confused and the attack would likely be killed in that conversation.<p>This is an interesting attack vector but I am questioning how likely it is to succeed. The article paints a very specific and narrow window of events for this attack to really work. I don’t buy it, personally.<p>EDIT: I know phishing happens and works. I am not saying it doesn't. I just mean the people that fall for phishing don't need this sophisticated of an attack to fall for. In fact, the attacker probably narrows the chance of success by putting this much extra (very specific) effort into the attack. They are likely to just succeed with their typical phishing email.
The other day I was discussing the design for an "update" email that our designer was putting together and showing me the size of this stupid graphical header he put at the top and I was showing him how with that you can't even see the text of the title of the email without scrolling down, and then he forwards some other version to me for more feedback and suddenly started getting all disturbed and upset because something looked different to him.. like the fonts were a bit smaller.. and then he said, oh no, when you forward it, it transforms it to the desktop version, instead of the mobile version! And I'm sitting there in disbelief, just staring at him, like,... this is EMAIL we're talking about, what do you <i>mean</i> "desktop" version and "mobile" version? How is that even a thing? What do you <i>mean</i> it "transforms" it? It's literally just copying it! The fact that it "breaks" when you do that is evidence of how <i>stupid</i> this is. My god man, why is CSS in my email <i>at all</i>?<p>The fact that we haven't adopted something much simpler to just be able to express italics or whatever, like markdown, is just bonkers to me. It just shows how little anyone cares about actually improving the situation. And all just to cater to the bizarre corporate need to put logos and banners everything. HTML email is just ridiculous.
I long argued that we should use markdown (without the inline HTML) or a similar simple text markup instead of HTML for rich text in emails. This would makes it easy for emails clients to decide about either showing the text as rich text or just plain text, while supporting most of the formatting that a normal user might need: bold, italic, quotes, inline images, code blocks, headers, ...<p>Sure it wouldn't be good for marketing emails with the super advanced HTML but I don't think anyone should care about this use-case.
The real risk to your organisation is that the developer you assign to generate HTML emails will go mad, lock themselves in the server room and destroy all the hardware while screaming “why is Outlook rendering DIFFERENT”<p>(Seriously though, this is a fascinating exploit)
Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags? To improve usability, email clients could include an automatic step where all Stylesheets are “compiled” to inline styles.
The only thing this would break would be advanced CSS selectors (hover etc.) but I’m not sure they would be needed.
This is really clever!<p>Premise: CSS in HTML email allows some text to be visible only after the message is forwarded. This is a huge threat to the trustworthiness of verified email! Examples given in Thunderbird, Outlook, Gmail. Excellent work.<p>I read all mail in mutt, so this is officially "someone else's problem".<p>...<p>Consequently, I'll complain about something else:<p>> <i>This issue was reported to Mozilla on 05.03.2024. The planned release date and a draft of the following section were communicated to Mozilla on 20.03.2024.</i><p>I agree that little-endian dates make more sense than US-style middle-endian dates.<p>But I will assert that any technologist who does not use ISO 8601 date formatting (2024-03-05, with or without hyphens), is <i>doing it wrong</i>. :)
I see that some of the email clients mentioned wrap the mail’s content in extra HTML tags and modify the CSS and classes names. I’m wondering why email clients don’t use sandboxed iframes to render HTML email? Do they still present security risks?
A classic cut off the limb to fix the cut solution. The problem is bad standardization for email that has allowed hacks like this to rule the day.<p>HTML in general is susceptible to these very concerns. Plenty of emails exist that use HTML without incident. This reads as one user’s frustration with something in the wild that is dressed as a security issue.
Some possible mitigations from the top of my head (maybe ineffective):<p>- warn prominently on hidden elements<p>- randomize the number of enclosing div, on both incoming and outgoing<p>- compute what the forwarded message would look like on forwarding, ask for confirmation if differs significantly. Or do the opposite (probably more effective since doesn't require other clients to help)
When efail came out, I wrote a blogpost about the security risks of HTML mail.<p>It is really amazing how problematic all of this is, despite its widespread use. The HTML mail spec is really old, and contains almost no security considerations.<p>HTML in emails can only be a subset of HTML to be secure. But nobody has ever defined what exactly that subset is, so everyone does whatever they think. And unsurprisingly, this leads to an endless stream of security flaws.<p>See:
<a href="https://blog.hboeck.de/archives/894-Efail-HTML-Mails-have-no-Security-Concept-and-are-to-blame.html" rel="nofollow">https://blog.hboeck.de/archives/894-Efail-HTML-Mails-have-no...</a>
>...it may even be cryptographically signed ...<p>In general, anything you are going to sign has to be in a simple enough format to make it so that the sender and the receiver(s) can actually determine what is signed. HTML should automatically be considered unsigned. It simply is not suitable for the purpose.
HTML in email shouldn't be as big of a nightmare as it is. It really comes down to rendering engines. If all email clients just checked for text vs HTML and when HTML switched the rendering engine to Webkit, this problem could be solved overnight.<p>There's zero reason why you can't render an email the same way you can as a regular page (minus JavaScript).<p>Out of curiosity, is anybody working on this? It seems like a standard could be produced w/ relative ease to make it easier on vendors. Imagine somebody has at least proposed the idea before...
> the position of the original email in the DOM usually changes, allowing for CSS rules to be selectively applied only when an email has been forwarded.<p>oh, that's sneaky. Would "plain" old rtf have been a better choice for formatted emails since that CSS complexity isn't much needed outside of spam marketing :) Why has that been surpassed by HTML&CSS
Don't let me start on phishing SMS texts... still around and strong. My phone will fireup a non-big-tech noscript/basic (x)html browser if I mistakenly click on an URL in it <i>AND</i> my phone does not run android (or an other linux based phone OS) nor iOS.
this highlights a broader issue of irreproducible content.<p>Another good example are group chats where some recipients see messages inconsistently or in a different order than others. It can happen due to inconsistent delivery, inconsistent ACLs, or other reasons.<p>How can people agree on things when they are not looking at the same thing? And people assume that everyone sees what they see by default.<p>Can a board make a decision when not everyone has the same presentation of facts?<p>Remember when you judged someone for asking a stupid question when the answer was just posted a moment ago? How do you know they even received it?
Between these sorts of email tricks and ability to easily voice clone using ai, it would seem that invoicing systems should put some sort of 2 factor approval/confirmation into the workflow for payouts.
<p><pre><code> If we style the kobold letter as an overlay, we can not only affect the forwarded email, but also (for example) replace any comments your manager might have had on the original mail, opening up even more opportunities for phishing.
</code></pre>
clever doesn't even begin to adequately describe.<p>tangentially and anecdotally, it's only occurred to me fairly recently, like within the past year or so, to configure all my mail clients, including both desktop and mobile Outlook (<i>and</i> OWA), to <i>not</i> 'automatically download new messages'. this really needs be the default setting.
See also: The Spammers' Compendium: <a href="https://www.virusbulletin.com/resources/spammerscompendium/" rel="nofollow">https://www.virusbulletin.com/resources/spammerscompendium/</a>
> To prevent the CSS of emails to affect the style of the webmailer, Outlook modifies the email by prefixing all ids and classes with x_ and adjust the CSS accordingly.<p>Wait what, OWA <i>loads emails directly into the same DOM tree as the rest of the app</i> instead of an iFrame?