Hi MailMate users,
most mailing list readers probably missed this, but a couple of months
ago I wrote something on the list which deserves a follow-up.
On 3 Apr 2024, at 15:27, Benny Kjær Nielsen wrote:
[...] When I get back, the main priority will be to look into a
potential future Gmail issue. The “kill switch” I mentioned in an
old blog post might be looming around the corner:
https://blog.freron.com/2015/is-oauth2-support-a-good-thing/
Almost half a year ago I got a message from Google informing me that
they needed me to do some additional verification steps in order for
MailMate users to be able to continue to use Gmail. They told me that I
had 90 days to initiate the process -- this naturally meant I ignored it
for almost 60 days. When I finally initiated the process, I realized
that it would likely require more work than I had anticipated. It also
included a deadline:
“You are required to complete a CASA Tier 2 security assessment for
your application [...] by the following date: 2024-06-12. This
assessment is required annually; to learn more, please visit the CASA
website.”
Before going into what this means, I should tell you that I've completed
the assessment and MailMate went into the “verified” state a week
ago. This should make the MailMate/Gmail combination fairly safe for the
next year. To be more precise, the verification expires May 7th 2025.
Going forward, I will have to do this every year. This means that every
year there is a potential risk of MailMate no longer being able to
access Gmail accounts. Google might decide that some
feature/language/library used by MailMate is no longer considered safe,
or they might come up with some other requirement that I cannot easily
satisfy. This is a risk that I somehow need to make sure that users are
aware of before buying a license key. I'm still considering how to best
solve this problem.
The same, by the way, is true for any other desktop email client, but I
think it's fair to assume that many of them are “too big to fail”.
The rest of this email is for anyone wondering what the assessment is
all about and then some random thoughts on the subject. It's a brain
dump and probably a bit of a mess :)
---
So what is a CASA Tier 2 security assessment? It's mostly questions
which are irrelevant to MailMate (and probably most desktop email
clients) which means I've been clicking a lot of checkboxes on a
website. Most often the options are Yes, No, and Not Applicable.
Choosing the last option would trigger a discussion with an assessor
which would end with me either changing it to Yes or a note being added
to the item in the final “letter of validation”.
The most problematic part was a so-called static analysis of the source
code. This can be done in a number of ways, but the only one really
available to me was a “self scan” using an open source tool. I'll
skip the details, but let's just say that this doesn't really work well
for an application having code in C, C++, Objective C, Objective C++,
Javascript, Ruby, Python, Swift, Bash, and possibly more. Yes, it's a
complex app.
Scanning code for vulnerabilities is good and I could likely do more to
integrate that in my build process. I'm not questioning that.
Apple/Xcode/clang warns about insecure/deprecated APIs/functions in the
build process and I wouldn't mind if this was extended to also check for
known/likely vulnerabilities. Every release of MailMate is also scanned
by Apple (after compilation) as part of the so-called notarization
process although I think this is mostly about detecting intentionally
included malware. Nevertheless, this process is more “real” since I
cannot release an update which does not pass these checks. The CASA 2
assessment is based completely on good faith.
Other random thoughts on this subject:
* In relation to Gmail, the most sensitive part of talking to the server
is the OAuth2 authentication process. MailMate never sees the user
password because that is part of the process. The token used to gain
access is stored in Keychain Access (Apple).
* Ironically, the whole OAuth2 authentication process is handled by a
third party framework. This framework would need to be part of the code
scan described above. The framework (AppAuth) is provided by Google. I
would therefore be scanning Googles own code. What happens if that has
an issue ;)
* MailMate is an IMAP client and not a Gmail client. IMAP is how
MailMate talks to a huge number of different email servers with
different IMAP implementations. In theory, all of them could come up
with their own sets of requirements and assessment procedures. Will I
eventually be going through processes like this every year for every
email provider?
* Providing an app with IMAP access to an email account means that the
app gets total control of the emails in that account. No code
verification process is going to change that. The user has to trust
MailMate, and by extension, me.
That last point is interesting and I would be willing to look into ways
that I could strengthen this trust. Using “Little Snitch” is a good
way to monitor the behavior of an application like MailMate, but I can
think of ways that this would not detect “evil” email client
behavior.
It's also interesting what would have happened if I had failed to pass
the required assessment. Google writes:
“If you do not verify your app, your app will be subject to an
ongoing 100 user limit and your app’s consent screen will display
the unverified app user interface.”
The “unverified app user interface” would then show you this line:
“This app hasn't been verified by Google yet. Only proceed if you
know and trust the developer.”
I would be fine with that in general (if it wasn't for the 100 user
limit). With or without Google verification, it requires a lot of trust
to let an app access your emails and I would strongly suggest that this
is not done lightly.
---
Final rant: The worst part of this process might have been the
assessment portal. A system which requires you to log in every time you
need to write a message and you have to write it in a text field with a
login timeout. You do then receive the reply by email (with a subject
line just stating “New message posted in thread”), but you cannot
reply to that email. You need to log in to the portal again. As an email
client developer, it's kind of infuriating not being able to use an
email client :)
--
Benny
Validation,Section,ID,Description,CWE,Linked CWE,Requirement ID
ZAP,Session Management,3.4.1,Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),614,None,1
ZAP,Session Management,3.4.2,Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),1004,None,1
ZAP,Session Management,3.4.3,Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),1275,None,1
ZAP,Session Management,3.5.3,"Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.",345,"346-None
347-None
348-None
349-None
351-None
352-High
354-Medium
360-High
494-Medium
616-None
646-High
649-High
924-None
1293-None
346-None
347-None
352-High
354-Medium
708-None
924-None
358-None
287-High",1
ZAP,Access Control,4.2.2,"Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.",352,None,1
ZAP,Access Control,4.3.2,"Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.",548,None,1
ZAP,"Validation, Sanitization and Encoding",5.1.5,"Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.",601,None,1
ZAP,"Validation, Sanitization and Encoding",5.2.5,Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.,94,"95-Medium
96-None
1336-None",1
ZAP,"Validation, Sanitization and Encoding",5.3.3,"Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",79,"80-High
81-None
83-None
84-None
85-None
86-None
87-None
692-None",1
ZAP,"Validation, Sanitization and Encoding",5.3.4,"Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))",89,564-None,1
ZAP,"Validation, Sanitization and Encoding",5.3.8,Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)),78,None,1
ZAP,"Validation, Sanitization and Encoding",5.3.9,Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.,829,"830-Medium
98-High
827-None
98 - High",1
ZAP,"Validation, Sanitization and Encoding",5.3.10,Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)),643,None,1
ZAP,"Validation, Sanitization and Encoding",5.5.2,Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.,611,None,1
ZAP,Stored Cryptography,6.2.1,"Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.",310,None,1
ZAP,Stored Cryptography,6.2.3,"Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.",326,"328-None
261-None",1
ZAP,Stored Cryptography,6.2.4,"Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",326,"328-None
261-None",1
ZAP,Stored Cryptography,6.2.7,"Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.",326,"328-None
261-None",1
ZAP,Communication,9.1.2,"Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred.",326,"328-None
261-None",1
_______________________________________________
mailmate mailing list
Unsubscribe: https://lists.freron.com/listinfo/mailmate
