Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DLL hijack in Sublime Text 3 version 3.1.1 build 3176 win 32 bit #2544

Closed
followboy1999 opened this Issue Jan 4, 2019 · 20 comments

Comments

4 participants
@followboy1999
Copy link

followboy1999 commented Jan 4, 2019

Description

Sublime Text 3 version 3.1.1 build 3176 allows local users to gain privileges by creating a
C:\Users\username\AppData\Local\Temp\any_name folder and then copying a Trojan horse api-ms-win-core-fibers-l1-1-1.dll or api-ms-win-core-localization-l1-2-1.dll file into this new folder, then creating test.txt and opening it with sublime_text.exe aka DLL Hijacking

Steps to reproduce

  1. First step
    Create a new C:\Users\username\AppData\Local\Temp\sublime_text folder and then create a file named test.txt in this folder
  2. Second step
    Copy a Trojan horse api-ms-win-core-fibers-l1-1-1.dll or api-ms-win-core-localization-l1-2-1.dll file into sublime_text folder
  3. Third step
    Open text.txt by using sublime_text.exe

Expected behavior

Load the calc.exe when open the text.txt

Actual behavior

Load the calc.exe when open the text.txt

Environment

Operating system and version:
Windows 7 (Version 6.1 Service Pack 1) 32
Sublime Text:
Build 3176
32 bit

@FichteFoll

This comment has been minimized.

Copy link
Member

FichteFoll commented Jan 4, 2019

I'd like to think this is critical, but attackers can have ST execute any arbitrary Python code by placing a Python plugin into the user's Packages folder.

@wbond

This comment has been minimized.

Copy link
Member

wbond commented Jan 4, 2019

Considering this requires modifying files in the Sublime Text install directory, couldn't the attacker just modify sublime_text.exe to include a trojan? Or as @FichteFoll suggested, install arbitrary Python modules to be loaded by the plugin_host.exe (this only requires user permissions), or even overwrite the Python33.zip and hijack the entire Python stdlib?

I personally wouldn't consider this to be a critical severity. DLL injection is a feature of Windows, and there are multiple layers of protection to prevent it from happening, including UAC and anti virus software.

@FichteFoll

This comment has been minimized.

Copy link
Member

FichteFoll commented Jan 5, 2019

Oh sorry, I thought the dlls were to be placed into C:\Users\username\AppData\Local\Temp\sublime_text, which wouldn't require privileges but could then potentially be elevated by someone launching ST with admin privileges. However, this is still the same attack vector as any custom Python plugin.

Definitely not critical and not in a position to declare a "wontfix".

@followboy1999

This comment has been minimized.

Copy link
Author

followboy1999 commented Jan 5, 2019

I think it is critical,
One, place any plugins into the user's Packages folder needs administrator right, but this attack doesn't need a administrator user, just need a normal local user.
Two, the api-ms-win-core-fibers-l1-1-1.dll or api-ms-win-core-localization-l1-2-1.dll is just loaded by sublime_text.exe not plugin_host.exe.

@followboy1999

This comment has been minimized.

Copy link
Author

followboy1999 commented Jan 5, 2019

You can check these dlls named api-ms-win-core-*.dll all are in system32 folder, but the api-ms-win-core-fibers-l1-1-1.dll or api-ms-win-core-localization-l1-2-1.dll are not, so attacker just needs put the Trojan dll and file that needs user open by using sublime_text.exe in the same folder whatever where it is. By the way, this can bypass UAC.
About DLL Hijacking, you can check this.
https://resources.infosecinstitute.com/dll-hijacking-attacks-revisited/#

@FichteFoll

This comment has been minimized.

Copy link
Member

FichteFoll commented Jan 5, 2019

Thanks for that link; it clarifies a lot. Going through that, it seems I was indeed right about my initial assumption of the dlls being placed in the custom folder rather than the application folder where ST is launching from (not in!).
It appears the solution for this kind of attack is to enable SafeDllSearchMode, which will move the priority of looking for dll's in the current directory (!) from second to fifth.

Seems like a somewhat easy fix and covers a different attack vector where even if the plugin path is unwritable (for some reason), just being able to launch ST from a compromized directory exposes this vulnerability.

@deathaxe

This comment has been minimized.

Copy link

deathaxe commented Jan 5, 2019

... place any plugins into the user's Packages folder needs administrator right ...

Don't think that's true as %APPDATA%\Sublime Text 3 has write access for the owning user. No need for administrator privileges.

@deathaxe

This comment has been minimized.

Copy link

deathaxe commented Jan 5, 2019

Btw. this is an issue which was discussed years ago and covers all Win programs in the one or the other way.

@wbond

This comment has been minimized.

Copy link
Member

wbond commented Jan 22, 2019

I've tried to reproduce this issue, but I've been unable to so far. I've tried moving the Python33.dll into the working dir, and Sublime Text doesn't launch properly. This seems to imply it is not trying the working dir.

I've also tried placing dlls with the suggested names in the working dir, but been unable to reproduce the issue. I've tried both 32bit and 64bit on Windows 10.

@deathaxe

This comment has been minimized.

Copy link

deathaxe commented Jan 22, 2019

