search

ioasis / google-security-research

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

Windows: CreateObjectTask SettingsSyncDiagnostics Elevation of Privilege #437

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Windows: CreateObjectTask SettingsSyncDiagnostics Elevation of Privilege
Platform: Windows 8.1 Update (I don’t believe it’s available in earlier 
Windows versions)
Class: Elevation of Privilege

Summary:
The CreateObjectTask scheduled task initializes a user accessible system COM 
service which allows you to instantiate the SettingsSyncDiagnostics COM object. 
This object doesn’t take into account the caller when copying logs files 
leading to EoP.

Description:

The Microsoft\Windows\Shell\CreateObjectTask initializes a shell32 based 
ICreateObject COM server as local system. This is marked as being accessible 
from a normal user account so once created we can attach to it. The server only 
has one method, CreateObject which checks the CLSID against a list of known 
safe classes before allowing it to be instantiated. One of these classes is a 
diagnostic class for setting synchronization implemented in SettingSync.dll. 

This class allows an event log to be initialized with the StartLogging method 
and then the logs copied to an arbitary location with the StopLogging method. 
The StopLogging method doesn’t impersonate the caller when moving the logs to 
the user defined location which means it runs as local system. It’s possible 
to use this to copy the log files to arbitrary locations using appropriate 
symbolic link attacks. We can get data into the log file by sending trace 
events to the appropriate provider, this could allow string data to be added to 
the file. The name of the file is under attacker control so it can be renamed 
to .hta or .ps1 which would allow the limited control over the contents to be 
abused in error tolerant script engines. 

Another way of exploiting this takes into account that the SHFileOperations 
call which moves the file resets the ACLs (where applicable) on the file to 
match the expected inherited permissions. So for example you could drop the 
file as c:\program.exe and it would pick up the default DACL for C:\ (which 
allows Authenticated Users modify permissions) but the call doesn’t reapply 
the High IL label. This could be used indirectly in bad system services with 
unquoted file paths as the normal user could re-write the files contents to an 
malicious executable. A second trick with this is there’s a race between the 
move and the resetting of the ACLs. As the shell uses TreeSetNamedSecurityInfo 
it will also walk directory hierarchies, therefore by switching the symlink 
from the original target to a directory (say c:\users) you can force parts of 
the system drive to reset their ACLs, leading to the user being able to modify 
new parts of the file system which again could be exploited.. 

Exploitation is complicated somewhat by a bug in the proxy in actxprxy.dll. 
Presumably in the original MIDL file for the COM object the StopLogging method 
is incorrectly marked, the single WCHAR* parameter is missing the [string] 
attribute. This results in the built-in proxy only marshalling a single WCHAR 
to the server, this tends to cause things to not work so well and leads to a 
limited information disclosure as whatever’s after the single character in 
memory up to the next NUL is assumed to be part of the path. Fortunately the 
stub is sufficiently simple that by sending a plain array buffer to the server 
it’ll pick up the correct data. I’ve done this in the PoC by implementing 
my own custom COM proxy object. 

Proof of Concept:

The PoC demonstrates the vulnerability by copying the log file to the system 
drive. The password for the 7z file is ‘password’. 

1) Extract the PoC to a location on a local hard disk
2) As a normal user execute the PoC. 
3) The PoC should complete execution. 

Expected Result:
The log file should fail to be moved to the specified target.

Observed Result:
The log file ends up copied to c:\program.exe and can be modified by the 
current 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.

Original issue reported on code.google.com by fors...@google.com on 9 Jun 2015 at 6:17

Attachments:

GoogleCodeExporter commented 9 years ago 
Assigned MSRC case 30433

Original comment by fors...@google.com on 12 Jun 2015 at 10:42

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 3 Sep 2015 at 10:19

GoogleCodeExporter commented 9 years ago 
Fixed in https://technet.microsoft.com/library/security/ms15-102

Original comment by fors...@google.com on 9 Sep 2015 at 9:45

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 15 Sep 2015 at 9:31