Impersonate user privilege escalation

[iamthefij]

The issue is that any unix user can gain access to admin through impersonation by writing to /tmp. Then they are free to install anything they want, ignoring any warnings and use that to escalate to unix root.

[iamthefij]

Disallowing impersonation of an Admin would be one way to mitigate the escalation.

Also, managing impersonation in app would do away with this as well.

[girish]

@iamthefij said in Impersonate user privilege escalation:

The issue is that any unix user can gain access to admin through impersonation by writing to /tmp. Then they are free to install anything they want, ignoring any warnings and use that to escalate to unix root.

True but we have not designed Cloudron to be safe from users with SSH/terminal access. For example, the database itself is available to all users. Our idea has always been that only the Cloudron admin has SSH access. In fact, with Cloudron 5, we are making this distinction a bit more clearer. The first admin is now called an 'owner'. Owner is someone who has access to server / administers the server / installed the Cloudron. Owner can add one or more admins who install apps and manage users. Admins don't require or need ssh access.

[iamthefij]

This is not necessarily a Cloudron privilege escalation, but that Cloudron provides an attack vector for system privilege escalation.

The process I laid out will allow one to get system root access.

It puts a Cloudron server one arbitrary code execution bug away from a fully pwned system. Even an admin running a non-privileged script will allow someone to gain access to the entire server.

This will be very easy to mitigate. I believe the easiest way is rather than using/tmp, which is world writable, put the files in a directory that is owned by the cloudron user. Users can write to it by doing echo '{"blah": "blah"}' | sudo -u cloudron tee /var/cloudron/ghost.json, then have Cloudron delete the file afterwards.

[girish]

@iamthefij I guess we tend to think Cloudron more as an appliance which nobody ssh's into and plays around. But there is ample evidence that people do run arbitrary stuff on the server after installing Cloudron even if we tell them it's not supported... I made a fix similar to your suggestion. I moved the ghost file into /home/yellowtent/platformdata and changed the owner as well. This way non-root users cannot create such a file and cannot read an existing file either (commit).

Thanks for reporting!

[murgero]

@iamthefij said in Impersonate user privilege escalation:

I was just reading the documentation on how to do user impersonation and it appears that you only need access to write to /tmp. This is something that any non-privileged Unix user can write to.

/tmp is only writable when in CLI or an app that has a feature to write to this (in the docker container, not the cloudron server)

[iamthefij]

@murgero I’m not sure what you mean. Anyone with shell access to the server as any user could do this.

@girish thanks for the quick update! L

Thinking on it a bit more, for more defense in depth I’m realizing that if the server is running as yellowtent the directory ought to be read only for that user. Otherwise a remote execution vulnerability is enough to own the server and escalate privileges.

I’m not a proper security auditor though...

Have you considered getting a professional audit?

[fbartels]

@iamthefij talking about irresponsible disclosure. For the benefit of other Cloudron users it may be wiser to have a non public channel to discuss something like this.

(But it's indeed good that is was noticed and changed)

[iamthefij]

@fbartels good point. @girish Is there a non-public channel for this?

[girish]

Our bad that we don't have any specific guidelines to report security issues. We will add this to our site. In the meantime:

• Write to support@cloudron.io
• Alternately, you can open a "confidential" issue in https://git.cloudron.io/cloudron/box/issues (this does require you to register in our gitlab and enable 2FA).

[girish]

Just to follow up on this. Now that we have owner role in Cloudron 5, install/update/repair/exec of apps that use the docker addon is restricted to owner in 5.1. This then means that an admin cannot get access to some shell and access docker and hijack the system.

On a technical note, docker is accessed by apps via proxy. This proxy verifies that only apps that request the docker addon can access the docker API. The proxy also ensures that random volumes cannot be mounted (only /app/data of the app can be volume mounted).

[iamthefij]

Thanks @girish!