If Sublime Text does not specify absolute paths for dlls to load (what I expect) it is up to the Operating System to lookup the required DLLs and load them.

The load order is outlined in chapter Standard Search Order for Desktop Applications at https://docs.microsoft.com/en-us/windows/desktop/Dlls/dynamic-link-library-search-order

According to the initial post of this issue the SafeDllSearchMode seems disabled, which would enable loading DLLs from the current directory as described.

Windows XP: Safe DLL search mode is disabled by default. To enable this feature, create the SafeDllSearchMode registry value and set it to 1. Safe DLL search mode is enabled by default starting with Windows XP with Service Pack 2 (SP2).

@wbond

This comment has been minimized.

Copy link
Member

wbond commented Jan 22, 2019

@deathaxe I’ve read the report and all of Microsoft’s documentation and various other bits about DLL hijacking on StackOverflow and a number of security websites. I know what API call should prevent the possibility of DLL hijacking via the working directory, however I have yet to be able to reproduce the attack, thus I can’t be sure the mitigation’s outlined are actually working.

Have you been able to reproduce the issue?

Perhaps Windows 10 is preventing such an issue? I can pull out my old VM of XP, but it is fully patched, so it won’t show ancient vulnerabilities such as the safe mode being disabled.

@deathaxe

This comment has been minimized.

Copy link

deathaxe commented Jan 22, 2019

Tried with a copy of the original api-ms-win-core-fibers-l1-1-1.dll copied to the C:\user...\temp directory as well as moving python33.dll and msvcrt100.dll there.

Moving python33.dll thows an error upon startup. msvcrt100.dll just falls back to c:\windows\system32\msvcrt100.dll. Can't see the first one to be queried at all.

Procmon shows some dlls to be looked up in the application directory, but nowhere else, but the system32 directory or any other valid Windows path.

Note: Windows 10 1803 x64

To be honest - I don't trust the statement of WinXP SP2+ being safe. I can remember this topic to have been discussed as heavy Windows security issue in 2012 or something like that. So even early Win7 setups could be vulnerable.

@deathaxe

This comment has been minimized.

Copy link

deathaxe commented Jan 22, 2019

Did you read https://support.microsoft.com/en-us/help/2389418/secure-loading-of-libraries-to-prevent-dll-preloading-attacks?

To prevent this attack, applications can remove the current working directory (CWD) from the DLL search path by calling the SetDllDirectory API by using an empty string (“”).

Maybe the following statement applies to python dlls / plugins *.pyd

An application that loads third-party plugins and that cannot force the plugins to use a qualified path for its LoadLibrary calls should call SetDllDirectory(“”) to remove CWD and then call SetDllDirectory(“plugin install location”) to add the plugin install directory to the DLL search path.

Would probably be an approach to "harden" ST against such attacks on older systems. Loading from CWD is not needed at all, I think.

@wbond

This comment has been minimized.

Copy link
Member

wbond commented Jan 22, 2019

@deathaxe The safe mode just moves the CWD check lower in the order, and yes as I stated above I did read Microsoft's documentation about the issue.

I've since been able to reproduce the CWD load on Windows XP. It appears Windows 10 prevents such an attack. Unfortunately so far the SetDllDirectory() call has not helped, but since this is an implicitly loaded dependency of system dlls, I imagine they are loaded pretty early in the process execution.

@deathaxe

This comment has been minimized.

Copy link

deathaxe commented Jan 22, 2019

I've since been able to reproduce the CWD load on Windows XP

Not surprising.

implicitly loaded dependency of system dlls

... which windows should manage in its "knowndlls" list and use in the first place anyway.

Most discussions about this topic seem to cover the LoadLibrary function, with the advice to use absolute paths as arguments only to prevent dll hijacking.

@wbond

This comment has been minimized.

Copy link
Member

wbond commented Jan 22, 2019

... which windows should manage in its "knowndlls" list and use in the first place anyway.

Right, but according to this bug report there are certain DLLs that aren't? Are we chasing bugs that have been patched by the OS long ago?

@deathaxe

This comment has been minimized.

Copy link

deathaxe commented Jan 22, 2019

Honestly, I think so.

@deathaxe

This comment has been minimized.

Copy link

deathaxe commented Jan 22, 2019

This is / was a design issue of Windows

@deathaxe

This comment has been minimized.

Copy link

deathaxe commented Jan 23, 2019

Tried to reproduce on a Windows 7 x64 with up to date patch level without any success as well.

@wbond wbond added R: invalid and removed unconfirmed labels Jan 31, 2019

@wbond

This comment has been minimized.

Copy link
Member

wbond commented Jan 31, 2019

This does not appear to be a bug with Sublime Text, but rather one with Windows that has been patched.

Since the DLLs in question are indirect dependencies of system DLLs that are loaded at program execution, the recommended (by Microsoft) approach of SetDllDirectory() does not work since the dependencies are loaded before main() is executed.

I confirmed that this vulnerability does exist on Windows XP, but it does not appear to be something we can prevent, and Windows XP is long since EOL'ed. A patched version of Windows 7 does not seem to be vulnerable.

@wbond wbond closed this Jan 31, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.