Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "SVG:Advisory-SVG-CVE-2020-14386"

From EGIWiki
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 2: Line 2:


<pre>
<pre>
Title:      EGI SVG 'ADVISORY' [TLP:WHITE] **UPDATE** HIGH risk - privilege escalation vulnerability in recent kernels  
Title:      EGI SVG 'ADVISORY' [TLP:WHITE] **UPDATE 3** HIGH risk - privilege escalation vulnerability in recent kernels  
             (e.g. RHEL/CentOS 8) [EGI-SVG-CVE-2020-14386]  
             (e.g. RHEL/CentOS 8) [EGI-SVG-CVE-2020-14386]  


Date:        2020-09-22
Date:        2020-09-22
Updated:    2020-10-22
Updated:    2020-10-22, 2020-10-28 
 


Affected software and risk
Affected software and risk
Line 18: Line 17:
Bug ID  : RedHat Bugzilla 1875699
Bug ID  : RedHat Bugzilla 1875699


A memory corruption vulnerability described in CVE-2020-14386 [R 1], [R 2] has been found in some versions  
A memory corruption vulnerability described in CVE-2020-14386 [R 1], [R 2] has been found in some versions of the  
of the Linux kernel that may result in privilege escalation to gain root privileges from unprivileged processes.  
Linux kernel that may result in privilege escalation to gain root privileges from unprivileged processes.  
Specifically, this affects RedHat Enterprise Linux 8 and its derivatives including CentOS 8; RHEL 7 and  
Specifically, this affects RedHat Enterprise Linux 8 and its derivatives including CentOS 8; RHEL 7 and CentOS 7 are not affected.
CentOS 7 are not affected.




Line 31: Line 29:
RedHat has fixed this issue - see [R 8], fixes are now available for RedHat and its derivatives.  
RedHat has fixed this issue - see [R 8], fixes are now available for RedHat and its derivatives.  


Sites are recommended to update relevant components.  This should be carried out urgently if they have not  
Sites are recommended to update relevant components.  This should be carried out urgently if they have not already
already carried out the mitigation described in this advisory on affected hosts, especially those providing  
carried out the mitigation described in this advisory on affected hosts, especially those providing shell or container  
shell or container access to unprivileged users.
access to unprivileged users.
 
Sites should be aware that if a public exploit is released which demonstrates a root exploit of this vulnerability this
vulnerability is likely to be elevated to 'Critical' and sites will then be required to take action within 7 days or risk suspension.
 
In general, the EGI SVG recommends that sites enable user namespaces (an advisory was issued on this [R 3]).
 
**UPDATE 2020-10-28 ** We refer to the latest OSG recommendations and information on network and user namespaces, and their
relationship with the more recent kernels [R 9]
 
Based on the latest OSG recommendation
======================================


Sites should be aware that if a public exploit is released which demonstrates a root exploit of this
Additionally, the OSG Security team and the EGI SVG recommend disabling network namespaces when unprivileged user
vulnerability this vulnerability is likely to be elevated to 'Critical' and sites will then be required
namespaces are enabled [R 3]:
to take action within 7 days or risk suspension.


In general, the EGI SVG recommends that sites enable user namespaces (an advisory was issued on this [R 3]),
```
but for the matter at hand the mitigation is strongly recommended on affected services, until they have been
echo "user.max_net_namespaces = 0" \
rebooted with a fixed kernel.
    > /etc/sysctl.d/90-max_net_namespaces.conf
sysctl -p /etc/sysctl.d/90-max_net_namespaces.conf
```


Note RHEL/CentOS 8, recent Fedora versions, Debian, Ubuntu and OpenSUSE (LEAP 15.1 and newer) have user namespaces  
Note that docker uses network namespaces, unless it is invoked with --net=host. Disabling network namespaces
enabled by default.  
also blocks the systemd PrivateNetwork feature, which is a feature that is used by some EL 8 services.
It is also configured for some EL 7 services but they are all disabled by default. More details on this issue
and potential workarounds are available in the OSG Singularity documentation [R 9].
 
