CVE-2015-2554 : Détail

CVE-2015-2554

A01-Broken Access Control
12.24%V3
Local
2015-10-13
23h00 +00:00
2018-10-12
17h57 +00:00
CVE.org
NVD
Notifications pour un CVE
Restez informé de toutes modifications pour un CVE spécifique.
Gestion des notifications

Descriptions du CVE

The kernel in Microsoft Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT Gold and 8.1, and Windows 10 allows local users to gain privileges via a crafted application, aka "Windows Object Reference Elevation of Privilege Vulnerability."

Informations du CVE

Faiblesses connexes

CWE-ID Nom de la faiblesse Source
CWE-264 Category : Permissions, Privileges, and Access Controls
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.

Métriques

Métriques Score Gravité CVSS Vecteur Source
V2 7.2 AV:L/AC:L/Au:N/C:C/I:C/A:C [email protected]

EPSS

EPSS est un modèle de notation qui prédit la probabilité qu'une vulnérabilité soit exploitée.

Score EPSS

Le modèle EPSS produit un score de probabilité compris entre 0 et 1 (0 et 100 %). Plus la note est élevée, plus la probabilité qu'une vulnérabilité soit exploitée est grande.

Percentile EPSS

Le percentile est utilisé pour classer les CVE en fonction de leur score EPSS. Par exemple, une CVE dans le 95e percentile selon son score EPSS est plus susceptible d'être exploitée que 95 % des autres CVE. Ainsi, le percentile sert à comparer le score EPSS d'une CVE par rapport à d'autres CVE.
EPSS First.org

Informations sur l'Exploit

Exploit Database EDB-ID : 38580

Date de publication : 2015-10-29 23h00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes

Source: https://code.google.com/p/google-security-research/issues/detail?id=483 Windows: NtCreateLowBoxToken Handle Capture Local DoS/Elevation of Privilege Platform: Windows 8.1 Update, Windows 10, Windows Server 2012 Class: Local Dos/Elevation of Privilege Summary: The NtCreateLowBoxToken API allows the capture of arbitrary handles which can lead to to local DoS or elevation of privilege. Description: The NtCreateLowBoxToken system call accepts an array of handles which are stored with the new token. This is presumably for maintaining references to the appcontainer specific object directories and symbolic links so that they do not need to be maintained anywhere else. The function, SepReferenceLowBoxObjects which captures the handles has a couple of issues which can lead to abuse: 1) It calls ZwDuplicateObject which means the API can capture kernel handles as well as user handles. 2) No checks are made on what object types the handles represent. The fact that kernel handles can be captured isn’t as bad as it could be. As far as I can tell there’s no way of getting the handles back. The second issue though is slightly more serious as it allows a user to create a reference cycle to kernel objects and potentially maintain them indefinitely, at least until a reboot. One way of doing this is to exploit the fact that threads can be assigned impersonation tokens. For example a new thread can be created and the handle to that thread captured inside the lowbox handle table. The resulting lowbox token can then be assigned as an impersonation token, the thread and token now maintain their references and the kernel objects survive the user logging out. As the thread references the process this also maintains the process object. Now at the point of logging out the process will be terminated but because the token maintains the reference cycle the process object itself will not go away. This can lead to a few results: 1) A user could open handles to important resources and files and prevent the handles getting released. This could ultimately result in a local DoS (although only something like a terminal server would be affected) and the administrator wouldn’t easily be able to fix it without rebooting as the process becomes hidden from typical task managers and trying to terminate it won’t help. 2) If a user logs out then back in again they can reopen the process (by PID or using NtGetNextProcess) and get access to the original process token which is still marked as having the original session ID (something which would normally require TCB privilege to change). This might be exploitable to elevate privileges in some scenarios. While the session object still exists in the kernel due to the reference cycle, it is dead so trying to create a process within that session will not work, however the user could release the reference cycle by clearing the thread’s impersonation token which will let session object be cleaned up and allow another user (again think terminal server) to login with that session ID. The user could then create a process in that session indirectly by impersonating the token and using something like the task scheduler. It isn’t immediately clear if the user would be able to access the session’s desktop/window station due to its DACL, but at the least references to the sessions object directory could be maintained (such as DosDevices) which might allow the user to redirect named resources for the user to themselves and get the privileges of the other user. This would be particularly serious if the other user was an administrator. Proof of Concept: I’ve provided a PoC which will cause the reference cycle and display the process if it can open one. The archive password is ‘password’. Follow these steps: 1) Extract the PoC to a location on a local hard disk which is writable by a normal user 2) Execute the poc executable file 3) The user should be automatically logged out 4) Log back in as the user 5) Execute poc again, it should now print out information about the stuck process and the extracted process token. Expected Result: It shouldn’t be possible to generate a kernel object reference cycle Observed Result: The reference cycle is created and the user can reopen the process. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38580.zip
Exploit Database EDB-ID : 44914

