Subject: [Jmap] HTML email security considerations

From: Neil Jenkins <[email-masked]>
Date: Mon, 09 Apr 2018 11:26:37 +1000

This is an important security consideration for client vendors, and
getting this right may help vendors avoid various security pitfalls in
the future, so it would be good to have a few eyeballs to check I've
covered the essential points in sufficient detail. I've created a pull
request[1] for review, content copied below for convenience.
------
HTML message bodies provide richer formatting for emails but present a
number of security challenges especially when embedded in a webmail
context in combination with interface HTML. Clients that render HTML
email should make careful consideration of the potential risks,
including:

 * If JavaScript is allowed to execute it can rewrite email to change
   its content on subsequent opening, allowing users to be mislead. In
   webmail systems it can access and exfiltrate all user content
   accessible via the browser, including all other emails and
   potentially contacts, calendar events, settings, and login
   credentials. It can also rewrite the interface to undetectably phish
   passwords.
 * HTML documents may load content directly from the internet, rather
   than just referencing attached resources. For example you may have
   an <img> tag with an external src attribute. This may leak to the
   sender when a message is opened, as well as the IP address of the
   recipient. Cookies may also be sent and set by the server, allowing
   tracking between different emails and even website visits and
   advertising profiles.
 * In webmail systems, CSS can break the layout or create phishing
   vulnerabilities. For example, the use of position:fixed can allow an
   email to draw content outside of its normal bounds, potentially
   clickjacking a real interface element.
 * If not inside a separate frame in a webmail context, any styles
   defined in CSS rules will apply to interface elements as well if the
   selector matches, allowing the interace to be modified. Similarly,
   any interface styles that match elements in the email will alter
   their appearance, potentially breaking the layout of the email.
 * The link text in HTML has no neccessary correlation with the actual
   target of the link, which can be used to make phishing attacks more
   convincing.
 * Links opened from an email may leak private info in the Referer
   header sent by default in most systems.Sanitizing HTML to mitigate these issues is tricky. Using a well-tested
library with a carefully vetted whitelist-only approach is the safest
way to avoid vulnerabilities. New features with unexpected security
characteristics may be added to HTML rendering engines in the future; a
blacklist approach is likely to result in security issues.A defence in depth approach can help to mitigate the risks of HTML
email. Webmail systems are strongly encouraged to use a strong Content
Security Policy[2] as a second line of defence to block malicious
content should it manage to evade the filter.Subtle differences in parsing of HTML can introduce security flaws: to
filter with 100% accurately you need to use the same parser when
sanitizing that the HTML rendering engine will use.As highly complex software components, HTML rendering engines increase
the attack surface of a client considerably, especially when being used
to process untrusted, potentially malicious content. Serious bugs have
been found in image decoders, JavaScript engines and HTML parsers in the
past, which could lead to full system compromise. Clients using an
engine should ensure they get the latest version and continue to
incorporate any security patches released by the vendor.

Links:

  1. https://github.com/jmapio/jmap/pull/197
  2. https://www.w3.org/TR/CSP3/

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 Apr 2018 11:30:35 +1000

> On 9 Apr 2018, at 11:26 am, Neil Jenkins <[email-masked]> wrote:
> 
> This is an important security consideration for client vendors, and getting this right may help vendors avoid various security pitfalls in the future, so it would be good to have a few eyeballs to check I've covered the essential points in sufficient detail. I've created a pull request for review, content copied below for convenience.
> 
> ------
> HTML message bodies provide richer formatting for emails but present a number of security challenges especially when embedded in a webmail context in combination with interface HTML. Clients that render HTML email should make careful consideration of the potential risks, including:
> 
> 	• If JavaScript is allowed to execute it can rewrite email to change its content on subsequent opening, allowing users to be mislead. In webmail systems it can access and exfiltrate all user content accessible via the browser, including all other emails and potentially contacts, calendar events, settings, and login credentials. It can also rewrite the interface to undetectably phish passwords.
> 	• HTML documents may load content directly from the internet, rather than just referencing attached resources. For example you may have an <img> tag with an external srcattribute. This may leak to the sender when a message is opened, as well as the IP address of the recipient. Cookies may also be sent and set by the server, allowing tracking between different emails and even website visits and advertising profiles.
> 	• In webmail systems, CSS can break the layout or create phishing vulnerabilities. For example, the use of position:fixed can allow an email to draw content outside of its normal bounds, potentially clickjacking a real interface element.
> 	• If not inside a separate frame in a webmail context, any styles defined in CSS rules will apply to interface elements as well if the selector matches, allowing the interace to be modified. Similarly, any interface styles that match elements in the email will alter their appearance, potentially breaking the layout of the email.
> 	• The link text in HTML has no neccessary correlation with the actual target of the link, which can be used to make phishing attacks more convincing.
> 	• Links opened from an email may leak private info in the Referer header sent by default in most systems.
> Sanitizing HTML to mitigate these issues is tricky. Using a well-tested library with a carefully vetted whitelist-only approach is the safest way to avoid vulnerabilities. New features with unexpected security characteristics may be added to HTML rendering engines in the future; a blacklist approach is likely to result in security issues.
> 

You might want to refer to 
  https://www.w3.org/TR/referrer-policy/

> A defence in depth approach can help to mitigate the risks of HTML email. Webmail systems are strongly encouraged to use a strong Content Security Policy as a second line of defence to block malicious content should it manage to evade the filter.
> 
> Subtle differences in parsing of HTML can introduce security flaws: to filter with 100% accurately you need to use the same parser when sanitizing that the HTML rendering engine will use.
> 
> As highly complex software components, HTML rendering engines increase the attack surface of a client considerably, especially when being used to process untrusted, potentially malicious content. Serious bugs have been found in image decoders, JavaScript engines and HTML parsers in the past, which could lead to full system compromise. Clients using an engine should ensure they get the latest version and continue to incorporate any security patches released by the vendor.

It might also be worthwhile to ping the W3C WebAppSec WG for a review:
  https://www.w3.org/2011/webappsec/

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 09 Apr 2018 11:53:32 +1000

On Mon, 9 Apr 2018, at 11:30 AM, Mark Nottingham wrote:
> You might want to refer to https://www.w3.org/TR/referrer-policy/

Yes, good idea. I've now added this as a mitigation for referrer
leakage.
> It might also be worthwhile to ping the W3C WebAppSec WG for a review:>   https://www.w3.org/2011/webappsec/

Thanks, have done.

Cheers,
Neil.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Apr 2018 12:19:01 +1000

> If JavaScript is allowed to execute it can rewrite email to change its content on subsequent opening, allowing users to be mislead. In webmail systems it can access and exfiltrate all user content accessible via the browser, including all other emails and potentially contacts, calendar events, settings, and login credentials. It can also rewrite the interface to undetectably phish passwords.

The point here is that a webmail system might render HTML in its own
origin, which will mean that JS will run in that origin.  As you say,
that's a complete compromise of all state available to the webmail
system and gives the attacker all capabilities not explicitly disabled
by a CSP (which - given typical webmail client capabilities, won't
exclude much).  You would point out that a compromise like this is
likely persistent: get pwned once and that pwnage can be persistent.

A webmail system doesn't have to render HTML in its own origin, which
is actually a great defense.  But that could limit what it can do.  It
might also have other costs related to the use of other origins.

p.s., Old man observation: my spellchecker doesn't object to "pwned"
as a word.  What a world we live in.

On Mon, Apr 9, 2018 at 11:26 AM, Neil Jenkins <[email-masked]> wrote:
> This is an important security consideration for client vendors, and getting
> this right may help vendors avoid various security pitfalls in the future,
> so it would be good to have a few eyeballs to check I've covered the
> essential points in sufficient detail. I've created a pull request for
> review, content copied below for convenience.
>
> ------
>
> number of security challenges especially when embedded in a webmail context
> in combination with interface HTML. Clients that render HTML email should
> make careful consideration of the potential risks, including:
>
> If JavaScript is allowed to execute it can rewrite email to change its
> content on subsequent opening, allowing users to be mislead. In webmail
> systems it can access and exfiltrate all user content accessible via the
> browser, including all other emails and potentially contacts, calendar
> events, settings, and login credentials. It can also rewrite the interface
> to undetectably phish passwords.
> HTML documents may load content directly from the internet, rather than just
> referencing attached resources. For example you may have an <img> tag with
> an external src attribute. This may leak to the sender when a message is
> opened, as well as the IP address of the recipient. Cookies may also be sent
> and set by the server, allowing tracking between different emails and even
> website visits and advertising profiles.
> In webmail systems, CSS can break the layout or create phishing
> vulnerabilities. For example, the use of position:fixed can allow an email
> to draw content outside of its normal bounds, potentially clickjacking a
> real interface element.
> If not inside a separate frame in a webmail context, any styles defined in
> CSS rules will apply to interface elements as well if the selector matches,
> allowing the interace to be modified. Similarly, any interface styles that
> match elements in the email will alter their appearance, potentially
> breaking the layout of the email.
> The link text in HTML has no neccessary correlation with the actual target
> of the link, which can be used to make phishing attacks more convincing.
> Links opened from an email may leak private info in the Referer header sent
> by default in most systems.
>
> Sanitizing HTML to mitigate these issues is tricky. Using a well-tested
> library with a carefully vetted whitelist-only approach is the safest way to
> avoid vulnerabilities. New features with unexpected security characteristics
> may be added to HTML rendering engines in the future; a blacklist approach
> is likely to result in security issues.
>
> A defence in depth approach can help to mitigate the risks of HTML email.
> Webmail systems are strongly encouraged to use a strong Content Security
> Policy as a second line of defence to block malicious content should it
> manage to evade the filter.
>
> Subtle differences in parsing of HTML can introduce security flaws: to
> filter with 100% accurately you need to use the same parser when sanitizing
> that the HTML rendering engine will use.
>
> As highly complex software components, HTML rendering engines increase the
> attack surface of a client considerably, especially when being used to
> process untrusted, potentially malicious content. Serious bugs have been
> found in image decoders, JavaScript engines and HTML parsers in the past,
> which could lead to full system compromise. Clients using an engine should
> ensure they get the latest version and continue to incorporate any security
> patches released by the vendor.
>
>
>
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap
>

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 09 Apr 2018 15:35:54 +1000

On Mon, 9 Apr 2018, at 12:19 PM, Martin Thomson wrote:
> origin, which will mean that JS will run in that origin.
>  … 
> You would point out that a compromise like this is likely persistent

Good points. I've updated this paragraph to the following:

*If JavaScript is allowed to execute it can rewrite email to change its
content on subsequent opening, allowing users to be mislead. In webmail
systems, if run in the same origin as the interface it can access and
exfiltrate all user content accessible via the browser, including all
other emails and potentially contacts, calendar events, settings, and
credentials. It can also rewrite the interface to undetectably phish
passwords. A compromise is likely to be persistent, not just for the
duration of page load, due to exfiltration of session credentials or
installation of a service worker that can intercept all subsequent
network requests (this however would only be possible if blob downloads
are also available on the same origin, and the service worker script is
attached to the message).*
Neil.