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?

Improve this question
3
  • 5
    Surely if someone has the ability to change your PATH variable, they are able to do much worse things?
    – Kat
    Nov 22, 2016 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, 2016 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, 2016 at 15:02

3 Answers 3

Reset to default
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)
Improve this answer
10
  • 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, 2016 at 17:08
  • 1
    @RobertFraser GAC is only for .NET ASSEMBLIES. Native DLLs are still searched by PATH.
    – Fabricio Araujo
    Nov 22, 2016 at 18:36
  • 2
    Linux also has PATH, and people use it all the time. What's with the 'cardinal sin'?
    – bmargulies
    Nov 22, 2016 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, 2016 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 cds to /tmp and runs ls, there you are.
    – Charles Duffy
    Nov 22, 2016 at 19:16
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...

Improve this answer
2
  • 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, 2016 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, 2016 at 7: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.

Improve this answer
3
  • 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, 2016 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, 2016 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, 2016 at 15:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .