search

Temptationx / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

IE11 AudioSrv RegistryKey EPM Privilege Escalation #99

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The registry key HKCU\Software\Microsoft\Internet Explorer\Low Registry is 
created by IE during initialization. There existed a vulnerability in the way 
IE created keys under this key which was vulnerable to registry symbolic link 
attacks. The fix for CVE-2013-5045 was to add undocumented flags to the 
registry creation process to open the symbolic link instead of the destination.

However on closer inspection it seems that there are other users of this 
registry key. For example it's common to see an Audio key, this isn't created 
by IE but instead created by the Windows Audio service. At certain times (due 
to an RPC call from a user) the function CreateLowRightsRegistryKey will be 
called in audiosrv.dll. This function doesn't have the same protections as 
introduced in IE. It copies the DACL from the base key onto the Audio key so 
once the symbolic link has been followed the new key will be directly 
accessible by the low privileged process. 

The creation is done under impersonation so you cannot just directly call into 
Windows Audio to create the keys, you need to get a medium process to do it. 
One way I've found is to just run the sound mixer (sndvol) process, although 
this obviously displays a prompt in IE (this I used for the PoC for 
simplicity). It might be possible to use wmplayer (which is in the elevation 
policy) or just wait for something to occur which reloads the audio policy 
settings.

Attached is a PoC with 64 bit binaries and source. To test the PoC perform the 
following:

Before running the PoC ensure the "HKCU\Software\Microsoft\Internet 
Explorer\Low Rights" key is deleted. New Windows installations don't have this 
by default. It would be possible to work around but just complicates things. 

1) Copy injectdll.exe and testdll.dll to a directory.
2) Add ALL_APPLICATION_PACKAGES ACE to the directory to allow EPM to access the 
DLL
3) Ensure EPM is enabled in IE (and it's running 64 bit tabs).
4) Start desktop IE and navigate to an internet zone webpage. Right click the 
page and choose properties to verify page rendered with EPM
5) Find the PID of the EPM process then run 'injectdll pid testdll.dll'
6) IE will prompt for running a process, this is to start sndvol.exe, accept 
this dialog otherwise the PoC won't work. The reason for this is expediency, it 
ensures that the keys will be created in a timely manner, however I don't 
believe it's necessary. The mixer dialog should appear.
7) Close the mixer dialog, if successful the Windows calculator should now 
appear outside of the EPM sandbox. 

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.

Original issue reported on code.google.com by fors...@google.com on 25 Aug 2014 at 5:34

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 29 Aug 2014 at 2:22

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 11 Nov 2014 at 6:17

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 12 Nov 2014 at 11:05

GoogleCodeExporter commented 9 years ago 
MS bulletin: https://technet.microsoft.com/library/security/MS14-071

Original comment by cev...@google.com on 20 Nov 2014 at 1:09

GoogleCodeExporter commented 9 years ago 
This vulnerability is exploitable through a windows API "MessageBox"
Because the MessageBox will call MessageBeep, In win32k.sys MessageBeep will 
call the rpc which the endpoint is taskhost process. And the taskhost process 
run at medium integrity level.  taskhost process will call the rpc(the endpoint 
is audiosrv) to write the RegistryKey.

Original comment by progm...@gmail.com on 26 Mar 2015 at 3:06

Attachments:

GoogleCodeExporter commented 9 years ago 
Very interesting analysis thanks, I assumed there was probably a way of 
exploiting without a prompt but I didn't think it was worth the effort to go 
through the process of finding it.

Original comment by fors...@google.com on 26 Mar 2015 at 8:01