The short version of this blog post: If you rely on using S/MIME in MailMate then make sure you have updated to version 1.13.2 (or later).

It has been quite a while since MailMate had a public update (December, 2019). This is kind of a good thing, because the reason is that I’ve been working hard on replacing some parts of MailMate which were long overdue for a replacement. Most importantly, I’m working on replacing the part of MailMate used to display emails. Since the first release of MailMate, this has been handled by a single interface element displaying a single HTML document. Originally, this seemed like a good idea, but over the years it became apparent that it’s a horrible idea with all sorts of problems — including security issues. The new message view is going to be both safer and far more flexible, but it’s not ready for a public release yet. When it’s ready I’ll write a blog post about the many ways it works differently from the old one.

The reason I’m releasing an update now is a security problem in version 1.13.1 (and some earlier releases). I strongly recommend all users of S/MIME to update as soon as possible. Now, if you follow security related email news then you might have seen this paper, but it’s actually not the reason for this security update. Nevertheless, I’ll be reviewing the issues described in the paper in a section below.

From my perspective as a developer, there are 2 basic types of security issues. There’s the smart ones where someone cleverly combines email software features to reveal that something that seemed to be safe behavior really isn’t. An advanced email client (like MailMate) is more likely to have such issues than a simple one, but I’m still somewhat embarrassed when I think I should have been more careful when implementing some specific feature. I learn every time and, for example, I’m constantly thinking about security related issues while implementing the new message view. The other type of security issue is what I can only phrase as “Sh*t-for-Brains” issues. That may seem like vulgar language, but nothing less can match the embarrassment felt when discovering such an issue. It’s the result of careless programming and a sad lack of proper testing.

The mailto: paper

As noted above then this paper is not the reason for the MailMate 1.13.2 update, but the paper does highlight some important issues and I’ll use this opportunity to go through them in relation to MailMate.

First of all, the paper does not state the version of MailMate used for the tests and the public release of MailMate does not behave exactly as described in the paper. The paper describes 3 issues labelled A1-A3:

  • A1: This one is about S/MIME certificates. By default, MailMate has never auto-added S/MIME certificates to the keychain, but there was a hidden preference to do it (version 1.9.7) and later it also got a GUI setting (version 1.11), but the latter happened after fixing the issue in MailMate. Auto-adding a certificate is, in particular, a problem when a certificate already exists in the keychain since it allows a MITM (Man-In-The-Middle) attack in which an existing certificate can be replaced without the user noticing. Subsequently encrypted emails would then quietly use this certificate.

  • A2: This is a MITM attack in which the attacker needs access to the IMAP account of the victim and the attacker needs the victim to click an “evil” mailto: link. The attack takes advantage of any email clients uploading incomplete drafts to the server. MailMate has not (for a very long time) uploaded drafts before the draft has been saved and the composer has been closed. MailMate is still vulnerable to the attack, but in practice the user should have time to realize if the draft contains anything unexpected after clicking an “evil” mailto: link. Nevertheless, version 1.13.2 explicitly ignores OpenPGP content in a mailto: link. In addition to this, MailMate no longer uploads drafts which are signed and/or encrypted. (If you do not want to upload drafts at all then you can explicitly take the Drafts mailbox offline in each of your accounts.)

  • A3: This is the worst issue described in the paper, but fortunately MailMate is and never has been vulnerable to this attack. (The attack uses an “evil” mailto: link to attach arbitrary files to a new message.)

The “Sh*it-for-Brains” issue

I cannot share the details of this issue yet (users need time to update), but it’s the kind of issue that makes me think that I have “Sh*t-for-Brains” and maybe it was better if MailMate didn’t support S/MIME and OpenPGP at all (this particular issue only affects S/MIME). Ironically, this issue was introduced while I was working on the A1 issue described above.

If you use S/MIME in MailMate then please update to version 1.13.2 as soon as possible.

A special thank you to Heike Knobbe for making me aware of this issue! The only thing worse than discovering this type of issue in MailMate is not knowing when such an issue exists.

Big Sur

Completely unrelated, this security release also includes a fix which should make MailMate run on macOS Big Sur.