DOS or not? [was Re: How to tell Script to use pythonw.exe ?]

Chris Angelico rosuav at gmail.com
Fri Jul 5 00:39:39 CEST 2013


On Fri, Jul 5, 2013 at 8:12 AM, Andrew Berg <robotsondrugs at gmail.com> wrote:
> On 2013.07.04 09:08, Wayne Werner wrote:
>> powershell -ExecutionPolicy Bypass -File ...
>>
>>
>> \o/
>>
>> Microsoft "security" at it again! (reminds me a bit of just pushing
>> "Cancel" to log into windows 98, I think it was)
> From an MSDN page linked in one of the answers:
>> Now, why is
>>
>>     PowerShell.exe –ExecutionPolicy Bypass –File c:\temp\bad-script.ps1
>>
>> not a security bug? Ultimately, if bad code has the ability to run this code, it already has control of the machine.
> http://blogs.msdn.com/b/powershell/archive/2008/09/30/powershell-s-security-guiding-principles.aspx
>
> If an attacker can run code, he/she already has the capability to well, run code.

Well, the whole point of sandboxing is to allow some code and not
other - look at web browser scripts. You can run your JavaScript code
on someone else's machine without the capability to run arbitrary
code.

What this proves is that PowerShell is not a sandboxing environment.
It has just two states: Trusted and untrusted. Untrusted code may not
run. Trusted code has full access as though the administrator typed
the commands by hand.

Unix has measures to prevent a running process from having full
control over the system, but even there, privilege escalation attacks
(usually involving some application that runs as root) have been
known. Restricting a running binary (as opposed to creating an
interpreted and very slow language) is a distinctly hard problem.

ChrisA



More information about the Python-list mailing list