Summary

When using RUN_AS_USER, the specified user (and therefore, web interface admins) can read arbitrary files as root.

Details

Traditional UNIX services (ISC bind just to give an example) start up with these steps, in order:

1. Start as privileged binary somewhere in /usr (writable by root only)
2. Read config from /etc including the listeners (writable by root only)
3. Set up the listeners while still privileged
4. Drop the privileges
5. Access data somewhere in /var (writable by the unprivileged user)

What makes this secure is that the unprivileged user cannot write anything that is interpreted as root. stalwart-mail adopts the "privdrop after bind"-part, but ignores the "access unprivileged data only after privdrop"-part.

PoC

1. Configure server.listener.https.bind = "%{file:/etc/shadow}%" (works as local user or via the API, rejected by the web interface)
2. View the log after restart (either as local user or via the web interface):

Failed to parse setting "server.listener.https.bind": Invalid socket address "root:$y$j9T…(redacted)

Impact

Admins who have set up to run stalwart with RUN_AS_USER who:

1. handed out admin credentials to the mail server but expect these to only grant access according to the RUN_AS_USER
2. are attacked where the attackers managed to achieve Arbitrary Code Execution using another vulnerability