Bug 1875699 (CVE-2020-14386) - CVE-2020-14386 kernel: memory corruption in net/packet/af_packet.c leads to elevation of privilege
Summary: CVE-2020-14386 kernel: memory corruption in net/packet/af_packet.c leads to e...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2020-14386
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1876221 1876222 1876223 1876224 1876225 1876226 1876227 1876228 1876349 1881425 1881426 1887496 1887497 1887498
Blocks: 1875230
TreeView+ depends on / blocked
 
Reported: 2020-09-04 06:21 UTC by msiddiqu
Modified: 2023-12-15 19:10 UTC (History)
75 users (show)

Fixed In Version: Linux kernel 5.9-rc4
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the Linux kernel. Memory corruption can be exploited to gain root privileges from unprivileged processes. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
Clone Of:
Environment:
Last Closed: 2020-10-20 14:21:25 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:4286 0 None None None 2020-10-20 08:48:10 UTC
Red Hat Product Errata RHSA-2020:4287 0 None None None 2020-10-20 08:39:04 UTC
Red Hat Product Errata RHSA-2020:4289 0 None None None 2020-10-20 09:00:32 UTC
Red Hat Product Errata RHSA-2020:4331 0 None None None 2020-10-26 11:19:12 UTC
Red Hat Product Errata RHSA-2020:4332 0 None None None 2020-10-26 11:14:39 UTC
Red Hat Product Errata RHSA-2020:5199 0 None None None 2020-11-24 10:04:22 UTC

Description msiddiqu 2020-09-04 06:21:27 UTC
A vulnerability was found in Linux Kernel, which leads to a memory corruption in (net/packet/af_packet.c). It can be exploited to gain root privileges from unprivileged processes.

Comment 1 msiddiqu 2020-09-04 06:22:05 UTC
References: 
 
https://seclists.org/oss-sec/2020/q3/146

Comment 6 Alex 2020-09-06 14:30:50 UTC
Acknowledgments:

Name: Or Cohen (paloaltonetworks.com)

Comment 8 msiddiqu 2020-09-07 05:36:11 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1876349]

Comment 9 Vincent Brillault 2020-09-07 15:50:39 UTC
Could you clarify what you mean by `If the CAP_NET_RAW capability disabled by default (that is true for all Red Hat Enterprise Linux products)`?
`CAP_NET_RAW` is normally not given to normal users, true, but they can get it by using namespace, can't they (I'm not sure what you mean by "disabling" this capability)?
Calling `unshare(CLONE_NEWUSER)` should grant you `CAP_NET_RAW` (and many more), then you can `unshare(CLONE_NEWNET)` can get you more control over "your" network...

I have not tested on RHEL8, but on CentOS8 (with I believe the default systcl), the reproducer from https://seclists.org/oss-sec/2020/q3/146 (https://seclists.org/oss-sec/2020/q3/att-146/trigger_bug_c.bin) crashes the system (4.18.0-193.14.2.el8_2.x86_64). Setting `user.max_net_namespaces` or `user.max_user_namespaces` to 0 (I believe their defaults to be 13622) prevents the reproducer from working.

Is this a difference of defaults between RHEL8 and CentOS8? Did I miss another way of "disabling" the CAP_NET_RAW?