Unprivileged user namespaces are enabled by default on EL8. If you are not using unprivileged user namespaces
(for example for singularity), you can also mitigate this issue by disabling them:
 
```
echo "user.max_user_namespaces = 0" \
    > /etc/sysctl.d/90-max_user_namespaces.conf
sysctl -p /etc/sysctl.d/90-max_user_namespaces.conf
 
 
Note RHEL/CentOS 8, recent Fedora versions, Debian, Ubuntu and OpenSUSE (LEAP 15.1 and newer) have user namespaces enabled by default.  




Line 59: Line 82:
==========
==========


**UPDATE 2020-10-22**  A patched kernel is now available. This mitigation was the recommended action  
**UPDATE 2020-10-22**  A patched kernel is now available. This mitigation was the recommended action prior
prior to the availability of a patched kernel.  
to the availability of a patched kernel.  


The Red Hat security announcement [R 2] recommends disabling the CAP_NET_RAW capability for regular  
The Red Hat security announcement [R 2] recommends disabling the CAP_NET_RAW capability for regular users
users and executables as a mitigation.
and executables as a mitigation.
 
Additionally, the OSG Security team and the EGI SVG recommend disabling network namespaces when
unprivileged user namespaces are enabled [R 3]:
 
echo "user.max_net_namespaces = 0" \
    > /etc/sysctl.d/90-max_net_namespaces.conf
sysctl -p /etc/sysctl.d/90-max_net_namespaces.conf
 
Note that docker uses network namespaces, unless it is invoked with --net=host.
 
Unprivileged user namespaces are enabled by default on RHEL 8. If you are not using unprivileged user
namespaces (for example for singularity), you can also mitigate this issue by disabling them:
 
echo "user.max_user_namespaces = 0" \
    > /etc/sysctl.d/90-max_user_namespaces.conf
sysctl -p /etc/sysctl.d/90-max_user_namespaces.conf




Line 102: Line 109:


At present, only crashing of services has been demonstrated as a result of exploit of this vulnerability,  
At present, only crashing of services has been demonstrated as a result of exploit of this vulnerability,  
but we are aware of on-going efforts to develop a root exploit of this vulnerability.  Previously memory  
but we are aware of on-going efforts to develop a root exploit of this vulnerability.   
corruption vulnerabilities where only an operational risk was initially demonstrated have later been  
Previously memory corruption vulnerabilities where only an operational risk was initially demonstrated have later  
associated with incidents.
been associated with incidents.
 
Some sites have found that setting "user.max_net_namespaces = 0"  as recommended breaks some features with some of the latest kernels. 
OSG has since looked at this and modified its recommendations and we refer sites to OSG information at  [R 9].  




Line 150: Line 160:


[R 8] https://access.redhat.com/errata/RHSA-2020:4286
[R 8] https://access.redhat.com/errata/RHSA-2020:4286
[R 9] https://opensciencegrid.org/docs/worker-node/install-singularity/#enabling-unprivileged-singularity


Credit
Credit
Line 168: Line 180:
2020-09-22 Advisory sent to sites recommending mitigating action
2020-09-22 Advisory sent to sites recommending mitigating action
2020-10-22 Advisory updated as issue has been fixed and sites are recommended to update
2020-10-22 Advisory updated as issue has been fixed and sites are recommended to update
2020-10-28 Advisory updated to include the latest OSG recommendations.




Line 176: Line 189:
"To minimize the risk to the EGI infrastructure arising from software vulnerabilities"
"To minimize the risk to the EGI infrastructure arising from software vulnerabilities"


The risk is that assessed by the group, according to the EGI SVG issue handling procedure [R 7]   
The risk is that assessed by the group, according to the EGI SVG issue handling procedure [R 7]  in the context of how  
in the context of how the software is used in the EGI infrastructure. It is the opinion of the group,  
the software is used in the EGI infrastructure. It is the opinion of the group, we do not guarantee it to be correct.  
we do not guarantee it to be correct. The risk may also be higher or lower in other deployments  
The risk may also be higher or lower in other deployments depending on how the software is used.   
depending on how the software is used.   


-----------------------------
-----------------------------
This advisory is subject to the Creative commons license https://creativecommons.org/licenses/by/4.0/  
This advisory is subject to the Creative commons license https://creativecommons.org/licenses/by/4.0/ and
and the EGI https://www.egi.eu/ Software Vulnerability Group must be credited.  
the EGI https://www.egi.eu/ Software Vulnerability Group must be credited.  
-----------------------------
-----------------------------


Line 190: Line 202:


On behalf of the EGI SVG,
On behalf of the EGI SVG,






</pre>
</pre>

Latest revision as of 16:44, 28 October 2020

Main page Software Security Checklist Issue Handling Advisories Notes On Risk Advisory Template More

Advisory-SVG-CVE-2020-14386


Title:       EGI SVG 'ADVISORY' [TLP:WHITE] **UPDATE 3** HIGH risk - privilege escalation vulnerability in recent kernels 
             (e.g. RHEL/CentOS 8) [EGI-SVG-CVE-2020-14386] 

Date:        2020-09-22
Updated:     2020-10-22, 2020-10-28   

Affected software and risk
==========================

HIGH risk vulnerability in recent kernels, used e.g. by RHEL 8 and derivatives

Package : Linux kernel used e.g. by RHEL 8 and derivatives 
CVE ID  : CVE-2020-14386
Bug ID  : RedHat Bugzilla 1875699

A memory corruption vulnerability described in CVE-2020-14386 [R 1], [R 2] has been found in some versions of the 
Linux kernel that may result in privilege escalation to gain root privileges from unprivileged processes. 
Specifically, this affects RedHat Enterprise Linux 8 and its derivatives including CentOS 8; RHEL 7 and CentOS 7 are not affected.


Actions required/recommended
============================

**UPDATE 2020-10-22** 

RedHat has fixed this issue - see [R 8], fixes are now available for RedHat and its derivatives. 

Sites are recommended to update relevant components.  This should be carried out urgently if they have not already 
carried out the mitigation described in this advisory on affected hosts, especially those providing shell or container 
access to unprivileged users.

Sites should be aware that if a public exploit is released which demonstrates a root exploit of this vulnerability this 
vulnerability is likely to be elevated to 'Critical' and sites will then be required to take action within 7 days or risk suspension.

In general, the EGI SVG recommends that sites enable user namespaces (an advisory was issued on this [R 3]).

**UPDATE 2020-10-28 ** We refer to the latest OSG recommendations and information on network and user namespaces, and their 
relationship with the more recent kernels [R 9] 

Based on the latest OSG recommendation
======================================

Additionally, the OSG Security team and the EGI SVG recommend disabling network namespaces when unprivileged user 
namespaces are enabled [R 3]:

```
echo "user.max_net_namespaces = 0" \
    > /etc/sysctl.d/90-max_net_namespaces.conf
