Vulnerability: seizure of phone with DC with admin group gains eternal unlimited access to the mailcow server

[dumblob]

• Operating System (Linux/Mac/Windows/iOS/Android): N/A
• Delta Chat Version: N/A
• Expected behavior:

This everything is about admin group and thus the bot accepting diverse commands.

There is a way (perhaps even partially automated - e.g. some governance/voting model in the admin group facilitated using DC apps for "write" operations unlike "read" operations) to lock any participant in an admin group any time. Removing the participant immediately seems too much, but locking her sounds more resistant to human mistakes.

Or maybe every "write" request shall ask for password each time?

IDK what would be best.

• Actual behavior:

Anybody in possession of a smartphone, tablet, notebook etc. - e.g. your child, spouse, friend, cat, ... you name it - more often than not has access to your unlocked phone. A communicator is the "target number one" to play with. It is super easy to unintentionally as well as intentionally do harm with admin rights on an email server.

• Steps to reproduce the problem: become part of admin group
• Screenshots: N/A
• Logs: N/A

Related

https://github.com/deltachat/mailadm/issues/36

[missytake]

I understand your concerns, but I think we can't do anything more to protect admins against this threat model.

If an attacker steals a phone, you are supposed to remove the compromised account, and re-add it as soon as you took away access from the attacker. Worst case, if the attacker threw everyone else out of the admin group, you can deactivate the admin group over the command line through mailadm setup-bot and set up a new one.

My opinion is that this is much less annoying than typing in a password on every command.

Luckily, the threat model is less severe than you think: it's not unlimited eternal access, only few methods are exposed. The admin group can not be used to get persistent access or escalate privileges; therefore an attacker can always be kicked out as soon as you realize that an account was compromised.

Finally, I think admins are responsible for protecting their devices. Opsec is not the responsibility of mailadm, we can not influence all the other threat vectors an admin can experience. A child, spouse, or friend having access to your unlocked phone is a scenario which I as an admin simply try to completely avoid. After all, if an attacker can get hold of an admin's phone, they could also ask a co-admin to "quickly upload this new SSH key to the server, I don't have my laptop with me and need to look something up" or something similar - this would give much more power to an attacker than a mailadm admin group. So I don't think sacrificing usability for security is a good idea in this scenario.

[dumblob]

Ok, I now see that not a full-featured interface will be available through chat. That somewhat limits the danger but not enough IMHO.

I totally agree with most of what you wrote but there are two observations which make it a different situation:

1. chat is generally considered as "totally safe" which mailadm reverses - people (incl. admins) are simply not used to the fact that one of the tens/hundreds of contacts (all looking the same with identical behavior UX-wise in the chat app) is so much different and dangerous (yes, accidental mistakes happen in such scenarios vastly more frequently)
2. the defaults of any admin interface must be safe whatever it takes

So yes, having passwords (or at least disabled the "write" access) by default is definitely solving the issue. Admins can always change their mind and allow the write access explicitly later.

Btw. passwords can be cached for a short period (e.g. 3 minutes since last "write"-class command issued through chat) effectively avoiding to type it over again. Alternatively one can implement fine-grained settings which "write" commands with which parameters can be issued without password/authentication from the admin chat.

There are other approaches but these I outlined seem the easiest to grasp & implement.

[hpk42]

On Fri, Feb 03, 2023 at 05:33 -0800, dumblob wrote:

1. chat is generally considered as "totally safe" which mailadm reverses - people (incl. admins) are simply not used to the fact that one of the tens/hundreds of contacts (all looking the same with identical behavior UX-wise in the chat app) is so much different and dangerous (yes, accidental mistakes happen in such scenarios vastly more frequently)

There is no "contact" that is special. The "genesis" admin group allows accessing/modifying users and tokens for creating users. It does not offer e.g. reading or deleting messages or modifying the server in more profound ways. Moreover, a random user of an admin's phone would hardly be able to write "/add_token" or similar with a couple correctly parseable parameters.

Have you ever used mailadm-supported admin groups, btw? It's much more mundane than you might imagine :)

[dumblob]

There is no "contact" that is special.

I did not mean a genuine contact. I meant an item in the left list of chats/groups. Sorry for the confusion.

The "genesis" admin group allows accessing/modifying users and tokens for creating users. It does not offer e.g. reading or deleting messages or modifying the server in more profound ways. Moreover, a random user of an admin's phone would hardly be able to write "/add_token" or similar with a couple correctly parseable parameters.

Yep, then we have this much more careful about what happens in the future. Maybe we will add command history (making it easy to "resend last message") or advanced suggestions (making it easy to resend one of the past commands with something altered) or any expansion of mailadm command coverage.

To me this all sounds a little too brittle. But I agree that I tend to be too paranoid at times :smile:.

Have you ever used mailadm-supported admin groups, btw? It's much more mundane than you might imagine :)

Not yet. Perhaps because I was subconsciously a little afraid of using it :smile:.