Windows: Edge/IE Isolated Private Namespace Insecure Boundary Descriptor EoP
Platform: Windows 10 10586, Edge 25.10586.0.0 not tested 8.1 Update 2 or Windows 7
Class: Elevation of Privilege
Summary:
The isolated private namespace created by ierutils has an insecure Boundary Descriptor which allows any non-appcontainer sandbox process (such as chrome) or other users on the same system to gain elevated permissions on the namespace directory which could lead to elevation of privilege.
Description:
In iertutils library IsoOpenPrivateNamespace creates a new Window private namespace (which is an isolated object directory which can be referred to using a boundary descriptor). The function in most cases first calls OpenPrivateNamespace before falling back to CreatePrivateNamespace. The boundary descriptor used for this operation only has an easily guessable name, so it’s possible for another application to create the namespace prior to Edge/IE starting, ensuring the directory and other object’s created underneath are accessible.
In order to attack this the Edge/IE process has to have not been started yet. This might be the case if trying to exploit from another sandbox application or from another user. The per-user namespace IEUser_USERSID_MicrosoftEdge is trivially guessable, however the IsoScope relies on the PID of the process. However there’s no limit on the number of private namespaces a process can register (seems to just be based on resource consumption limits). I’ve easily created 100,000 with different names before I gave up, so it would be trivial to plant the namespace name for any new Edge process, set the DACL as appropriate and wait for the user to login.
Also note on IE that the Isolated Scope namespace seems to be created before opened which would preclude this attack on that type, but it would still be exploitable on the per-user one.
Doing this would result in any new object in the isolated namespace being created by Edge or IE being accessible to the attacker. I’ve not spent much time actually working out what is or isn’t exploitable but at the least you’d get some level of information disclosure and no doubt some potential for EoP.
Proof of Concept:
I’ve provided a PoC as a C++ source code file. You need to compile it first targeted with Visual Studio 2015. It will create the user namespace.
1) Compile the C++ source code file.
2) Execute the PoC as another different user to the current one on the same system, this using runas. Pass the name of the user to spoof on the command line.
3) Start a copy of Edge
4) The PoC should print that it’s found and accessed the !PrivacIE!SharedMem!Settings section from the new Edge process.
Expected Result:
Planting the private namespace is not allowed.
Observed Result:
Access to the private namespace is granted and the DACL of the directory is set set to a list of inherited permissions which will be used for new objects.
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.
