IE11: CShdocvwBroker::MOTWCreateFileW EPM Local File Information Disclosure

[GoogleCodeExporter]

IE11: CShdocvwBroker::MOTWCreateFileW EPM Local File Information Disclosure
Platform: Windows 8.1 Update 32/64 bit, IE11 
Class: Information Disclosure

The method CShdocvwBroker::MOTWCreateFileW was already reported and supposedly 
fixed in CVE-2014-1777/MS14-035 however after finally taking a look it seems 
that the function still isn't correctly fixed.

For a start while the function now holds a lock over the checks those checks 
are still done using the original filepath and not the opened handle which 
somewhat defeats the point of opening the file. It's possible to do something 
like placing a junction in the directory hierarchy and switch it after the open 
so that any subsequent checks are done against a dummy file. This might be 
easier to exploit than it was originally.

A more simple issue to exploit is the second check after FileHasMOTW, which 
looks something like:

BOOL IsUrlFile(LPCWSTR lpFileName)
{
   LPCWSTR lpExt = PathFindExtension(lpFileName);

   return wcscmp(lpExt, L".url") == 0;
}

This doesn't seem that important, however it's possible to trivially exploit 
this by using an object manager symlink as the CreateFile call allows the NT 
namespace escape syntax (i.e. \\?\ or \\.\). All you need to do is create a 
symlink somewhere in the NT object manager namespace you can write to which has 
an extension of .url. This can then be pointed to any arbitrary file including 
things like devices or pipes. Still I wouldn't fix it by banning the escape 
syntax as it's possible to use something like a mount point to redirect from a 
filesystem directory into the object manager namespace to achieve the same 
effect. IMHO all verification of the MOTW'ness of the file should be done on 
the opened handled and only returned to the caller after they pass (such as 
reading the real opened file name from the handle). 

Provided is a PoC with 32 bit binaries and source. To test the PoC perform the 
following:

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 32 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) If successful a message box should appear indicating that bootmgr has been 
opened. If you inspect the handle table of the IE EPM process a handle to 
bootmgr for read access should be present. 

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 21 Nov 2014 at 11:51

Attachments:

• poc.zip

[GoogleCodeExporter]

Original comment by fors...@google.com on 22 Nov 2014 at 8:29

• Added labels: MSRC-21085

[GoogleCodeExporter]

Bulletin: https://technet.microsoft.com/library/security/MS15-009

Original comment by cev...@google.com on 10 Feb 2015 at 7:10

• Changed state: Fixed
• Added labels: CVE-2015-0055, Fixed-2015-Feb-10

[GoogleCodeExporter]

Remove view restriction

Original comment by fors...@google.com on 18 Feb 2015 at 8:26

• Removed labels: Restrict-View-Commit