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:

  1. Is this really how the code signing and verification system is intended to work on Windows?
  2. 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?
  3. 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.

  • 1
    Code signing is not really about security of the user's machine, but security of the file itself. It can help guarantee that the executable came from the signer and that it has not been tampered with. (There's a hash of the executable that is compared with the sig...) You can turn off access to certain scripting engines (vbscript, python, etc...) Scripts themselves cannot be signed. You may also want to consider limiting access to other run-times like .NET or Java... those executables are usually signed, but again the signature makes no guarantee of safety it only lists the signer. Commented Jan 20, 2023 at 18:04

2 Answers 2


So given that users can download signed programs, and that those programs can act on unsigned input

This statement is not only true for things like Python, but also for a word processor, a spreadsheet, a PDF reader, a web browser etc. All these process unsigned input (user entering text, opening existing documents) and often even unsigned programs (like calculations, Javascript, ...).

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?

Correct. Or just use signed software already available on the system, like a web browser. This is actually done with attached HTML files in mails, attached word documents, PDF etc.

If so, what purpose does this system serve?

Reduce the risk, not eliminate it.

It is up to the signed program to implement additional protections. Browsers usually run code within a sandbox. Other applications have only a limited set of functions what user input can do. Some languages like Powershell can be configured to only allow signed scripts.

Note that just because an application is signed does not mean it is fully safe to use. Even signed programs can do harmful things, either inadvertently or by design. Similar to the certificates of a website a valid signature proves only who created the application and says nothing about the actual security.

It is still up to the administrator of the system to decide which programs to trust. Trusting any kind of program is worse than trusting only signed programs, but trusting only signed programs from some trusted vendors is even better. Or ultimately only whitelisting a set of verified programs.

  • Regarding the assertion that this system was only intended to reduce the risk and not eliminate it, i don't think it would provide any meaningful reduction in risk given how trivial it is to circumvent even by a novice attacker. I do agree that it can be useful for whitelisting and identifying the source of the binary, but I still don't see how it could provide any real protect benefit beyond that. Commented Jan 23, 2023 at 12:28
  • @TendersMcChiken: Code signing is the first step in limiting applications by identifying the author of an application, i.e. it is the precondition to further limit execution to only trusted authors. If you don't go the second step you have to live with the limits of only going the first step. Commented Jan 23, 2023 at 12:47

Your points are valid. It does not make much sense to sign a program like a Python interpreter that runs unsigned code, or to sign any program that loads untrusted DLLs.

However, it does make a lot of sense to sign the installers for these programs that you download from the Internet. The installers can in theory be written to not execute any untrusted code, and I think this is what the installer frameworks try to do. The installer contains all the files it will extract and store on your computer, so a single digital signature on the installer binary verifies that those files have not been tampered with after the installer was created.

  • In other words, the system is not so much a mechanism to keep bad code from running but rather a mechanism only meant for verifying the origin of the executable? Commented Jan 23, 2023 at 12:32
  • 2
    @TendersMcChiken: It is like website certificates - they make only a claim about a verified origin but don't make any claims about security of the website. Commented Jan 23, 2023 at 12:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .