0

❔ Enable native/direct execution of .ps1 scripts - Warnings / Considerations

Intro: Recently, I have been doing a lot more scripting, both in PowerShell (.ps1) and Console/Shell (.cmd/.bat). I recognised that PowerShell is arguably a much more powerful / versatile scripting language, however I always found the ability to directly run a .cmd/.bat file (i.e. C:> MyCmd) quite appealing (compared the relatively cumbersome C:> powershell.exe -NoLogo -NoProfile -File "C:\Specify_the_full_path_to_my_powershell_folder\MyScript.ps1". Today I happened to notice the %PATHEXT% system variable and thought to myself: "Could it be that simple!?" (just add .ps1 to the list of extensions?) - It was! (for more info on how to do this, see the Linked question below, or click how to enable direct/native running of .ps1 files).

The relative ease of enabling this made me pause and wonder however...

  • Microsoft make Windows
  • Microsoft make PowerShell (and are actively driving the development of pwsh across multiple platforms)
  • Microsoft have enabled 10+ extensions to be run directly: .com .exe .bat .cmd .vbs .vbe .js .jse .wsf .wsh .msc (several of which I have never even heard of!)

(Main question) Which forces me to ask...

  • Why did Microsoft exclude .ps1 files from PATHEXT (i.e. stop them being run directly)!? (This seems like an obvious thing Microsoft would want to do)
  • Are there any reasons why people should not do this?
  • Any other downsides or disadvantages of doing this?

I feel like there is some obvious/major downside I must be over-looking, but can't think what that is. Yes, you could argue it is more risky / it's safer to load a PowerShell script into say PowerShell ISE and run it from there, but you could make that same statement for a .bat file - so would suggest there are some other reason(s) why running .ps1 scripts is not recommended.

Any advice would be greatly appreciated, thanks in advance! 👍🏼



🔁 Linked question: Enable direct/native running of .ps1 files — How To

Click here for a step-by-step guide on how to enable direct running of .ps1 files (assuming the answers do this question don't show that this is absolutely something you should never do)

4
  • 1
    Why did Microsoft exclude .ps1 files from PATHEXT .. like you assumed.. for security. I'll give you a tip.. :) .. I myself have added .LNK files so I can run shortcuts without extensions. It is a risk that I myself am willing to take but the average user is not able to make an informed decision about this and would probably either run a virus or shoot themselves in the foot. Jun 2 at 22:23
  • 1
    .ps1 are pointed to notepad for a reason. It was not an arbitrary decision by Microsoft. Double-click to run .hta/.cmd/.bat/.vbs is how hack infections/takeovers truly took off. PowerShell (access to all of . Net) is far more powerful by design than the aforementioned. Why open yourself to that? You have organizations/enterprises worldwide locking down PowerShell actions, specifically to control this post-exploit attack vector. In every org/ent I support, if an individual did such a thing; it's grounds for termination. If you are doing this on your own machine, that's your choice.
    – postanote
    Jun 3 at 5:05
  • CMD.exe is not PowerShell. It is a program and only this program uses pathext. It is not a general Windows thing. I would guess that cmd,exe is on care and maintence so no new features. The last features to CMD.exe were done in 2000. Jun 4 at 7:16
  • @postanote - Thanks for the info.. NB: I tried to search what you put in bold ("double-click..." but didn't really find an article that explained it, I would be curious to learn more though if you can share any specific links (intro-level is poss, I don't know what a 'HTA' is for example). RE: Notepad, lol this is one of the first things I change when I re-install Windows (always thought this should default to powershell_ise). RE: Context, appreciate that... FYI the question assumes personal context/moderate user (am not suggesting all orgs and governments enable PowerShell by default).
    – Martin
    Jun 4 at 10:46
1

Why did Microsoft exclude .ps1 files from PATHEXT (i.e. stop them being run directly)?

As already pointed out in the comments, likely security. PowerShell is a relatively capable automation tool with a number of built-in Cmdlets, including ones that can affect Windows or be used to download files from the internet.

Disabling PowerShell by default helps prevent it from running on PCs that may not even want it to run scripts (e.g. an average desktop user, or some security admin who probably doesn't want it downloading malware from random URLs.)

Running malicious scripts because a user doesn't know better is an exceptionally common attack vector. It's generally far easier to fool someone into doing this than it is to actually a break device or program's security (or use other exploits). If you must enable PowerShell manually, it ensures that at least you know there is a possibility it could be running scripts on your system (ideally allowing you to choose your own level of risk).

Are there any reasons why people should not do this? Any other downsides or disadvantages of doing this?

Any downsides would probably all be primarily security-related.


Other Stuff

However, I always found the ability to directly run a .cmd/.bat file (i.e. C:> MyCmd) quite appealing.

You can (potentially) shorten your example PowerShell command by quite a bit:

  1. Create some folder of your choice (e.g. C:\CLI) and place it in your System PATH variable.

  2. Create a batch file called e.g. ps.bat in that folder with something like the following:

    powershell.exe -NoLogo -NoProfile -File %*
    
  3. Run your PowerShell script(s) with this batch file and the "current directory" shorthand of .\, assuming you are in the same directory as your .ps1 script at the command line:

    ps .\MyScript.ps1
    
3
  • Thanks, makes sense... Admittedly, it still doesn't quite tally in my head (i.e. it seems that a user could just as easily download a .cmd, .bat (or even .exe) file that could maliciously affect Windows / damage their computer, but it is starting to be a bit clearer -- like you say, PowerShell includes cmdlets and modules that enable access to a wide range of system files and settings. (PS - I trusted that things like PS ExecutionPolicy safe-guarded a large variety of this, but maybe it's not that secure)... Anyway, thanks for your answer, appreciate your info! 👍🏼
    – Martin
    Jun 4 at 10:36
  • Also, good tip with powershell.exe -NoLogo -NoProfile -File %*... Lol, TBH I have done exactly this with half-dozen other programs already, so I don't know why I never thought to do this with PowerShell itself! (d'oh) 🤦🏼‍♂️... Thanks again 👍🏼
    – Martin
    Jun 4 at 10:38
  • You're welcome. =) For what it's worth, there are definitely other security threats beyond PowerShell. But I think there is likely a tradeoff here between usability and security by Microsoft. For instance, batch is common enough and has existed long enough in an insecure state that it's generally expected to "just work". PowerShell, on the other hand, is relatively "newer" (it wasn't even widely distributed as part of Windows until 2009) and more powerful. So Microsoft probably feels more comfortable placing additional safeguards on it (i.e. not much negative response from customers). Jun 4 at 17:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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