sysctl -p /etc/sysctl.d/90-max_net_namespaces.conf
```

Note that docker uses network namespaces, unless it is invoked with --net=host. Disabling network namespaces 
also blocks the systemd PrivateNetwork feature, which is a feature that is used by some EL 8 services. 
It is also configured for some EL 7 services but they are all disabled by default. More details on this issue 
and potential workarounds are available in the OSG Singularity documentation [R 9].

Unprivileged user namespaces are enabled by default on EL8. If you are not using unprivileged user namespaces 
(for example for singularity), you can also mitigate this issue by disabling them:

```
echo "user.max_user_namespaces = 0" \
    > /etc/sysctl.d/90-max_user_namespaces.conf
sysctl -p /etc/sysctl.d/90-max_user_namespaces.conf


Note RHEL/CentOS 8, recent Fedora versions, Debian, Ubuntu and OpenSUSE (LEAP 15.1 and newer) have user namespaces enabled by default. 


Component installation information
==================================

For information related to RedHat see [R 2]

For information related to Debian see [R 4] 

For information related to Ubuntu see [R 5]

Mitigation
==========

**UPDATE 2020-10-22**  A patched kernel is now available. This mitigation was the recommended action prior 
to the availability of a patched kernel. 

The Red Hat security announcement [R 2] recommends disabling the CAP_NET_RAW capability for regular users 
and executables as a mitigation.



