4 ms·

> The DLL file hasn't been kept up to date. For example, you can use .PS1 (PowerShell) embeds without any security warning. There's a lot of file types now yo

> The DLL file hasn't been kept up to date. For example, you can use .PS1 (PowerShell) embeds without any security warning. There's a lot of file types now you can execute code with without warning, basically. That's a poor example. Powershell scripts won't execute by default at all, and a lot of enterprise customers will only execute scripts signed by the internal CA. Off the top of my head I cannot think of too many new ways of running executable code. Microsoft has only been removing them, not adding news ones. Powershell is one of the few new ones and is designed from the ground up expressly not to allow this type of thing.

scott_karana 11y ago
Originally, Powershell did NOT have execution policy. And even in versions that do, it's also at the mercy of the invoking process, as I recall. Which is why he specifically said "powershell embeds without any security warning", I suspect. :| https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/ https://blog.netspi.com/15-ways-to-bypass-the-powershell-exe...
- hug 11y ago
  On an OS that is still under Microsoft support, all of those "bypasses" require: A) An argument to powershell.exe which Office will not supply when executing the ps1 file or B) Interacting with the powershell window after it's opened (which you can't do without already having some sort of code execution) or C) The execution policy being set to something that allows unsigned code. A and B are impossible, and C can be locked down with group policy to the point that local administrator rights can't bypass. Executing a ps1 with the appropriate parameters after executing something else may be possible, but also redundant.
- x0n 11y ago
  PowerShell execution policy is not a security layer/boundary. It's just a simple mechanism to stop people unintentionally shooting themselves in the foot; it won't stop other people intentionally shooting you in the foot.
- useerup 11y ago
  > Originally, Powershell did NOT have execution policy. Yes it did. It always had default execution policy to not allow scripts to execute. Not sure how it was set in the Monad days before PowerShell 1.0 was released, but for as long as it has been called PowerShell, execution policy has been part of it. On top of that, the .ps1 file extension is associated with notepad - not the PowerShell interpreter. When you "invoke" a ps1 file (like double-clicking it or have some program like outlook take default action), Windows will open notepad unless you explicitly associates .ps1 with another program.
  - gossitd 11y ago
    Yeah, this is my mistake when writing the advisory. For info, I did test it (with right extension) and it DOES work at some corps, who turn off signing (I know, I know). Additionally, you can use .js or .vbs to spawn Powershell command line with switch to turn off checking.
stephengillie 11y ago
It depends on the system. I've had installs where I had to enable execution, remote execution, and unsigned execution. Other systems run network-based scripts without any complaint.

scott_karana 11y ago

Originally, Powershell did NOT have execution policy. And even in versions that do, it's also at the mercy of the invoking process, as I recall. Which is why he specifically said "powershell embeds without any security warning", I suspect. :| https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/ https://blog.netspi.com/15-ways-to-bypass-the-powershell-exe...

hug 11y ago
On an OS that is still under Microsoft support, all of those "bypasses" require: A) An argument to powershell.exe which Office will not supply when executing the ps1 file or B) Interacting with the powershell window after it's opened (which you can't do without already having some sort of code execution) or C) The execution policy being set to something that allows unsigned code. A and B are impossible, and C can be locked down with group policy to the point that local administrator rights can't bypass. Executing a ps1 with the appropriate parameters after executing something else may be possible, but also redundant.
x0n 11y ago
PowerShell execution policy is not a security layer/boundary. It's just a simple mechanism to stop people unintentionally shooting themselves in the foot; it won't stop other people intentionally shooting you in the foot.
useerup 11y ago
> Originally, Powershell did NOT have execution policy. Yes it did. It always had default execution policy to not allow scripts to execute. Not sure how it was set in the Monad days before PowerShell 1.0 was released, but for as long as it has been called PowerShell, execution policy has been part of it. On top of that, the .ps1 file extension is associated with notepad - not the PowerShell interpreter. When you "invoke" a ps1 file (like double-clicking it or have some program like outlook take default action), Windows will open notepad unless you explicitly associates .ps1 with another program.
- gossitd 11y ago
  Yeah, this is my mistake when writing the advisory. For info, I did test it (with right extension) and it DOES work at some corps, who turn off signing (I know, I know). Additionally, you can use .js or .vbs to spawn Powershell command line with switch to turn off checking.

stephengillie 11y ago

It depends on the system. I've had installs where I had to enable execution, remote execution, and unsigned execution. Other systems run network-based scripts without any complaint.