Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Platform is Windows 7. I noticed that some folders in the PATH environment variable (e.g. C:\Python) give write privilege 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 path, could this issue still affect other more sensitive folders in PATH such as System32.

share|improve this question
    
Surely if someone has the ability to change your PATH variable, they are able to do much worse things? – Kat 11 mins ago

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 this 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 MSWindows the risk is lower but its more difficult to mitigate:

  • most people don't use command lines in MWindows
  • usually programs are started from the explorer which uses a full path to the executable
  • MSWindows always searches the current directory first before checking in %PATH% for an executable (i.e. the the risk is baked into MSWindows by design)
share|improve this answer
    
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 2 hours ago
    
@Nate - No. .NET searches the GAC, then probes several other places, notably the directory the application is located in. msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.110).aspx – Robert Fraser 1 hour ago
    
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 1 hour ago
    
@RobertFraser GAC is only for .NET ASSEMBLIES. Native DLLs are still searched by PATH. – Fabricio Araujo 52 mins ago
    
Linux also has PATH, and people use it all the time. What's with the 'cardinal sin'? – bmargulies 47 mins ago

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.

share|improve this answer
    
"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 14 mins ago

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.