4 ms·
This is one of the biggest false assumptions that I see smart people making. Unless you have verified the implementation under the hood, you have no knowledge t
by dsl 13y ago
This is one of the biggest false assumptions that I see smart people making. Unless you have verified the implementation under the hood, you have no knowledge that the parser and renderer are not being executed on a rich text part regardless of what is displayed on the screen.
- bananas 13y agoUnless it's multi-part MIME which is usually the encapsulation mode for RTF based email. In that case, there's usually a plain text copy attached to the body as well which doesn't need to be read by the parser or any of the rich text stuff. Confirmed: Content-Type: multipart/alternative; boundary="_000_1B81DC42240AEE4B96F487A2683E7EEB0A6AE7505BTHHS2E12BE2Xh_" MIME-Version: 1.0 --_000_1B81DC42240AEE4B96F487A2683E7EEB0A6AE7505BTHHS2E12BE2Xh_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RTF test From outlook 2013 in RTF mode... And I use mutt for my personal email...
- Xylakant 13y agoIt's unlikely that an attacker uses a well-behaved email-client to attack you. The parent points out that you don't know what your client does if it receives a rich-text (HTML,...)-only email and you set your client to render it as plain text. Your client will probably use some sort of parser to tell the formatting from the content and remove the formatting. If that is the "regular" parser, you're still vulnerable.
- dsl 13y ago...and if the vulnerability is in the MIME parser itself?
- bananas 13y agoIt wouldn't be if the mitigation was to stop viewing RTF as it says on technet...