Impersonate user privilege escalation

[iamthefij]

Note: I haven't tested this method yet as I am not sure which Apps already have the Docker addon, but making a custom one and installing it via the CLI after taking over the admin account with the temp password would be simple enough.

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.

Theoretically, a normal user could do this to gain access to an Admin user and then be able to modify users or gain access to user information. They could also install an app with privileged access to the Docker socket and then use that to gain access to the machine by starting a container as root with access to the root filesystem. Eg. docker run -it -v /:/host ubuntu

[girish]

Only JupyterHub app on the app store uses docker addon. Normal users don't have access to docker containers as a privileged user in the app. For custom apps, only admins can install apps in the first place. Current, an admin can already generate reset password links of other users and fellow admins (clicking the plane button in the users view).

So, I think the attack vector here is that an unknowing admin installs a custom app with the docker addon. Maybe, we need to add security warning in https://cloudron.io/documentation/custom-apps/addons/#docker for admins ? We could make it the docker addon unavailable for custom apps altogether. Not sure if this breaks "hackability"/tinkering

[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!