Affected software details
=========================

RHEL 8 and CentOS 8 are affected.

RHEL 6 and RHEL 7 and their derivatives are not affected.

For information on Debian related to this specific vulnerability see [R 4], and Ubuntu see [R 5]


More information
================

A memory corruption vulnerability [R 6] exists in code related to handling AF_PACKET sockets. 
An unprivileged user on systems where unprivileged user namespaces are enabled, such as EL8 systems, 
can acquire the CAP_NET_RAW capability to create AF_PACKET sockets and trigger this memory corruption, 
potentially leading to privilege escalation.

At present, only crashing of services has been demonstrated as a result of exploit of this vulnerability, 
but we are aware of on-going efforts to develop a root exploit of this vulnerability.  
Previously memory corruption vulnerabilities where only an operational risk was initially demonstrated have later 
been associated with incidents.

Some sites have found that setting "user.max_net_namespaces = 0"  as recommended breaks some features with some of the latest kernels.  
OSG has since looked at this and modified its recommendations and we refer sites to OSG information at  [R 9]. 


TLP and URL
===========

** WHITE information - Unlimited distribution 
- see https://wiki.egi.eu/wiki/EGI_CSIRT:TLP for distribution restrictions***    

URL:   https://wiki.egi.eu/wiki/SVG:Advisory-SVG-CVE-2020-14386   

Minor updates may be made without re-distribution to the sites


Comments
========

Comments or questions should be sent to svg-rat  at  mailman.egi.eu

If you find or become aware of another vulnerability which is relevant to EGI you may report it by e-mail to  

report-vulnerability at egi.eu
 
the EGI Software Vulnerability Group will take a look according to the procedure defined in [R 7]  

Note that this is undergoing revision to fully handle vulnerabilities in the EOSC-hub era. 


References
==========

[R 1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14386

[R 2] https://access.redhat.com/security/cve/CVE-2020-14386

[R 3] https://wiki.egi.eu/wiki/SVG:Advisory-SVG-2020-16648

[R 4] https://security-tracker.debian.org/tracker/CVE-2020-14386

[R 5] https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-14386

[R 6] https://seclists.org/oss-sec/2020/q3/146 

[R 7] https://documents.egi.eu/public/ShowDocument?docid=3145

[R 8] https://access.redhat.com/errata/RHSA-2020:4286

[R 9] https://opensciencegrid.org/docs/worker-node/install-singularity/#enabling-unprivileged-singularity

Credit
======

SVG was alerted to this vulnerability by Dave Dykstra 

Some of the information in this advisory is based on the corresponding OSG advisory for these vulnerabilities.

Timeline  
========
Yyyy-mm-dd  [EGI-SVG-CVE-2020-14386] 

2020-09-17 SVG alerted to this issue by Dave Dykstra
2020-09-18 Acknowledgement from the EGI SVG to the reporter
2020-09-18 Investigation of vulnerability and relevance to EGI carried out 
2020-09-21 EGI SVG Risk Assessment completed
2020-09-22 Advisory sent to sites recommending mitigating action
2020-10-22 Advisory updated as issue has been fixed and sites are recommended to update
2020-10-28 Advisory updated to include the latest OSG recommendations.


Context
=======

This advisory has been prepared as part of the effort to fulfil EGI SVG's purpose 
"To minimize the risk to the EGI infrastructure arising from software vulnerabilities"

The risk is that assessed by the group, according to the EGI SVG issue handling procedure [R 7]  in the context of how 
the software is used in the EGI infrastructure. It is the opinion of the group, we do not guarantee it to be correct. 
The risk may also be higher or lower in other deployments depending on how the software is used.   

-----------------------------
This advisory is subject to the Creative commons license https://creativecommons.org/licenses/by/4.0/ and 
the EGI https://www.egi.eu/ Software Vulnerability Group must be credited. 
-----------------------------

Note that the SVG issue handling procedure is currently under review, to take account of the increasing 
inhomogeneity of the EGI infrastructure and the services in the EOSC-hub catalogue.

On behalf of the EGI SVG,