Comment 10 Alex 2020-09-08 15:45:15 UTC
In reply to comment #9:
> Could you clarify what you mean by `If the CAP_NET_RAW capability disabled
> by default (that is true for all Red Hat Enterprise Linux products)`?
> `CAP_NET_RAW` is normally not given to normal users, true, but they can get
> it by using namespace, can't they (I'm not sure what you mean by "disabling"
> this capability)?
> Calling `unshare(CLONE_NEWUSER)` should grant you `CAP_NET_RAW` (and many
> more), then you can `unshare(CLONE_NEWNET)` can get you more control over
> "your" network...
> 
> I have not tested on RHEL8, but on CentOS8 (with I believe the default
> systcl), the reproducer from https://seclists.org/oss-sec/2020/q3/146
> (https://seclists.org/oss-sec/2020/q3/att-146/trigger_bug_c.bin) crashes the
> system (4.18.0-193.14.2.el8_2.x86_64). Setting `user.max_net_namespaces` or
> `user.max_user_namespaces` to 0 (I believe their defaults to be 13622)
> prevents the reproducer from working.
> 
> Is this a difference of defaults between RHEL8 and CentOS8? Did I miss
> another way of "disabling" the CAP_NET_RAW?

Red Hat Enterprise Linux does not have unprivileged user namespaces enabled by default.
Local unprivileged users also cannot abuse namespaces to grant this capability to themselves and elevate their privileges.

Comment 11 Martin Hecht 2020-09-09 13:11:56 UTC
What if the user.max_user_namespaces setting is set to something larger than 0 administratively? Are the kernels in RHEL 7 affected, or is the classification "not affected" based on this default setting that disables unprivileged namespaces.

In my understanding user namespaces are intended to confine elevated privileges for instance inside of a container environment. Is the scenario described by Vincent realistic (i.e. use unshare to obtain CAP_NET_RAW in a container and crash the whole system using this bug, possibly escalate privileges once the announced exploit becomes available)?

Also, as mentioned by Vincent, by default in RHEL 8.x user namespaces are available (or is this a subtle difference between RHEL and CentOS?)

Comment 15 Alex 2020-09-10 10:47:46 UTC
In reply to comment #11:
> What if the user.max_user_namespaces setting is set to something larger than
> 0 administratively? Are the kernels in RHEL 7 affected, or is the
> classification "not affected" based on this default setting that disables
> unprivileged namespaces.
> 
> In my understanding user namespaces are intended to confine elevated
> privileges for instance inside of a container environment. Is the scenario
> described by Vincent realistic (i.e. use unshare to obtain CAP_NET_RAW in a
> container and crash the whole system using this bug, possibly escalate
> privileges once the announced exploit becomes available)?
> 
> Also, as mentioned by Vincent, by default in RHEL 8.x user namespaces are
> available (or is this a subtle difference between RHEL and CentOS?)

The RHEL 7 not affected, because bug appeared with addition of these lines of source code:
"
+                if (po->has_vnet_hdr) {
                        netoff += sizeof(struct virtio_net_hdr);
+                        do_vnet = true;
+                }
                macoff = netoff - maclen;
"
; this based on comment by Alexander (see
"I just looked into it some further, and it appears the bug was exposed
to the known way to trigger it with 58d19b19cd99 ("packet: vnet_hdr support for tpacket_rcv") in February 2016, which first got into 4.6-rc1"
, taken from https://seclists.org/oss-sec/2020/q3/150 ),
and then it is actual only for rhel8 (means after commit 58d19b19cd99 that was not in RHEL 7 yet).


For being sure that it is disabled for RHEL 8.x, I tried (with "8.0 (Ootpa)", kernel "4.18.0-80.11.2.el8_0.x86_64"):

[tasks]$ unshare -U sh
sh-4.4$ gcc poc.c
sh-4.4$ ls
a.out  poc.c
sh-4.4$ ./a.out 
[-] unshare(CLONE_NEWUSER): Operation not permitted

, and the same if trying "unshare(CLONE_NEWNET)" instead of unshare(CLONE_NEWUSER):

unshare -n -U sh
[-] unshare(CLONE_NEWNET): Operation not permitted


However, I'll check more if any scenario realistic to bypass for regular user.

-- added later: note that experiment above not correct, because no need to run "unshare" command before poc.c.
See my next comment for more details.

Comment 17 Martin Hecht 2020-09-10 13:35:03 UTC
(In reply to Alex from comment #15)

Hi Alex,

thanks for answering my questions.

> The RHEL 7 not affected, because bug appeared with addition of these lines
> of source code: [...]
> and then it is actual only for rhel8 (means after commit 58d19b19cd99 that
> was not in RHEL 7 yet).

I just wasn't sure if Redhat has backported this commit (perhaps together 
with other features) to the 3.10-el7 kernel.
 
> [...] I'll check more if any scenario realistic to bypass for regular user.

Thank you very much.

Comment 18 Dave Dykstra 2020-09-10 18:27:30 UTC
(In reply to Alex from comment #10)
> In reply to comment #9:
> Red Hat Enterprise Linux does not have unprivileged user namespaces enabled
> by default.

Alex: that's true for RHEL 7, but as far as I have seen not true for RHEL 8.
Can you confirm?  Like Vincent, I have only tested on CentOS 8, but I believe
CentOS uses the same defaults as RHEL.  I haven't found any Red Hat documentation
confirming or denying it.

Comment 19 Vincent Brillault 2020-09-10 18:31:59 UTC
(In reply to Alex from comment #15)

Dear Alex,

Thanks a lot for your tests and for confirming that RHEL7 is not affected!

> For being sure that it is disabled for RHEL 8.x, I tried (with "8.0
> (Ootpa)", kernel "4.18.0-80.11.2.el8_0.x86_64"):

I must admit I only tested 8.2, not 8.0, I don't know/remember if there is any difference in namespace support.
A colleague tested on a pure RHEL 8.2 and was able to trigger the poc without any privilege.

> [tasks]$ unshare -U sh

In our tests, we were simply running the poc as a non-privilege user (as the poc itself is calling unshare).
I don't remember if there is any restriction in chained namespaces, but this step should not be needed.

> However, I'll check more if any scenario realistic to bypass for regular
> user.

Thanks!

Comment 20 customercare 2020-09-10 22:55:29 UTC
F31 seems to be affected, if crashcode is run as unprivileged user, but does not crash the server, it just crashes nonechroot-ssh (if connected via ssh). Server seems to be uneffected.

F31 seems not be affected, if crashcode is run inside a chroot() i.e. ssh connection:

[cloud-test@testserver cloud-test]$ ./trigger_bug.bin 
[-] unshare(CLONE_NEWUSER): Operation not permitted

tested with 5.6.13-200.fc31.x86_64.

Comment 21 customercare 2020-09-10 23:00:24 UTC
correction: server crashed and rebooted immediatly in case 1.. unpriv user nonechroot-ssh.

Comment 23 Ulrich Schwickerath 2020-09-16 11:26:52 UTC
(In reply to Alex from comment #10)
> In reply to comment #9:
> > Could you clarify what you mean by `If the CAP_NET_RAW capability disabled
> > by default (that is true for all Red Hat Enterprise Linux products)`?
> > `CAP_NET_RAW` is normally not given to normal users, true, but they can get
> > it by using namespace, can't they (I'm not sure what you mean by "disabling"
> > this capability)?
> > Calling `unshare(CLONE_NEWUSER)` should grant you `CAP_NET_RAW` (and many
> > more), then you can `unshare(CLONE_NEWNET)` can get you more control over
> > "your" network...
> > 
> > I have not tested on RHEL8, but on CentOS8 (with I believe the default
> > systcl), the reproducer from https://seclists.org/oss-sec/2020/q3/146
> > (https://seclists.org/oss-sec/2020/q3/att-146/trigger_bug_c.bin) crashes the
> > system (4.18.0-193.14.2.el8_2.x86_64). Setting `user.max_net_namespaces` or
> > `user.max_user_namespaces` to 0 (I believe their defaults to be 13622)
> > prevents the reproducer from working.
> > 
> > Is this a difference of defaults between RHEL8 and CentOS8? Did I miss
> > another way of "disabling" the CAP_NET_RAW?
> 
> Red Hat Enterprise Linux does not have unprivileged user namespaces enabled
> by default.
> Local unprivileged users also cannot abuse namespaces to grant this
> capability to themselves and elevate their privileges.

Dear all,

we have reproduced the behavior described by Vincent on a RHEL8 machine. The system crashes and reboots when the reproducer is executed. How can we verify that CAP_NET_RAW is indeed disabled on RHEL8?

Comment 24 Dave Dykstra 2020-09-16 16:10:33 UTC
Ulrich: CAP_NET_RAW will always be enabled in a user namespace, but as Vincent said you can disable the affect with sysctl -w user.max_net_namespaces=0.

This will turn off network namespaces both inside and outside of a user namespace.  Note that docker depends on network namespaces by default, but not if the --net=host option is used.

Comment 28 Alex 2020-09-17 16:22:19 UTC
In reply to comment #15:
> In reply to comment #11:
..
> For being sure that it is disabled for RHEL 8.x, I tried (with "8.0
> (Ootpa)", kernel "4.18.0-80.11.2.el8_0.x86_64"):
> 
> [tasks]$ unshare -U sh
> sh-4.4$ gcc poc.c
> sh-4.4$ ls
> a.out  poc.c
> sh-4.4$ ./a.out 
> [-] unshare(CLONE_NEWUSER): Operation not permitted
> 
> , and the same if trying "unshare(CLONE_NEWNET)" instead of
> unshare(CLONE_NEWUSER):
> 
> unshare -n -U sh
> [-] unshare(CLONE_NEWNET): Operation not permitted
> 
> 
> However, I'll check more if any scenario realistic to bypass for regular
> user.


I've just checked again that is if running the same without prior "unshare -U sh" command (like just run these two commands

gcc ./poc.c
./a.out

), then bug happens and leads to immediate reboot (with unprivileged users and tested again with "with "8.0 (Ootpa)", kernel "4.18.0-80.11.2.el8_0.x86_64"").

It means that both this prior saying (that was correct for RHEL7, but different starting with RHEL 8.0)

"
In order to exploit this issue the attacker needs CAP_NET_RAW capability, which needs to be granted by the administrator to the attacker's account. Since Red Hat Enterprise Linux 7 does not have unprivileged user namespaces enabled by default, local unprivileged users also cannot abuse namespaces to grant this capability to themselves and elevate their privileges.
" (taken from https://access.redhat.com/solutions/2795871 that is other more or less similar issue)

and my previous experiment were incorrect if for RHEL8.

Comment 30 Dave Dykstra 2020-09-17 16:39:52 UTC
How about adding that an additional mitigation needed for Red Hat Enterprise Linux 8 products is to disable network namespaces with user.max_net_namespaces=0 or user namespaces with user.max_user_namespaces=0?

Comment 31 Dave Dykstra 2020-09-17 17:16:41 UTC
For that matter, the setting of CAP_NET_RAW or any namespace setting is irrelevant on RHEL products earlier than 8, because the bug isn't even in that kernel.  So the current mitigation text is misleading by mentioning earlier products.

How about a mitigation of "For Red Hat Enterprise Linux 8 products, the mitigation is to disable CAP_NET_RAW capability for regular users and for executables and to either disable network namespaces with user.max_net_namespaces=0 or user namespaces with user.max_user_namespaces=0."

Comment 32 Dave Dykstra 2020-09-17 19:17:43 UTC
Also this fits the definition of "Important" impact for RHEL 8, not just "Moderate".

Comment 41 Jason Shepherd 2020-09-18 04:04:05 UTC
I adjusted the impact to important based on the impact to OpenShift Container Platform 4, and that product consuming the kernel from RHEL-8.

Comment 43 Ulrich Schwickerath 2020-09-18 08:32:36 UTC
Hi, all,
maybe I'm still confused. 
Sam, you say above:
"If the CAP_NET_RAW capability disabled by default (which is true for Red Hat Enterprise Linux), then only a privileged user can trigger this bug."
What I did is:
- Boot a RHEL8.2 VM
- do useradd to create a test user
- login as this user
- run the reproducer and the machine crashed and rebooted
I would not have expected that behavior based on the above statement. This is precisely the same behavior reported by Vincent above for CentOS8. What am I missing ?

Comment 44 customercare 2020-09-18 08:43:03 UTC
(In reply to Ulrich Schwickerath from comment #42)

> What I did is:
> - Boot a RHEL8.2 VM
> - do useradd to create a test user
> - login as this user
> - run the reproducer and the machine crashed and rebooted
> I would not have expected that behavior based on the above statement. This
> is precisely the same behavior reported by Vincent above for CentOS8. What
> am I missing ?

how did you login as user?  did you su from root, or via ssh/desktop etc. ?

Comment 45 Sam Fowler 2020-09-18 08:52:22 UTC
(In reply to Ulrich Schwickerath from comment #43)
> Hi, all,
> maybe I'm still confused. 
> Sam, you say above:
> "If the CAP_NET_RAW capability disabled by default (which is true for Red
> Hat Enterprise Linux), then only a privileged user can trigger this bug."

Alex, could you weigh in on this? I carried that part of the Statement over when I added the OpenShift specific information.

Comment 46 Colin Walters 2020-09-18 11:52:10 UTC
> "If the CAP_NET_RAW capability disabled by default (which is true for Red Hat Enterprise Linux), then only a privileged user can trigger this bug."

The confusion here comes from the concept of user namespaces which are enabled by default in RHEL8.  It's true that an "unprivileged user" doesn't have CAP_NET_RAW by default, but the reproducer program uses CLONE_NEWUSER to create a new user namespace with that capability.

The initial introduction of user namespaces required a lot of fixes in other places in the kernel (e.g. iptables) - and it continues to be an area of elevated security risk - but it is "secure" in the sense we believe we can ship fixes for flaws that are discovered without compromising the functionality.

So yes, all statements around this CVE should be very clear that any operating system which allows CLONE_NEWUSER by default is also vulnerable, and that includes default RHEL8 unprivileged user login sessions.

Comment 47 Petr Matousek 2020-09-18 13:25:12 UTC
Statement:

Only local users with CAP_NET_RAW capability enabled can trigger this issue.

For OpenShift Container Platform 4, pods in the default restricted SCC are granted CAP_NET_RAW by default. An attacker can exploit this if they can run arbitrary container images on the target cluster.

Comment 50 Dave Dykstra 2020-09-18 15:42:21 UTC
That's much better. Please also include a mitigation of disabling network namespaces.  Some of us depend on unprivileged user namespaces but not on network namespaces.  With that you may want to also note that docker requires --net=host if network namespaces are disabled.

I also note that the CVE-2020-14386 page https://access.redhat.com/security/cve/CVE-2020-14386 is not displaying properly on Firefox (version 80.0 on a Mac, and it works on Chrome): long lines in the Description, Statement, and Mitigation are not being wrapped and are overlapping the Additional information box.

Comment 51 Alex 2020-09-21 18:50:42 UTC
In reply to comment #45:
> (In reply to Ulrich Schwickerath from comment #43)
> > Hi, all,
> > maybe I'm still confused. 
> > Sam, you say above:
> > "If the CAP_NET_RAW capability disabled by default (which is true for Red
> > Hat Enterprise Linux), then only a privileged user can trigger this bug."
> 
> Alex, could you weigh in on this? I carried that part of the Statement over
> when I added the OpenShift specific information.

This saying "CAP_NET_RAW capability disabled by default (which is true for Red Hat Enterprise Linux)" was incorrect, because from 8.0 it is enabled. The mitigation is already written accordingly.
I tried these two commands of mitigation with "8.0 (Ootpa)", kernel "4.18.0-80.11.2.el8_0.x86_64":

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf
# sysctl -p /etc/sysctl.d/userns.conf

and then log in with new user and trying poc.c:

gcc poc.c
./a.out

, and the result is:
 
[-] unshare(CLONE_NEWUSER): No space left on device

, so mitigation works as it should be (prevents system from being frozen/reboot).

Comment 52 Petr Matousek 2020-09-22 11:35:08 UTC
Mitigation:

If the CAP_NET_RAW capability disabled by default (which is true for Red Hat Enterprise Linux), then only a privileged user can trigger this bug. The mitigation is to disable CAP_NET_RAW capability for regular users and for executables.

On Red Hat Enterprise Linux 8 CAP_NET_RAW capability can be also gained by exploiting unprivileged user namespaces. The mitigation is to disable unprivileged user namespaces by setting user.max_user_namespaces to 0:

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf
# sysctl -p /etc/sysctl.d/userns.conf

OpenShift Container Platform 4.5 and 4.4 this can be mitigated by removing `CAP_NET_RAW` from the default cri-o capabilities provided to pods (NOTE: This may prevent `ping` from working in unprivileged pods. This fix has not been validated for OpenShift 4.3 or below):
```
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 50-reset-crio-capabilities
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZV0KZGVmYXVsdF9jYXBhYmlsaXRpZXMgPSBbCiAgICAiQ0hPV04iLAogICAgIkRBQ19PVkVSUklERSIsCiAgICAiRlNFVElEIiwKICAgICJGT1dORVIiLAogICAgIlNFVEdJRCIsCiAgICAiU0VUVUlEIiwKICAgICJTRVRQQ0FQIiwKICAgICJORVRfQklORF9TRVJWSUNFIiwKICAgICJTWVNfQ0hST09UIiwKICAgICJLSUxMIiwKXQo=
        filesystem: root
        mode: 0644
        path: /etc/crio/crio.conf.d/reset-crio-capabilities.conf
```

Create this MachineConfig object via e.g. `oc apply`.  More information about MachineConfig can be found here: 
https://github.com/openshift/machine-config-operator
https://docs.openshift.com/container-platform/4.5/architecture/architecture-rhcos.html

In order to monitor the rollout of this change, use `oc describe machineconfigpool/worker`.

Check for any pods which start to crash after this is applied; they may need to be adjusted request `CAP_NET_RAW` explicitly.  More information:
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container
https://docs.openshift.com/container-platform/4.5/authentication/managing-security-context-constraints.html

Comment 76 errata-xmlrpc 2020-10-20 08:38:52 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.1 Extended Update Support

Via RHSA-2020:4287 https://access.redhat.com/errata/RHSA-2020:4287

Comment 77 errata-xmlrpc 2020-10-20 08:48:15 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2020:4286 https://access.redhat.com/errata/RHSA-2020:4286

Comment 78 errata-xmlrpc 2020-10-20 09:00:20 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2020:4289 https://access.redhat.com/errata/RHSA-2020:4289

Comment 79 Product Security DevOps Team 2020-10-20 14:21:25 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2020-14386

Comment 86 errata-xmlrpc 2020-10-26 11:14:29 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.1 Extended Update Support

Via RHSA-2020:4332 https://access.redhat.com/errata/RHSA-2020:4332

Comment 87 errata-xmlrpc 2020-10-26 11:19:17 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2020:4331 https://access.redhat.com/errata/RHSA-2020:4331

Comment 91 errata-xmlrpc 2020-11-24 10:04:15 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.0 Update Services for SAP Solutions

Via RHSA-2020:5199 https://access.redhat.com/errata/RHSA-2020:5199


Note You need to log in before you can comment on or make changes to this bug.