20

I noticed that some folders in the PATH environment variable (e.g. C:\Python) give write privileges to anyone on the machine, including users without Admin rights. I understand that people can probably modify the Python executables and things in that folder. However, how dangerous is it if I don't use Python? Also, since most programs on Windows are called either through GUI or with absolute paths, could this issue still affect other more sensitive folders in PATH such as System32?

Jamal
  • 148
  • 1
  • 8
Shao Kun Deng
  • 309
  • 2
  • 3
  • 5
    Surely if someone has the ability to change your PATH variable, they are able to do much worse things? – Kat Nov 22 '16 at 19:18
  • Maybe you don't use python *directly*, note however that you could be using any number of programs which, under the hood, need python. If you look at "AskUbuntu" more than one guy was burned after trying to disinstall python and completely breaking the system... – Bakuriu Nov 23 '16 at 10:31
  • The risk, as @symcbean alludes, is for any command you execute (and possibly many DLLs). If the OS searches the path to find it, an attacker can substitute a malicious copy in any folder in the PATH. – jpaugh Nov 23 '16 at 15:02

3 Answers3

27

How dangerous is it if I don't use Python?

Your usage of Python is irrelevant to the risk.

The PATH variable provides a means to invoke programs without having to type in their full path. While Unix people would consider putting a publicly writable directory (or .) in the PATH variable a cardinal sin. The risk is that an attacker can substitute the program a user intends to run with their own evil code and thereby trick the victim into running it.

On MS Windows the risk is lower but its more difficult to mitigate:

  • most people don't use command lines in MS Windows
  • usually programs are started from the explorer which uses a full path to the executable
  • MS Windows always searches the current directory first before checking in %PATH% for an executable (i.e. the risk is baked into MS Windows by design)
AeroX
  • 103
  • 4
symcbean
  • 18,278
  • 39
  • 73
  • Isn't the PATH also used to load DLLs for .NET applications? I know a lot of .NET applications load shared libraries through the PATH, so you could theoretically inject malicious, non-signed binaries through the PATH. – Nate Diamond Nov 22 '16 at 17:08
  • @Nate - No. .NET searches the GAC, then probes several other places, notably the directory the application is located in. https://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.110).aspx – Robert Fraser Nov 22 '16 at 17:37
  • Visual C++ (compiled to .NET) libraries built with VS 2015 use shared Universal C Runtime references which are in C:\System32, retrieved from the PATH. I've just ran into this yesterday where we either had to copy the files to the output (as you're suggesting), add them to System32, or add their containing folder to the PATH. – Nate Diamond Nov 22 '16 at 17:41
  • 1
    @RobertFraser GAC is only for .NET ASSEMBLIES. Native DLLs are still searched by PATH. – Fabricio Araujo Nov 22 '16 at 18:36
  • 2
    Linux also has PATH, and people use it all the time. What's with the 'cardinal sin'? – bmargulies Nov 22 '16 at 18:42
  • 7
    @bmargulies, the "writable location" aspect is a cardinal sin -- and putting `.` in the PATH explicitly (at any location) is a rather substantial one as well. Folks who remember academic systems in the 70s (before expulsion and prosecution was accepted as a response to attacks on shared systems) might recall hundreds of common command typos being squatted on with names in `/tmp`, in the hopes that someone would `cd` there and typo `ls` as `sl`; the associated risks are real, even if improvements in common practice make them less exploitable today than they once were. – Charles Duffy Nov 22 '16 at 19:10
  • 7
    ...and that's assuming that folks had `.` at the *end* of their PATH; if they put it at the *beginning*, you could create a malicious `/tmp/ls`, and as soon as someone `cd`s to `/tmp` and runs `ls`, there you are. – Charles Duffy Nov 22 '16 at 19:16
  • OK, your wording mislead me to refer to PATH at all. – bmargulies Nov 22 '16 at 20:56
  • @CharlesDuffy: On Windows, it is just non sense to put `.` in path. The system searches first in the folder containing the executable, then in the current folder. The path is the last searched location after the system and windows folders. It if far from Unix best practices but it is *by design*. Anyway this question is tagged Windows-7 where `ls` is seldom used... – Serge Ballesta Nov 23 '16 at 07:29
  • “Your usage of Python is irrelevant to the risk” - I disagree somewhat, since people replacing the Python binary would also affect other people who start commands using full path. So there ware two aspects, nicely captured by two answers. Concentrate on the `PATH` aspect as you do, but perhaps refer to Serge's answer for the other aspect instead of claiming this to be a non-issue. – MvG Nov 23 '16 at 11:26
