Now and then I tend to run some of the excellent tools from Sysinternals. Recently, I noticed something odd. It seems like Windows was searching for executables and DLLs in a Java folder. What made it even more interesting was that this folder is located within the
ProgramData folder. The default NTFS ACLs allows local user to create new files within this folder. These are ingredients for local privilege escalation.
Further investigation showed that this issue was introduced around the release of Java SE 8 Update 20 for Windows. I discovered that this issue was already addressed by a recent version of Java SE. I confirmed that Java SE 8 Update 40 removes the weak NTFS ACLs from the affected folder (it may have been addressed in an earlier version). Due to this it is no longer possible for local unprivileged users to creating new files in this folder. I performed some Google searches and could not find any information about this change/fix. I guess it must have been found internally by Oracle. In this article I'll explain how this issue can be used to escalate privileges locally.
Vulnerability details - unsafe JRE installation
When installing Java SE 8 on a Windows system, the installer will create the folder
%ProgramData%\Oracle\Java\javapath (if it does not exist). The
javapath folder contains symlinks to the executables
javapath symlinks to Java executables
The NTFS permissions are inherited from the parent folder. By default any local unprivileged user is allowed to create new files within the
javapath folder. It is not possible to modify the Java symlinks.
Figure 2: NTFS permissions of
Users group on
Creating new files in
javapath is not an issue per se. In this case it can result in code being executed as a different user. This is possible because the JRE installer not only creates the
javapath folder, but this folder is also added to the
PATH environment variable. It is even added as the first entry of the
PATH. This means that when Windows searches
PATH, Windows will look in
javapath added to the
PATH environment variable
Running code as a different user
Abusing this issue allows us to run our own executable code with the privileges of another (system) user. Process Monitor can be used to find applications that load executable code from the affected Java folder. We can create a filter in Process Monitor to only show path operations on the
javapath folder. Potential targets are shown in the Process Name column.
Figure 4: using Process Monitor to find potential targets
Using this method we can find affected applications that are started by other users and also system processes (services) that are affected by this issue. I've chosen Windows Media Player and Microsoft Distributed Transaction Coordinator Service as target applications.
When Windows Media Player is started it will look for the DLL file
rapi.dll in the
PATH. If such a file is present in
javapath, Windows Media Player will try to load this DLL. An attacker can place a malicious DLL named
javapath and wait for a user to launch Windows Media Player, causing the attacker's DLL to be executed with the privileges of that user. It may even be possible to trick a user to do so by sending this user a link/file that will cause Windows Media Player to be opened.
Figure 5: malicious
rapi.dll loaded in Windows Media Player opening
A similar attack is possible against the Microsoft Distributed Transaction Coordinator Service. The Microsoft Distributed Transaction Coordinator Service tries to load the DLL
oci.dll from the
PATH. It is possible to abuse this to run arbitrary code with
NETWORK SERVICE privileges, as is shown in figure 6.
backdoor.exe running with
NETWORK SERVICE privileges