CVE-2017-10129 : Detail

CVE-2017-10129

8.8
/
High
0.11%V3
Local
2017-08-08
13h00 +00:00
2024-10-04
19h00 +00:00
CVE.org
NVD
Notifications for a CVE
Stay informed of any changes for a specific CVE.
Notifications manage

CVE Descriptions

Vulnerability in the Oracle VM VirtualBox component of Oracle Virtualization (subcomponent: Core). The supported version that is affected is Prior to 5.1.24. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.0 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).

CVE Informations

Related Weaknesses

CWE-ID Weakness Name Source
CWE Other No informations.

Metrics

Metrics Score Severity CVSS Vector Source
V3.0 8.8 HIGH CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/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.

Changed

An exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component. In this case the vulnerable component and the impacted component are different.

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 4.6 AV:L/AC:L/Au:N/C:P/I:P/A:P [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 : 42426

Publication date : 2017-08-02 22h00 +00:00
Author : Google Security Research
EDB Verified : Yes

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1296 VirtualBox: Windows Process DLL UNC Path Signature Bypass EoP Platform: VirtualBox v5.1.22 r115126 x64 (Tested on Windows 10) Class: Elevation of Privilege Summary: The process hardening implemented by the VirtualBox driver can be circumvented to load arbitrary code inside a VirtualBox process giving access to the VBoxDrv driver which can allow routes to EoP from a normal user. Description: NOTE: I don’t know if you consider this an issue or not, however you fixed the last bypass I sent so it’s possible you still consider it a security boundary. This is a similar issue in impact to the one I reported in S0867394 but it uses a completely different mechanism. Once again we can use a current user COM registration to redirect the VBOX COM object to an arbitrary DLL path. However in this case rather than using MS signed code or abusing path behaviours in DLL library loading (and a bug in the hardening code) we'll instead abuse the way Windows handles image mapping from a kernel perspective. On Windows mapped DLLs use an Image Section under the hood. This is a special type of file mapping where the parsing and relocating of the PE file is all handled by the kernel. To allow for sharing of image mappings (so ideally the kernel only needs to do the parsing and relocation once) the kernel memory manager ties the file object to an existing section object by using a unique section pointer set by the file system driver. The interesting thing about this is the section pointer doesn't necessarily ensure the file hasn't changed, just that the file system considered the file the "same". Therefore it's possible that opening a file and reading it returns a completely different PE file than the one you'll get if you then map that file as an image section. If we can get a file mapped via one section pointer, then change the file underneath to be a different one we can exploit this. However on a default NTFS drive this isn't really possible due to things like sharing (outside of having admin privileges) so we need to use something different. For that we can use the SMB client file system. When you open a file via a UNC path any queries for the path return a MUP device path such as \Device\Mup\server\share\path\file.dll. When this is first mapped into memory the section pointer is used to refer to any file with that same path, however when opening the file the SMB client still needs to go to the server and receive the current data. Even with SMB supporting locking hopefully you can see that if you control the server as an admin then all bets are off with regards to returning the same data. In the worst case you could compile SAMBA with some custom code to do the attack (not that it would be needed). SMB also supports all the necessary file operations the hardening code checks for such as requesting the file Owner so we can pass all the checks with this. So to do the attack we can do the following: 1. Load our untrusted DLL from \\server\share\path\file.dll and map it into memory using something like LoadLibrary. This mapping needs to stay valid for the entire exploit to work. 2. Change the untrusted DLL file on the server to one which is a valid file for the hardening code and also has a owner set appropriately. 3. Add current user COM redirection to point VBOX class to the original UNC path. 4. Run VirtualBox. The hardening code will read the UNC path and find it's a valid file, however when the kernel maps the image section in NtMapViewOfSection it will find it's already got a mapped image loaded and will use that instead, the mapped image is of course the untrusted DLL, not the one the hardening code checked. 5. The untrusted DLL will be loaded into memory and executed. This is easy enough using a remote server but it would be more useful to exploit locally. For that we can use the default admin shares on a Windows system which expose the drives over SMB. Even though their primary purpose is for administration you don't need to be an administrator if you access them locally, you'll just get access just a the same user account. So we can do the redirection of the file access as follows: 1. Set up a path such as c:\poc somewhere on an NTFS drive and copy the untrusted DLL to that directory called vboxc.dll. 2. Create a mount point (a directory symlink) at c:\poc\dummy which redirects to c:\poc. 3. Map \\localhost\c$\poc\dummy\vboxc.dll. The SMB server will follow the mount point and open c:\poc\vboxc.dll, however from the client perspective (even though we're on the same machine) the file still thinks the original UNC path. 4. Change the mount point to c:\program files\oracle\virtualbox. Now when accessing the UNC path the file opened will be the real vboxc.dll file which is signed and has a trusted owner. The main reason this works is the fact that from a client perspective the filename never changes therefore the hardening code can't do much about it. The only way to tell the mapped file doesn't match the original would be to check the acual mapped image data as requesting its path using the memory manager would just return the UNC path. Ultimately I guess you probably shouldn't be trusting code on UNC paths. Proof of Concept: I’ve provided a PoC which will abuse the VBox COM Client loading process in source form. Prerequisites: Compile the supplied project in release mode using VS2015. I've only provided x64 version, it should work on x86 but I've not got anything to test it on. Then follow these steps: 1) Create the directory c:\poc and copy RunPoc.exe, NtApiDotNet.dll and the fake vboxc.dll to that directory. 2) Execute RunPoc.exe, it should print that it's successfully loaded the file. At this point DO NOT close the RunPoc executable as the file needs to stay mapped. 3) Start a VM. Each process the DLL is injected into will show a message box. This will include the protected VirtualBox.exe process. 4) When done testing hit enter in the RunPoc executable to ensure the keys get deleted. Expected Result: Untrusted DLL loading should fail inside a protected process. Observed Result: DLL is loaded into the protected process. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42426.zip

Products Mentioned

Configuraton 0

Oracle>>Vm_virtualbox >> Version To (including) 5.1.22

References

http://www.securityfocus.com/bid/99638
Tags : vdb-entry, x_refsource_BID
http://www.securitytracker.com/id/1038929
Tags : vdb-entry, x_refsource_SECTRACK
https://www.exploit-db.com/exploits/42426/
Tags : exploit, x_refsource_EXPLOIT-DB