7

Disclaimer: OP's question is explicitely for Windows, so this answer only focuses on this system. For an Unix or Unix-like system the answer would be different.

The problem is not really that some folders in PATH are writable by anyone. The PATH is only a list of folders from which you can start a command with a simple name and not a full path.

But the fact that folders containing commands, be them in PATH or not, are writable by anyone is a security risk.

If the machine has no server service active, and if it is physically secured with only one single user, the risk may be acceptable: if you erase/rewrite a system file or any other executable, you should know why and nobody else than you can be to blame. But anyway best practices (as dicted by Windows) recomment that you are warned before doing a potentially dangerous task, so system folders should require admin privileges to be writable.

But if more than one person (administrators are not included here) can access the machine, then it becomes a serious security problem. One could voluntarily or not replace an executable or a DLL, and another one could launch an unwanted program when executing a Python script. Not speaking if System32 is publicly writable because any action could lead to unexpected results.

TL/DR: unless you are the only user of the machine, the Python folder should not be writable by all but should require admin priviledge.

On a Unix or Unix-like system, the problem will be different. First default installations normally never make folders containing executable publicly writable and the PATH is heavily used. So of course having a folder in PATH publicly writable would be per se a serious security problem. But Windows comes with different usages...

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • 1
    "in PATH" certainly escalates the level of risk. If a writable directory not on a `noexec`-mounted filesystem needs to have executables explicitly invoked, only a user intentionally executing a binary located there will be impacted. On the other hand, if it's in someone's PATH before `/usr/local/bin` (for instance), then any executable in `/usr/local/bin` can have a hostile version created in this directory, which will be run instead of whatever command a user really *intends* to invoke unless they explicitly pass the full path at invocation time. – Charles Duffy Nov 22 '16 at 19:14
  • @CharlesDuffy: I have `/usr/local/bin` neither in user path nor in system path. The folder is not even present on my machine, and I wonder whether it should be directly under C:\, or c:\Windows. Maybe under `c:\Users\[username]\AppData\Local`? More seriously OP's question was explicitely about Windows so I only focuses on Windows. But I have edited the answer to make it more clear... – Serge Ballesta Nov 23 '16 at 07:22
0

Yes, it can be a security risk if the proper GPO protections against running foreign executables are not in place (which is a grave security risk in itself).

By swapping out one PATH folder for another, you can trick a user into running a different executable than what they are trying to run. However if you have sensible GPO policies in place the most this would do is cause the user to annoy tech support for a few minutes because 'their' program won't run. And that's IF they are using batch scripts or commandline. Most users do not.

520
  • 723
  • 3
  • 5
  • 5
    "proper" and "sensible", as applied to group policy, are very context-specific. What's proper for your server is definitely not sensible for my development machine. – Ben Voigt Nov 22 '16 at 22:00
  • Yes but the vast majority of workplace machines are not dev or testing machines, and there aren't a whole lot of workplace situations where it is a good idea to have users run non-whitelist executables. – 520 Nov 23 '16 at 14:52
  • @520 Hello, and welcome! The OP mentions Python, so throw your assumptions out the window! :-) At the very least, it's good to make all assumptions explicit (as your comment does). You never know who will be reading your answer, or for what purpose. – jpaugh Nov 23 '16 at 15:05