Windows: AppInfo AiCheckSecureApplicationDirectory Bypass

[GoogleCodeExporter]

Windows: AppInfo AiCheckSecureApplicationDirectory Bypass
Platform: Windows 8.1 Update, Windows 7
Class: Security Bypass/EoP

Summary:
The AppInfo service handles requests for UAC elevation. There's an issue with 
the checking of secure directories which allows a  user to install a UIAccess 
application without requiring full access to a secure directory leading to the 
potential for EoP

Description:

When the AppInfo service launches a UIAccess or auto elevated application it 
checks that the location of the executable file is in certain secure 
directories. For example it checks \Windows and \Windows\System32 as well as 
Program Files. However because some directories are writable by normal  users 
it explicitly excludes them. This includes \windows\tasks and \windows\tracing. 
It turns out though that it's possible to get a file in the \windows directory 
which bypasses this check as a normal user as the tracing directory gives a 
user write permissions. This also means that a normal user can create a named 
stream on that directory, as this isn't a file under tracing it bypasses the 
checks in the AppInfo service. As in you can create c:\windows\tracing:abc.exe 
which isn't under tracing\ and therefore passes the check. A normal user can 
copy their UIAccess signed executable there, execute it (I think you need to 
talk to the RPC service directly) and you'll gain UIAccess permissions. 

I actually documented the attack on my blog, but I didn't mention an actual 
attack vector as I didn't check very hard, probably because the documentation 
such as http://technet.microsoft.com/en-us/library/jj852244(v=ws.10).aspx 
doesn't list the \Windows directory as a valid secure directory. By blog post 
is http://tyranidslair.blogspot.co.uk/2014/05/abusive-directory-syndrome.html 
for your information. 

No doubt you'll consider this a UAC issue and consider it not a problem, that's 
your decision. 

Proof of Concept:

I’ve provided a PoC which copies a signed file to the tracing directory then 
executes it to gain UIAccess permissions. 

1) Install the root_cert.cer file into the trusted root store. You need to do 
this as the UIAccess binary is signed with a key I created. You could resign 
using a real signing key if you like.
2) Execute the LaunchAdminProcess.exe file
5) The PoC should copy the file then execute it, you should see a message 
indicating that UIAccess has been granted. 

Expected Result:
It shouldn’t be possible to elevate privileges

Observed Result:
The executed file runs with UIAccess permission without general access to the 
Windows directory

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 15 Dec 2014 at 7:27

Attachments:

• poc.zip

[GoogleCodeExporter]

Microsoft indicate that they think probably won't have a bulletin. 

Original comment by fors...@google.com on 16 Dec 2014 at 11:04

• Added labels: MSRC-21233

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

As this is likely to be considered a UAC only bypass and might not be fixed I'm 
providing more context for potential issues.

When a UIAccess program executes it not only sets a special flag in the process 
token but it also increases the integrity level of the token. The IL increase 
is to bypass UIPI. How much of an increase depends on the type of user being 
elevated. For split-token administrators this increase is from Medium to High 
(the assumption being it needs to interact with elevated admin processes which 
also run at High IL). For a normal user the current IL is taken (so Medium is 
0x2000) and 0x10 is added to it. So the result of this increase is to elevate 
the IL to being just above the current IL, so in this case 0x2010. If you start 
a new UIAccess program from an existing one the IL is not increased. 

It's possible to circumvent this and allow a normal user to elevate their token 
to High IL by exploiting this situation. A normal user can drop their UIAccess 
privileges using the SetTokenInformation API. So by dropping UIAccess before 
creating a new process we can ratchet up the IL in 0x10 increments until we hit 
the maximum limit of High.

This has potential implications if there are resources which either do 
incorrect administrator checks using just the IL or resources which are marked 
with High IL. A simple example is the root of the C drive. On Windows 8.1 it 
has an IL label with the following SDDL options, (OI)(NP)(IO)(NW). This means 
that any object created inherits the IL (though not containers), the IL is only 
applied to inheritance and isn't propagated and finally a lower IL can't write 
to the resource. The DACL allows for files to be modified by normal users but 
restricts that through the IL. Therefore a normal user which can reach High IL 
can modify certain files in the root of the C drive, by default there's nothing 
of interest (bootmgr doesn't have the right DACL) but potentially other 
software might add files which are security critical. 

Original comment by fors...@google.com on 22 Jan 2015 at 2:05

[GoogleCodeExporter]

To address another potential concern with regards to the requirement that the 
file is signed with a trusted certificate it's sufficient to place the root 
cert into the current user's trusted root certificate store. It does not need 
to be in the local machine store. While the normal UI framework shows 
confirmation prompts they are not required or enforced by any higher privileged 
process. Therefore from an attacker perspective it would be possible for 
malicious code to register a trusted cert and perform the elevation without 
requiring administrator privileges. 

Original comment by fors...@google.com on 22 Jan 2015 at 2:05

[GoogleCodeExporter]

Correspondence Date: 10 Feb 2015

> Microsoft indicate that they do consider this a UAC issue so this doesn't 
meet the bar for a security bulletin. Changes might be considered for a future 
version of Windows.

Original comment by fors...@google.com on 11 Feb 2015 at 8:54

[GoogleCodeExporter]

Microsoft have confirmed that they will not be fixing this issue. Marking as 
WontFix and de-restricting. 

Original comment by fors...@google.com on 26 Feb 2015 at 6:41

• Changed state: WontFix
• Removed labels: Restrict-View-Commit