As a security measure, my Windows-based work computer has been configured to deny any application that hasn't been signed with a valid certificate; my system will run a signed executable from DropBox's website, but it will refuse to run an unsigned open-source executable instead prompting me to enter an administrator password.
This behavior matches my mental model of how a security measure such as this would work.. except that it breaks when for interpreters like python.
When I downloaded python on my computer, I was able to successfully install it thanks to it being signed by a valid certificate. I was also able to run an arbitrary script I copied from another system because the interpreter is signed. In other words I was able to run an unsigned program (script) on a system that I thought was configured not to!
So given the facts that a) users can download signed programs, and that b) those programs can act on unsigned input:
- Is this really how the code signing and verification system is intended to work on Windows?
- If so, wouldn't a malicious actor be able to bundle any signed interpreter along with their own malicious script and have their code run on any Windows system?
- If so, what purpose does this system serve?
I admit that I likely may be missing something here, given a hole as large as this couldn't have been missed my Microsoft. Perhaps my work computer is misconfigured somehow, or that I made a mistake somewhere in my analysis. Please have the patience to correct me if I have.