New issue
Advanced search Search tips
Starred by 2 users

Issue metadata

Status: Fixed
Closed: Mar 2017

Sign in to add a comment

Issue 1021: Windows: COM Session Moniker EoP

Reported by, Dec 5 2016 Project Member

Issue description

Windows: COM Session Moniker EoP
Platform: Tested on Windows 10 14393, Server 2012 R2
Class: Elevation of Privilege

When activating an object using the session moniker the DCOM activator doesn’t check if the current user has permission allowing a user to start an arbitrary process in another logged on user’s session.


The COM session moniker allows a user to specify the interactive session that’s to be used when a DCOM object is registered with an AppID with RunAs of “Interactive User”. As switching sessions is not something a normal user can do you’d assume that this would be only accessible to administrators (or at least with Impersonate/Assign Primary Token privilege). It turns out however that there’s no such restriction, this allows one user to instantiate a DCOM object inside another user’s session on the same machine (think Terminal Server or Fast User Switching).

The only restriction on the user then accessing that instantiated server is the specified Access DACL. The default Access DACL on a modern system only allows the user identity the server is running as as well as Administrators to access the created object. However there are a number of statically registered servers which allow the interactive user group (and who knows how many dynamically allowed ones through CoInitializeSecurity). I already described one these in my blog post of resurrecting dead processes, HxHelpPaneServer. With this object we can execute an arbitrary process in the context of the other user in their session.

Fortunately at least it's not possible to create an object in Session 0 (as far as I can tell) as that's not an interactive session.

Proof of Concept:

I’ve attached a proof of concept in C#. To test PoC use the following steps.

1) Create two users on the same machine.
2) Log on to both users to ensure account setup has completed. 
3) As one of the users execute the PoC, ensure it prints that it’s going to start a new process. Switch to the other user (without logging out the one running the PoC).
4) After about 20 seconds a copy of notepad should start on the other user’s desktop. Of course this could be any process including an arbitrary executable from the other user.

NOTE: Make sure these user’s are not administrators, or at least are split token administrators. If they’re the Administrator user which doesn’t run by default with a filtered token then the user will not be able to access the DCOM object due to High IL and executing the process will fail. That’s not to say it’s impossible to exploit that scenario, just more difficult.

Expected Result:
Using a session moniker for a session outside the current one should fail if not an administrator.

Actual Result:
DCOM object created in the specified session an arbitrary executable run as that user.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.
4.6 KB View Download

Comment 1 by, Dec 6 2016

Project Member
Labels: MSRC-36544

Comment 2 by, Jan 4 2017

Project Member
Labels: Deadline-Grace
MSRC have requested the grace period extension aiming to fix on March 2017 PT.

Comment 3 by, Mar 14 2017

Project Member
Labels: -Restrict-View-Commit CVE-2017-0100
Status: Fixed (was: New)
As this is already past deadline derestricting. 

Fixed in

Comment 4 by, Mar 15 2017

A very interesting discovery, James. As usually, I'm interested in fixing (although MS has already patched it). Would you agree that preventing BindToMoniker from returning a valid server object for someone else's session if you're not an admin has to be implemented in the kernel (where system permissions are always checked)?

Comment 5 by, Mar 22 2017

Project Member
mitja.kolsek@ well imo the correct fix should prevent a normal user creating COM objects in other interactive sessions on the same machine. However it turns out that's not what MS did and it looks like they just fixed the behavior of HxHelpPaneServer. Oh well :-)

Sign in to add a comment