Page History

Code signing was introduced in Java to provide a mechanism Java uses code signing as a requirement for granting elevated privileges to code irrespective of the security policy in effect. Many security policies permit signed code to operate with privileges that exceed the default. For example, Java applets that need to read system properties from a user's machine can escape the default sandbox restrictions when signed. When a signed applet is run, the user is prompted with a security dialog, asking whether the party that signed the code is considered trustworthy. This element of trusting the signature and the signer allows applets to escape the default security sandbox restrictions. On the other hand, with applications that use a custom security policy, explicit permissions need to be granted to the particular codebase and optionally, the signer. Both these approaches place the control Applications can use custom security policies based on code signing. Thus, users can grant explicit permissions either to a particular codebase or to all code signed by a particular signer. This approach places control of security in the hands of the user, who can choose whether to run the an application either restrictively or with full or restricted permissions.

Signing code, however, has its own problems. According to Schneier \[[Schneier 2000|AA. Bibliography#Schneier 00]\]

First, users have no idea how to decide if a particular signer is trusted or not. Second, just because a component is signed doesn't mean that it is safe. Third, just because two components are individually signed does not mean that using them together is safe; lots of accidental harmful interactions can be exploited. Fourth, "safe" is not an all-or-nothing thing; there are degrees of safety. And fifth, the fact that the evidence of attack (the signature on the code) is stored on the computer under attack is mostly useless: The attacker could delete or modify the signature during the attack, or simply reformat the drive where the signature is stored."

Code signing is designed primarily both to authenticate the origin of the code as well as to verify authenticity of origin and the integrity of the code. It relies on a Certification Authority (CA) to duly confirm the identity of the principal signer. Naive users should not be expected to understand how certificates and the Public Key Infrastructure (PKI) work. All too often, users

Users commonly associate digital signatures with safety of code execution, and so trust the code to cause them no harm. In general, there is a misconception that signed code is safe to be executed. The problem manifests itself arises when a vulnerability is discovered in signed code. Because many users when prompted with the security dialog, choose the option of permanently trusting the organizations that they consider trustworthy, they are not notified in the future while downloading trusted but potentially vulnerable systems are configured to permanently trust certain signing organizations, those systems fail to notify their users when downloading content signed by the trusted organization, even when that content contains vulnerabilities. An adversary may offer them the users legitimately signed vulnerable content with the intentions intention of exploiting itthat content.

Consider, for example, signed Java applets. Whenever When a certificate is verified to be correct (as opposed to being self-signed or tampered), on widely used platforms the user is confronted presented with a security dialog that has in which the check box option "Always trust the content from the publisher" is selected by default. The dialog primarily asks whether the signed code should be executed or not. Unfortunately, by default this setting overrides any future warning dialogs if the user chooses to execute confirms the code dialog with the check box selected, the "Always trust..." setting overrides any future warning dialogs. An adversary may take advantage of this mechanism by supplying vulnerable code signed by the trusted organization. In this case, the code will execute without with the user's implied permission and may be freely exploited.

An organization that signs its own code must should not vouch for code acquired from a third party without carefully auditing itthe third party code. When signing privileged code, ensure that all of the signed code is confined to the same a single package (See guideline ENV01-J. Place all privileged code in a single package and seal the package for more information.) Likewise, and also that any code that is called invoked from the privileged code must is also be bundled contained in the same that package. Non-privileged code can should be left unsigned, restricting it to the sandbox. Additionally, avoid signing any code that is incomprehensible or unaudited must not be signed. (See guideline SEC17-J. Create and sign a SignedObject before creating a SealedObject.)

It follows that Signing unprivileged code is not required to be digitally signed and consequently should not be. This conviction adequately respects the guideline unnecessary; avoid doing so. See SEC00-J. Follow the principle of least privilege. For instance, unsigned applets and JNLP applications are granted the minimum set of privileges and are restricted to the sandbox.

...

ENV00-EX1: An organization that has an internal PKI and uses code signing for internal development activities (such as to facilitate code-check-in and track developerstracking of developer activity) may sign unprivileged code. This codebase should not be carried forward to the production environment. The keys used for internal signing must not be distinct from those used to ship the productssign externally available code.

Risk Assessment

Signing unprivileged code violates the principle of least privilege as it can circumvent security restrictions defined by the security policies of applets and Java Network Launch Protocol (JNLP) applications, for example.

Automated Detection

TODODetecting code that should be considered privileged or sensitive requires programmer assistance. Given identified privileged code as a starting point, automated tools could compute the closure of all code that may be invoked from that point. Such a tool could plausibly determine whether a body of signed code both includes that entire closure and also excludes all other code.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

\[[SchneierDormann 20002008|AA. Bibliography#SchneierBibliography#Dormann 0008]\]
\[[McGraw 2000|AA. Bibliography#McGraw 00]\] Appendix C: Sign Only Privileged Code
\[[DormannSchneier 20082000|AA. Bibliography#DormannBibliography#Schneier 0800]\]

...

01. Runtime Environment (ENV)      01. Runtime Environment (ENV)      ENV01-J. Place all privileged code in a single package and seal the package