Date de publication : 2018-06-19 22h00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes

Windows: Desktop Bridge Activation Arbitrary Directory Creation EoP Platform: Windows 10 1703, 1709 (not tested RS4) Class: Elevation of Privilege Summary: The activator for Desktop Bridge applications calls CreateAppContainerToken while running as a privileged account leading to creation of arbitrary object directories leading to EoP. Description: As much of the activation of Desktop Bridge applications require TCB privilege (such as creating the container) it’s delegated to the AppInfo service which runs as Local System. During post activation, either through RAiLaunchProcessWithIdentity or RAiFinishPackageActivation the API PostCreateProcessDesktopAppXActivation is called in daxexec which sets up various things. One of those things is registering the process with the Process State Manager service and to do that it passes an AppContainer token for the AppX package. To create the token the service will call the API CreateAppContainerToken, however it doesn’t impersonate the user while doing this which results in the service setting up the AppContainer object directories as the process user. By placing symbolic links into these locations arbitrary object directories can be created, as long as the parent directory can be written by Local System. The created directories are also given an explicit DACL which grants the user access so that they can also be written to by the original user once created. On Windows 8.1 this would be trivial to exploit as NtCreateLowBoxToken didn’t care what handles you passed it for capture, however since CVE-2015-2554 (which I reported) the system call checks that the directories are under the AppContainerNamedObjects directory for the user. They’re still created but once NtCreateLowBoxToken is called they’ll be closed again. However due to the way kernel objects persist it just becomes a race condition, as long as you open the directory you want before all handles are closed then you can keep it alive to do what you need to do with it. In practice it seems to be possible to capture the directory reliably but perhaps only on multi core systems. IMO this might be best to fix in CreateAppContainerToken, perhaps by impersonating the base token which is being used to create the lowbox one. I’ve tried to track down cases before where this function is called inappropriately and it wouldn’t surprise me if there’s more bad callers for this function as impersonation can be tricky to get right, especially when hidden behind RAI C++ classes. As an aside it’s also worth noting that this type of bug is of more general application to the session 0 AppContainerNamedObjects directory. That directory granted access to the Everyone group to write to it as shown below. PS C:\> $d = Get-NtDirectory \Sessions\0\AppContainerNamedObjects PS C:\> $d.SecurityDescriptor.Dacl Type User Flags Mask ---- ---- ----- ---- Allowed Everyone None 0002000F Allowed NT AUTHORITY\SYSTEM None 000F000F Allowed NT AUTHORITY\RESTRICTED None 00000002 Allowed APPLICATION PACKAGE AUTHORI... None 00000003 Allowed APPLICATION PACKAGE AUTHORI... None 00000003 Allowed NT AUTHORITY\SYSTEM ObjectInherit, Co... 10000000 Previously nothing used it in Session 0 but in a recent update the UMFD process spawns in Session 0 as an AC and so the directories would be created by a system process which could be redirected. I’m not sure that’s very useful but it’s something which you might also want to fix. Proof of Concept: I’ve provided a PoC as a C# project. As it’s a race condition it should be run on a multi-core machine to give the threads a chance to capture the directory object. It might work on a single core as well but I’ve not tested it. If it fails to get the directory try it again as it’s possible that the race wasn’t successfully won. It uses the My Office application as with previous exploits, if it’s not installed then the PoC will fail. However it doesn’t need a specific Desktop Bridge application just any installed will do though you’d have to modify the package information in the PoC to do so. The PoC will try and create the folder \Blah in the object manager namespace. 1) Compile the C# project. It will need to grab the NtApiDotNet from NuGet to work. 2) Run the PoC, if the PoC says that OfficeHub is already running ensure it’s closed. 3) If a dialog appears saying the application has failed to start click OK. 4) The poc should print whether it captured the directory and if so what access was granted. Expected Result: Create of the application should fail and the directories are not created. Observed Result: The directories are created, the application will still fail. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44914.zip

Products Mentioned

Configuraton 0

Microsoft>>Windows_10 >> Version -

Microsoft>>Windows_7 >> Version -

Microsoft>>Windows_8 >> Version -

Microsoft>>Windows_8.1 >> Version -

Microsoft>>Windows_rt >> Version -

Microsoft>>Windows_rt_8.1 >> Version -

Microsoft>>Windows_server_2008 >> Version -

Microsoft>>Windows_server_2008 >> Version r2

Microsoft>>Windows_server_2008 >> Version r2

Microsoft>>Windows_server_2012 >> Version -

Microsoft>>Windows_server_2012 >> Version r2

Microsoft>>Windows_vista >> Version -

Références

http://www.securitytracker.com/id/1033805
Tags : vdb-entry, x_refsource_SECTRACK
https://www.exploit-db.com/exploits/38580/
Tags : exploit, x_refsource_EXPLOIT-DB
http://www.securityfocus.com/bid/76998
Tags : vdb-entry, x_refsource_BID