On Fri, Jul 5, 2013 at 8:12 AM, Andrew Berg <robotsondr...@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 -- http://mail.python.org/mailman/listinfo/python-list
