Re: Security issues in snapcraft snap-confine set*id binary

[Jamie Strandboge <jamie () canonical com>]

On Thu, 18 Apr 2019, Matthias Gerstner wrote:

> 1) Up and including to version 2.37.4 the /tmp directory within a snap
>   container was owned by the first user that entered the container. Since
>   snap containers can be used by multiple users at the same time or a
>   privileged program or daemon may run in a container, the security of
>   files and directories in /tmp is compromised.  An attacker can remove
>   or replace files and directories belonging to other users within the
>   container's /tmp to achieve an unspecified impact.
>
>   This issue was recently fixed by upstream via commit [3].

This is CVE-2019-11502

> 2) The `sc_join_preserved_ns()` function along with a number of other
>   function remembers the current working directory (CWD) of the calling
>   user outside of the container and attempts to restore this CWD again
>   within the container. The `chdir()` operation to restore the CWD is
>   performed with root privileges within the container and is prone to
>   symlink attacks. Therefore an unprivileged user can enter arbitrary
>   directories within the container. Example PoC:

This is CVE-2019-11503

> 3) In function `sc_parse_mountinfo_entry()` the pseudo file
...
>   I don't see any viable attack vector here at the moment. To actually
>   control the behaviour of snap-confine we'd need to control the field
>   (4) of the mountinfo file. This field is only available to
>   unprivileged users if they can perform a bind mount.

I agree, this is a legitimate bug that the snapd team will fix but because an
unprivileged user can't gain privileges or other wise cross privilege
boundaries, I did not request a CVE. We can revisit as necessary.

> Best Regards
>
> Matthias

Thank you for the review!

-- 
Jamie Strandboge             | http://www.canonical.com

Attachment: signature.asc
Description: