Slashdot Mirror
Do You Code Sign?
Saqib Ali asks: "I am a regular reader of Bruce Schneier's Blog, Articles, and Books, and I really like what he writes. However I recently read his book titled 'Secret and Lies' and I think he has done some in-justice to the security provided by the 'Code Signing.' On page 163 of his books, he (Bruce Schneier) basically states that: 'Code signing, as it is currently done, sucks.' Even though I think that Code Signing has its flaws, it does provide a fairly good mechanism for increasing security in an organization." What are your thoughts on the current methods of code signing in existence, today? If you feel like Bruce Schneier, how would you fix it? If you feel like Saqib Ali, what have you signed and how well has it worked?
"The following are the reasons that he (Bruce Schneier) gives:
Bruce's Argument #1) Users have no idea how to decide if a particular signer is trusted or not.
My comments: True. However in an organization it is the job of the IT/security dept to make that determination. It shouldn't be left up to users. The IT dept should know not to trust "Snake Oil Corp.", however anything from "Citrix Corp" should be fairly safe. Moreover Windows XP SP2 provides provides a mechanism to create a Whitelist of certain trusted signers, and reject everything else. This is a very powerful security mechanism, and greatly increase the security in a corporate environment, if the workstations are properly configured. Having said that, this feature may not be that useful for home user, who can not tell the difference between Snake Oil and Citrix Corp.
Bruce's Argument #2) Just because a component is signed doesn't mean that it is safe.
My Comments: I fully agree with this. However Code Signing was never intended for this purpose. Code signing was design to prove the authenticity and integrity of the code. It was never designed to certify that the piece is also securely written.
Bruce's Argument #3) Just because two component are individually signed does not mean that using them together is safe; lots of accidental harmful interactions can be exploited.
My comment: Again Code Signing was was never designed to accomplish this.
Bruce's Argument #4) "safe" is not all-or-nothing thing; there are degrees of safety.
My comment: I agree with this statement.
Bruce's Argument #5) The fact that the evidence of attack (the signature on the code) is stored on the computer under attack is mostly useless: The attack could delete or modify the signature during the attack, or simple reformat the drive where the signature is stored.
My comments: I am not sure what this statement means. I think this type of attack is outside the realm of Code Signing. 'It is like saying host based IDs or anti-virus are useless, because if you can compromise the system you can turn them off.'
I would really appreciate any comments / thoughts / feedback on the above mentioned Bruce's arguments and my commentary. I am planning to give a short talk about benefits of code signing, so any feedback will really help me."
Bruce's Argument #1) Users have no idea how to decide if a particular signer is trusted or not.
My comments: True. However in an organization it is the job of the IT/security dept to make that determination. It shouldn't be left up to users. The IT dept should know not to trust "Snake Oil Corp.", however anything from "Citrix Corp" should be fairly safe. Moreover Windows XP SP2 provides provides a mechanism to create a Whitelist of certain trusted signers, and reject everything else. This is a very powerful security mechanism, and greatly increase the security in a corporate environment, if the workstations are properly configured. Having said that, this feature may not be that useful for home user, who can not tell the difference between Snake Oil and Citrix Corp.
Bruce's Argument #2) Just because a component is signed doesn't mean that it is safe.
My Comments: I fully agree with this. However Code Signing was never intended for this purpose. Code signing was design to prove the authenticity and integrity of the code. It was never designed to certify that the piece is also securely written.
Bruce's Argument #3) Just because two component are individually signed does not mean that using them together is safe; lots of accidental harmful interactions can be exploited.
My comment: Again Code Signing was was never designed to accomplish this.
Bruce's Argument #4) "safe" is not all-or-nothing thing; there are degrees of safety.
My comment: I agree with this statement.
Bruce's Argument #5) The fact that the evidence of attack (the signature on the code) is stored on the computer under attack is mostly useless: The attack could delete or modify the signature during the attack, or simple reformat the drive where the signature is stored.
My comments: I am not sure what this statement means. I think this type of attack is outside the realm of Code Signing. 'It is like saying host based IDs or anti-virus are useless, because if you can compromise the system you can turn them off.'
I would really appreciate any comments / thoughts / feedback on the above mentioned Bruce's arguments and my commentary. I am planning to give a short talk about benefits of code signing, so any feedback will really help me."
By agreeing to always trust Microsoft you are agreeing to several things you may not realize:
The second one is the kicker. If there is a bug in some signed code by microsoft that allows JavaScript to call it and write to any file, then anybody can give you that signed code and some JavaScript and take over your computer. This will be done without any further notification at all to you as the end user.
You are trusting microsoft to:
Even if you believe that code can be bug free, there is no way anybody who write code really locks it down so it can't be used for anything other than what it was intended. There was a security vulnerability that took advantage of just this. I bug in some signed Microsoft code. I'm not sure how it was fixed.
Currency conversion with understands "convert 23 dollars to pounds"
I co-sign. It comes in handy when your code has lots of trig math.
Escher was the first MC and Giger invented the HR department.
Of course I code sign, I'm deaf and mute you insensitive clod!
I'm an American. I love this country and the freedoms that we used to have.
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
MessageID: 5NWrD3M0/1xt+ynMPHbCYX+e3KSK9qhU
iQCVAwUBOFV2W1FO4fmE3w/VAQHgrgP9GlNAaTdNR7DI/Mh62H aZj49496wbM1Nhn p6nWR+Rrz+3DPCK 8yCEK0oe/aX0vv
YKlmtJIse2vcLF4LFVLJ47zQi4dK21vPlQ9XXAk4n4cype4gD
gpTUtsdlxZyMh0PvbAmssEX8z3In+cWgs43sjw6Tf0G4ENx68
mktgUuXP6A4=
=3mUU
-----END PGP SIGNATURE-----
Bruce is right. You mention that code signing is not designed to handle problems of security or safety. Well, what good is that? The primary reason you want to know who wrote the code is because some you trust some organizations to write safe code. Yet a restricted security model (sandbox, etc.) would give you a greater level of security. It's nice to know that Friendly Company X put their seal of approval on some flunky's ActiveX, but it's much nicer to know that the system is restricting system calls and network access.
If Red Hat can't be bothered to sign any of its updates (even the kernel, for pete's sake), then why as a user should I care one way or another?
I use Macs for work, Linux for education, and Windows for cardplaying.
You make some good arguments. Code signing is not a panacea, but it does add value. saying it sucks because it doesn't solve world hunger is a worthless criticism of a good technology.
I would add that "always trust X" is not appropriate for home users, and it is good that MS makes the unchecked state the default. I don't recall MS telling me to always trust MS, and if they do, I would want to give them feedback about that wording.
The "always truxt X" feature is best used by domain admins who can pre-approve stuff for their users. It's even better if they can resign the code themselves with a cert on the approved list.
--Jaborandy
When used in this context, "code sign" doesn't make sense... shouldn't it be "Do you sign your code?" Or if it's intended as a new phrase, maybe it should be "Do you code-sign?"
rooooar
I think most of the users have no idea what "This code is signed by BlahBlah corp" or "See certificate" etc. means. They simply click on something to get past the annoying window.
Explore your creative side
Maybe Bruce himself reads /. and will post. I read his blog daily and I know he often posts comments in his own blog.
or this thread could get hyperbolic very quickly.
Periodically, you have to use trig functions for sine-ing. This technique arcs back to Pythagoras who would tan himself by sitting in the radians of the sun.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I believe that I understand Bruce's point #5. Let's say that I'm going to download the Linux kernel from RedHat. And let's say that I want to be sure that it's the real Linux kernel instead of some trojaned thing. So I check the signature (assuming that RedHat actually signed it...)
But how would it not be the real executable? I only see two possibilities:
1. Somebody hacked into RedHat's servers and overwrote the executable. But if they did that, why not just overwrite the signature too? (I know, it isn't that simple if the signature mechanism uses a public key, which I suspect that it does. Then you would have to have access to a valid RedHat private key to sign the bad executable. But you could just delete the signature instead, making it look like RedHat didn't bother to sign the file.)
2. Somebody is playing with you via DNS or ARP poisoning or some such, and you aren't going to RedHat at all. But the exact same argument applies - they just remove the signature, and who's to know? (Well, everybody knows who is checking signatures, but everybody assumes "they just didn't sign it" rather than "oops, hostile action!")
So the point is that signatures don't really protect you here, unless you are really paranoid, and in practice, very few people really operate consistently in paranoid mode...
You can sign your code using a public key scheme like GPG. No need for a middle-man like VeriSign. Users can get your public key at your project's website and verify that the code is really yours. Of course, your project's website may be compromised... but so can VeriSign's...
The filesystem is the package manager
I sign my shareware, simply because WinXP's screen when running signed software is slightly less frightening. I think that is worth the yearly US$100 investment (I didn't do a double-blind test, though - it's just an educated guess).
About Bruce's Argument #1, that is true. However, the idea is that whomever they got their certificate from (Comodo, Thawte, Verisign, etc) will revoke the certificate as soon as they do something against the rules. It will show as revoked if the user is on-line when the screen comes up.
I previously heard about someone's certificate being revoked for wrongdoing. I can't remember any of the details.
If the certificate issuers acted fast on reasonable complaints, it could be a great security enhancer.
As it is, the group that gets the most of it is MS (who gets fees from issuers for being in their OS's root certificate) and the certificate issuers.
Sometimes "code-signing" is said that even though it does not garantee the safety of a downloaded component, at least you know who to blame if it crash your computer. But, a bad-guy can sign his component, you accept the signature, and then the component can delete all traces of the signature from your computer. So even if you later realize that it was a "bad-component", you have no mean to review the signature.
MOD THE CHILD UP!
At first glance I thought it was a referance to writing the software for those highway text display signs.
"Yeah, I code signs. Ever been by the I75 exit on the Ohio Turnpike? That's mine."
No But I Sign Code.
Editors: Please correct the mistake in the headline. Thank you.
Karma: Positive (probably because of superiour intellect)
You work for a corporation. You have some control over a bunch of desktops. You have an hopefully security aware groups to vet things and inspect and what not. You're the ONLY group of users who see real benefits to code signing. Of course it all works, FROM YOUR POINT OF VIEW. (sorry for shouting).
Me, I'm just one guy. I'm not going to do due diligence for every software out there. Half of what I use isn't signed. Should I just give up on it? I don't have TIME to deal with security enough to make a whitelist useful.
Them over there, they're also a big corporation, but they have tons of sites and while people back at HQ are somewhat clueful, the support folks at the site in the Boondocks halfway around the country suck. Or security is just not a priority, whatever. Benefits from code signing? Nil.
So you, the poster of this article, are in the one group that actually gains anything. I would recommend you investigate the possibility of resigning absolutely everything and banning anything but your own cert, not even microsoft's. Cause it sure seems like you run a tight ship, I envy you.
In other words, it doesn't eliminate risk, but it does quantify it - provided that the signature chain is meaningful.
For example, a "correct" approach is to have the package maintainer sign the package as verified by the maintainer. The maintainer's key is signed by someone else - preferably someone well known - so that users can be sure that the key's owner is who they say they are.
The RPM/DEB/whatever packager would then sign their built version of the code. For "perfect" security, the binaries would be handed back to the source package maintainer, who would countersign the binary as authenticly compiled from their work.
A distribution provider would then add their OWN signature to the binary package, to establish that the copy in their posession is genuinely from them and that they know the source of the package. They'd also countersign the developer's and binary packer's keys.
At this point, you've an auditable trail and enough cryptographic keys to (almost) guarantee that nobody could break into the package and add malign software to it.
It does NOT prove that the package is "safe", but COULD be used in a court where digital signatures were accepted to prove responsibility. Thus, if a package was provably untampered-with, but provably had spyware in it, then you could use the signature chain to establish with a high level of certainty as to who had introduced that spyware and when. (It can't have been after the last signature that matches the binary, and must have been the first person who established a valid signature on the file.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
You state that several of Bruce's arguments do not apply, since code signing wasn't designed to solve problem A or problem B. Unfortunately, this isn't an issue of what signing was designed to solve, it is a question of what the end user thinks code signing is for.
If the end user is presented with pop-ups asking "Do you want to trust code from Company X?", the user will be making a decision about that trust. They may (or may not) be concerned with questions such as "Will this code crash my computer?" or "Is this a Trojan horse?". They couldn't care less if the code was really authored by Simon P. Coder while under the employ of Company X. When they click "Always Trust", if they're thinking at all (not guaranteed), they will think that the code is safe, won't crash, and won't have extra "features" that steal their private information.
This is Bruce's point. Because of the presentation and implementation issues, most end users are left with the impression that signed code==good code, an impression that is not always accurate. If the technology is leading the end users to believe things that simply aren't true, there is a problem. In certain, limited, tightly-controlled environments, code signing can work as intented. In general, it is at best an annoyance to the end users and at worst a complete fraud.
Our organization recently bought an email encryption product called Tumbleweed that was quite expensive. One of the features is that any e-mail with "[Secure]" at the beginning of the subject would automatically be encrypted. The catch is that in order to make a button in Outlook that added this text, it would cost an extra $8,000 for a custom add-in.
Naturally the request came to me (even though I develop web applications). I whipped up a ten line Outlook macro that did it, spending about twenty minutes on it. Easy, right? The catch is that Outlook security is incredibly tight and unless you open massive security holes, the macro wouldn't run unless it was digitally signed by a trusted provider.
I plunked down $400 for a Verisign certificate and spent the next couple weeks working with our SMS guy to create packages for the various Outlook versions, and the desktop guys to deal with people who had custom Outlook macros.
Basically it was a huge hassle, done only because we had to. Still, it worked, and ended up saving some money. Crazy, though.
Bruce's Argument #2) Just because a component is signed doesn't mean that it is safe.
My Comments: I fully agree with this. However Code Signing was never intended for this purpose. Code signing was design to prove the authenticity and integrity of the code. It was never designed to certify that the piece is also securely written.
I thought the purpose of code signing was to vouch for the integrity of the SIGNER, not the code itself. If you want to argue that code signing guarantees the code because nobody but the signer could sign it, OK, but that still leaves you having to explain to users which signers are OK and which aren't.
The thing that's always bugged me about signing is that it relies on the root cert issuers (Verisign, Thawt, etc.) to do their jobs and verify that their customers are who they say they are, and the sense I'm getting lately is that $800 and a valid email address is enough to convince them that you are anyone you want to be. Am I wrong?
This is a bad example, but what happens if Joe the hacker incorporates a dummy company named "Micr0soft.com", registers a domain for it, installs web & mail servers with matching certs, then buys a code-signing cert from your favorite root-cert company, then uses that cert to sign plugins as "Micros0ft.com"? It would have a valid cert path, wouldn't it? Do the root cert issuers even check for that kind of crap anymore? They used to take D&B numbers as proof of identity, or in lieu of that, notorized copies of incorporation documents on letterhead, but I don't think they even bother checking anymore. At least, they didn't when I bought an SSL cert in December.
"Lawyers are for sucks."
- Doug McKenzie
As stated numerous times, code signing is not designed to let a user decide whether code is good or bad. But, for signed code, there is a way to track it back and make the author accountable. If all of today's viruses were signed, most of the authors would be caught. Even if they were signed in a fraudulent manner, there would be a thread to trace back. Enough threads and a good investigator will catch the bad guy.
So, code signing is a sign of software good-faith. Everyone should show that they are distributing software as something more than an Anonymous Coward. It always disappoints me that major hardware manufacturers won't even sign their device drives.
Bruce is right, code signing (at least in its present form) sucks. In fact trust in general sucks, and will until we come up with an intelligent way to assign it. So you want a 'whitelist'? By that you presumably think that the 'whitelist' of CAs rolled out with browsers works? It doesn't. Nor will telling 'safer' to consult it before running code.
My comments: True. [...]The IT dept should know not to trust "Snake Oil Corp." [...]
You are missing the point entirely: What if I were to present you with "Citrix Corp." and "Citrix Corporation" and "Cirtix Inc.". Which would you *know* comes from *the* Citrix corp. Also, notice how the third one had a typo. Also, I will remind you of some guy who had obtained a cert from verisign for the name of a well known company. I forget which one it was, but it was something like Microsoft or Sun.
Bottom line: the cert only assures you that the string ("Citrix") it corresponds to is correct. It doesn't say anything else. Which begs to ask: why have a signature?
Bruce's Argument #2) Just because a component is signed doesn't mean that it is safe.
My Comments: [...]Code signing was design to prove the authenticity and integrity of the code.[...]
Again, this is aside the point: when you for example give shell access to students at university machines, all the binaries they run are part of a secure base. cp and ls are *the* tried and true binaries from every distribution. An administrator *knows* that they can trust that code.
Now, let's say an administrator installs a signed ActiveX plugin. Let's say it's even the Flash player. What we cannot know, and what makes this mechanism extremely dangerous (by means of perceived safety), is that the player might have a security hole in it. So you might go to a web page, and an action script loaded into the player could cause the player to execute random code. This is a big no-no. And not because the player is flawed, but rather because you've decided to integrate this piece of code into your trusted base OS.
Bruce's Argument #3) Just because two component are individually signed does not mean that using them together is safe; lots of accidental harmful interactions can be exploited.
My comment: Again Code Signing was was never designed to accomplish this.
Bruce's Argument #4) "safe" is not all-or-nothing thing; there are degrees of safety.
My comment: I agree with this statement.
Combined with the first two points, you're basically saying that there's no point in having code signing.
Bruce's Argument #5) The fact that the evidence of attack (the signature on the code) is stored on the computer under attack is mostly useless: The attack could delete or modify the signature during the attack, or simple reformat the drive where the signature is stored.
This is a very important feature of security: auditing. If you have a system that's been compromised, you want to know how it happened. *Especially* if you are in a corporate environment: you see one workstation get 0wn3d and formated, you won't be sitting around to see when the next one hits. You will want to know what did it.
All in all, I agree with everything he says. Even though I'm just a mere mortal.
If you're even talking about this topic you are clearly not living in the real world of tight schedules and out-of-control projects. Chances are you're working in government. Who cares?
Make GCC sign code in a post-process by default. It can spawn a background child, so the compiled code is immediately available, while the signer completes in the background. But it's become obvious that programmers and security pros (securers?) are two distinct roleplayers. Like programmers and sysadmins, or programmers and users, or even programmers and designers/architects, or programmers and graphic artists: rarely is the same person good at both (though sometimes programmers are good users). So programmer tools should automate the process according to best practices. Leaving it voluntary is no longer an acceptable risk.
--
make install -not war