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-----
You know, something tells me that the majority of gay men are not named Bruce.
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.
Just because Bruce Willis is gay, doesn't mean all Bruces are gay...
;)
And most people who work with computers (while they may appear uninterested in women), aren't gay... Asexual would probably be a better term for it...
Deja Vu
n. 1. The sensation that you've read this very article before.
It IS useful in a perfect world, but most people are too clueless to not just go ahead and accept everything anyway.
I personally never accept "always accept".
The revolution will NOT be televised.
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
I don't know if it's an in-justice, but you might want to con-sider in-stead that maybe it's just on in-dividual's o-pinion.
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
This sounds like a windows-only feature but how can code signatures be verified? Does windows have some sort of certificate chain ala SSL where a developer needs to get an SSL certificate signed in order to code sign. If this is the case and such signatures were verified by the os kernel itself before running the binary, it makes good sense for IT departments to have the ability to restrict binaries based on signatures.
Code signing is useless dribble, to be quite frank. Your counter-argument for his first point is lacking.
Hey Cliffy Baby: You need to stop posting this garbage to Zonk's blog.
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.
This is all the proof anyone needs that the Slashdot editors don't even have a rudimentary grasp of English.
"do you code sign" is meaningless.
ANY other phrasing would be better. ANY.
How about: "Do you cryptographically sign your program code?" OH LOOK! It still fits in the titlebar, takes only three seconds to type, and contains a complete concept!
Jesus H. Christ. Fuck slashdot. Digg.com is all you need anymore.
Greetings,
This means if the host has been comprised and the code changed, the black hat will just regenerate the signature.
The code and signature should be on separate hosts. Maybe something like a keyring server.
Cheers
You can probably co-opt Thawte's freemail certificate for code signing.
or this thread could get hyperbolic very quickly.
and thats the problem, certificates are issued on the basis of whoever pays, gets, requirements have no bearing on authenticity just on whoever writes the cheque gets the certficate
perhaps this is one thing the goverment should oversee without a price tag attached to it (for the good of society, but thats a concept lost at the moment), so far its been proved to just be another revenue stream for Verisign/Thwarte etc, except its like money for free as far as they are concerned
Would it be any different if he unbasically said something?
Hey, this painting I just bought at a garage sail is signed "Piccasso" - W00t! eBay, here I come! Untold riches are surely mine! ...which, I think, would kinda point out the flaw in the system. I hope.
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...
Are you and/or Bruce talking about code signing as in microsoft pretending that signed activex controls are magically safe? If so, then Bruce is right, it does nothing and is a total waste of time. Signing is just so you know that the code was written by who you think, you still have to decide for yourself wether you trust that person to write good code.
.asc, very few people actually verify their downloads. But a tiny fraction do, and its worth the 2 seconds signing takes to help those people know that they downloaded what they thought they downloaded.
If we're talking about people like me, who offer pgp signatures of the software they wrote along with the tarballs, then its worth doing. Based on how many people download the tar.gz vs how many people download the
...the only I/O was via a camera (a-la HAL 9000), you'd have to code in sign.
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'd rather get a certificat [sic] and sign my code. Would you rather your application appear as "don't trust this code, it's unsigned" or as "Signed by . Do you want to trust?"
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!
Code signing can be used to determine where the code came from (or, at least, some place that claims to have provided the code). If that's really what you want to know, then it's fine. It's a good mechanism for giving some information to people who click on a program and select "properties".
On the other hand, this information is not useful for deciding whether to trust some code, because the signature only provides proof of origin, not proof of correctness. Anything that only permits signed code to run is fundamentally flawed, because it makes the assumption that there are signers who only sign good code, which is manifestly false.
On the other hand, mere origin is useful in some cases, although, lacking any security implications to forged signatures, there's little need for cryptography, which is why I've signed a bunch of my code. (It's worked reasonably well; people sometimes realize when I'm the right person to debug something, and sometimes don't.)
There is some potential for validating that things haven't been changed using signed code. If the OS knows that you're trying to run Microsoft Word, and it's not signed by Microsoft, it can tell you that. And some OSes could actually retain the public keys with sufficient security to actually catch some problems that way (particularly on applications installed by users). But this is an unusual situation and only protects things that viruses don't generally do these days (modify programs without compromising the system).
Software signing is a simple case of "who's watching the watchers". If there is no quality controls put in place on the signed code, what truly is the point of signing it? The browser gives me a scaaary dialog box that states "Not trusted!". Most users only want to achieve the installation and get that damn box to go away.
The solution? Simple. Approve all signed software and actually make the code signing a "process". The code is submitted, analyzed and API's detailed by a clearinghouse, and then receives a rating. Use the certificate mechanism to control what level is acceptable for an organization or an end user. In end loser cases, it's a 10 situation. OS default.
No But I Sign Code.
Editors: Please correct the mistake in the headline. Thank you.
Karma: Positive (probably because of superiour intellect)
The only thing that signing anything does is insure that the object you receive is the same as that which a trusted publisher sent you. It says nothing about the usefulness or safety of the code, and isn't meant to. If you trust whoever to write safe code, that's your problem. The only really practical use is to make sure you aren't receiving code that has been modified in transit or posted by someone posing as someone else. Of course to really do this, you need to verify the integrity of the signer's certificate as well as the code's signature. This either costs money or is generally insecure (as no one is going to bother verifying the md5 on joe blow's random certificate authority, and even if they did so, it theoretically could be compromised in transit as well, unless you call joe blow on the phone, and he probably wouldn't know what you were talking about). The only place this really works is in a corporate lan environment (where this type of breach is much less likely anyway) or with big name source distributors like MS or Linux distro's.
I see this book mostly as an opinion piece, as well as a good starting point on how to think about security. I must say I like his other books much more than this one.
The small part about code signing is just that, a not so well thought out part of his book with little around it to back it up. It mentions ActiveX especially, which probably means that it is taking code signing to mean "this package has safe code inside it, which other (untrusted) applications may run. I agree wholeheartely that this is little reason to trust some software package *alone*. This can be mitigated if said package runs in a sandbox itself, or has been proven to not contain buffer overflows, or requires user input to install or run. You get my drift.
But if code signing is used to show that an install package is from someone, and it is signed with its key, then code signing *can* provide some serious security benefits. Saying no to that means that putting digital signatures have no merit. This is however a very different use of code signing than the one Bruce seems to target.
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.
This makes the assumption that it's a solvable problem; not every problem is, especially when it comes to computer security (or security in general, for that matter).
Windows in C sharp!
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)
The question here is, do you want to know who wrote the code in question, or do you want to know if it's correct?
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
When you are developing applications and are compiling against packaged components that maybe you didn't write, it's critical to be able to say "I am building this application against this component/library - when it gets out in the production world, don't link/load any version of the library that isn't digitally signed with the private key that matches this public key". That is what code signing is good for. Not some farsical "proof of correctness" aquatic ceremony. :)
Left shift 1 for e-mail...
Offering a PGP signature for your code already solves the comprimised website problem. Your public key should not be on your website, it should be in several publicly available keyservers, so an attacker would have to hack a bunch of keyservers, plus your website to be able to do anything. And even then, people who had already downloaded your public key in the past are still safe.
Does code signing really ensure that the code came from the trusted source? I think there is an argument to be made that if someone hacks your software distribution channel, they might have also hacked whatever mechanism is responsible for signing your code. Bruce may have also made this argument, however, I'm not going to reread the book to confirm.
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.
I give the end users the source code, so they can make an informed decision whether to trust my code or not, rather than relying on what a dialogue box from a third party _I_ don't even trust tells them.
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
For Paint.NET v2.2 we are using code signing (http://www.eecs.wsu.edu/paint.net -- Alpha 1 was released on Monday). Every update that is downloaded by the app must be signed and the signature's cert must validate up to a trusted root before it will be installed. We are doing this mostly to prevent users from accidentally installing updates that we didn't release (hax0red DNS or network setups). This isn't a perfect solution, of course, but far better than naively not doing anything.
This post is made "AS IS" with no warranties, and confers no rights.
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.
Apparently, not do you grammar understand....
Really nice ...
When you are factoring in the regular annoyance for the sysadmin who has to verify everything, maintain all listings on a regular base and when the next big crash happens has to disable it (or because the boss has the fancy new laptop with special needs w/o signed code), you really want to forget about it if you do not have the budget for it, or a real need (working in secure environment where it makes sense or even is a requirement).
Cheers, G
I find code-signing to be almost useless. The only real value it has is that it tells me that the code I have is not corrupted or switched for something else.
Once you get into the whole "web of trust" mess it really becomes a case of diminishing returns. But it's one of those "check-box" security "features" that PHBs insist upon. Maybe there is where the percieved "value" is...
Next para is sorta OT...
My favourite rant about message signing is that stupids are using externally-verified SSL in internal links (!). That is, we are using external-signed SSL for links between our app servers and our database! Huh? Appart from shelling out a lot of wasted money to VeriSign, what does this get you? So your DB is certian that the transaction request came from your app server, yes. But why external signatures? It beets me too, but there you go: it was on some PHB's check-list...
“Our opponent is an alien starship packed with nuclear bombs. We have a protractor.” — Neal Stepnenso
it's critical to be able to say "I am building this application against this component/library - when it gets out in the production world, don't link/load any version of the library that isn't digitally signed with the private key that matches this public key".
Interpreting "don't" as "you break the EULA if you" violates the GNU Lesser General Public License, as the license requires the author of a program that depends on a covered library to allow users to upgrade libraries that a program depends on. On the other hand, interpreting "don't" as "all express and implied warranties shall become null and void and all update subscriptions shall be terminated if you" should be OK.
Stupid! That's what blame is for. ;)
If the issuers of code signing certificates still relied on proof of incorporation, they would be discriminating against purchasers that are not corporations. Because the current version of Microsoft Windows puts up scary warnings if a program is not published by someone who has been issued a code signing certificate, Microsoft is using FUD against all software published by an individual, which includes much of the available free software. This could lead to yet another antitrust case, especially in a country whose government has taken the initiative of promoting open source.
You can sign your code using a public key scheme like GPG. No need for a middle-man like VeriSign.
Microsoft Internet Explorer in Windows XP Service Pack 2 marks each file that you download from the Internet as "from the Internet". If an executable is "from the Internet", Windows Explorer will attempt to verify the file's digital signature. If this fails, you get a Big Scary Alert Box whose suggested action is Cancel. Problem here: Windows Explorer understands only signatures using middle-man technology, not GPG signatures.
You can use OpenCA or any other open source CA to keep track of your certificates and keys.
But has Microsoft chosen to trust OpenCA for Windows Code Signing? Because of the Big Scary Alert Box in Windows XP SP2 when running a setup.exe file downloaded from the Internet, a lot of inexperienced users have chosen to trust only those organizations that Microsoft has chosen to trust. Are OpenCA's certificates distributed along with the home PC market's "favourite web browser or operating system (or both)"?
Offering a PGP signature for your code already solves the comprimised website problem.
How can one get the Windows operating system's built-in code authentication systems to work with OpenPGP format signatures in addition to X.509 format signatures?
Your public key should not be on your website, it should be in several publicly available keyservers, so an attacker would have to hack a bunch of keyservers, plus your website to be able to do anything.
In this case, "hack[ing] a bunch of keyservers" would likely just involve creating certificates whose name contains a typo (e.g. "example.com" vs. "www.example.com") and uploading them to the keyservers, right?
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?
i worked with DoD PKI for quite a few years. certs are ok when you actually have a central authority that everyone trusts. but one of the big problems is fingerprints. you can make a cert look exactly like a verisign cert except with different fingerprints. users never actually check the fingerprints. but fixing this problem via central control of a whitelist will always involve ignorant/conservative sysadmins breaking your app because they have a different bottom line from you. they would keep you from running your own CA under the assumption that it's a source you can't trust...because it's not on the list.
users should be able to check the reputation of a certificate. for code signing they need to be granting a *specific* set of privilege to a specific app. all of this means that with code signing, you have to be using a good virtual machine architecture (JVM,CLR,etc) and a great user interface for maintaining policy. you should get alerts in the policy manager whenever an app tries to exceed its privilege, and extensive logging of privileges used by an app should be done.
otherwise we have the idiotic system we have now, where we assume perfect heirarchial trust in which trust is totally black and white.
limited as they are. It allows you verify the integrity of data which is usefully if your distributing your code from different place.
It could also be used to ensure code hasn't been modified. This is where the attack pointed out in Bruce's last argument comes in. It's not beyond the realm of possiblities that a peace of signed code could be modified and it's signature updated. All thought the certificate authority would have to be changed. I doubt the average user pays much attention.
If you feel like Bruce Schneier, ... If you feel like Saqib Ali, ...
I don't "feel like" either of these people; what would we have in common?
Oh, you mean if I feel as they do.
Posters who can't spell, editors who can't write... impressive forum, Slashdot.
The IT dept should know not to trust "Snake Oil Corp.", however anything from "Citrix Corp" should be fairly safe.
No shit. The problem never was that, but wheter "1024D/40558AC9" should be trusted, or perhaps if "1024D/8E297990" is more trustworthy.
I can label my key with "Citrix Corp" if I like, and I might even be able to convince Verisign to sign it as these guys did.
Code Signing was never intended for [guaranteeing code is safe].
But users don't know that. They're being duped into thinking that if only the path between the software developer and the user weren't so muddy, there wouldn't be any viruses or spyware or adware or whatnot.
Nevertheless, that path is the one attacked less frequently, but it is instead the software that Microsoft got to you completely intact that is the software you cannot trust.
'It is like saying host based IDs or anti-virus are useless, because if you can compromise the system you can turn them off.'
That's exactly why they are useless. You don't do scanning on a machine that you fear might be compromised. You do it from a machine that you know isn't, but that still has access to the other machine's frozen state.
My thoughts are:
Slashdot's going downhill fast!
Questions at the end of summary can be good every once in a while, but they're really getting old. C'mon guys.
Maybe someone should work on implementing "aspell" or something into Slashcode. That way editors will stop making spelling errors.
Editors should be more choosey about what is considered as "Front Page" material.
Also, someone should implement a "dupe checker" into Slashcode.
These are my thoughts.
You sign your releases via PGP.
How does one get Internet Explorer from Windows XP SP2 to use something based on OpenPGP instead of its native X.509 based system for disabling the Big Scary Alert Box when running a downloaded program?
Your public key should be available from multiple keyservers, and presumably you've hooked yourself into the web of trust.
How does one get into the web of trust? Google (my city) key signing doesn't seem to produce any relevant results. Biglumber.com seems to list key signing parties only in Triangle Area (North Carolina), Munich, and Zurich; I don't live within walking distance of any of those locations.
Given that anything you say, do, or code may become illegal in the future, why would you want it to be so traceable back to yourself? I kind of prefer to have email or whatever where the security is such that it would be very easy to raise reasonable doubt as to whether I myself actually am responsible for it or not.
Since I learned a smattering of ASL years ago, I automatically parsed that to mean something involving coding in sign language, or sign language as code.
And I thought to myself "Wow, that's some cool shit!"
But noooo...
"No problem. I have the capacity to do infinite work so long as you don't mind that my quality approaches zero."-Dilbert
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
I didn't, for example, and I've been using Linux (RH and Debian) since RH 6.2 .
That said, I've never run into the issue.
From the description given, it seems that this is mostly a user interface issue. A helpful message might well be all it takes.
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.
You're being hypocritical here. The obvious flaw in your argument is "how did the Administrator know that cp and ls were tried and true?" The correct answer is "by code signing" and trusting the distribution agent that signed them (and the implied chain of trust with the certificates).
Now, cp, ls or more likely sendmail can have flaws in them just like any ActiveX component can have flaws. They are all the same thing - binaries that you install which are signed by some developer that you trust. It's up to the Administrator to draw the line on where their level of trust is and that question is wholly independant of code signing.
It's very educational to replace "ActiveX" with "the ls binary" in any "OMG Code Signing is teh dev1L" arguments because it handily illustrates that it's not code signing but the level of trust Administrators do or don't have that is the real security problem.
Fear: When you see B8 00 4C CD 21 and know what it means
Use the geek code as public key, e.g. GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++ E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$ PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++ G++++ e++ h r-- y++** This way you can be certain any downloaded updates are from a certified geek. You know what you get.
My daily use of code signing is:
a) Verifying the integrity of the Linux kernel and patches downloaded from mirrors. I can verify them easily as I have the signers public key in my keyring. If it was signed by a foreigner I would notice by the absence of the key. This works here because it is not a one-time only check but I repeatedly verify code from the same source.
b) Signing MIDlets to leverage access rights on mobile devices. I do this because I have to. It improves usability for the user because she only has to allow network access once after installing and not every time the application is started. Not that you could really tell which application caused a certain amount of cost. So code signing on mobile devices is really bollocks.
And who is Bruce? And why should I believe anything you say?
It's a learned thing. While most people would think that a peice of executable code signed by "Bill Gates" of "Microsoft" would be trustworthy, I don't want it anywhere near my computer. Not since the day I decided to be lazy and not disconnect my main hard drive like I had 10 times before. Windows 98 installer asked me 3 times if I wanted to install windows on my "main hard drive" and I said yes, because I had my new crap 2 gig hard drive hooked up and bios had recognized it as "primary" and my 40 gig hard drive with all my data was hooked up as secondary. So windows leaves my 2 gig primary hard drive alone and installs windows on a new 2 gig partition on my 40 gig hard drive. I contacted Microsoft repeatedly and after they stopped ignoring me they said sorry your shit out of luck!! So do I "trust" anything from Microsoft? Nope!!!! But you might :) And it's 99/100 going to be ok for you. But still.... I DON'T. It's up to you :)
Bruce is right, because code signing is marketed as a protection against malware and viruses, which of course it is not.
But it works perfectly in large companies where it, properly enforced, is a great way to whitelist the applications your users can run.
That has of course a sort of indirect effect of protection against viruses, but one that could just as easily been done with disabling clicking on attachments entirely.
... I sign my code. As when I was in a team which wrote that large network monitoring application in Java, and we made an applet version of its client. The applet needed to write .tmp files on the user's HD, so we tweaked the SecurityManager, and signed the whole thing.
BUT -- and I insist upon the BUT --- we had tech-savvy users, who knew about code signing. Who KNEW that this was not about absence of bugs, but more about integrity of the coders than about anything else.
Not everyone is blessed with clients who are network admins, able-issimo BOFH and PFY's....
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Google did not give me what I wanted since it assumed US dollars and I'm in Canada forgivable, perhaps since the URL you gave was google.com. However google.ca makes the same assumption which is just plain dumb! The one suggested in the original post took the other approach and included every conversion rate under the sun: want to convert Solomon Island dollars to Egyptian pounts anyone? I think I'll stick to one with the pull down menus to specify currencies precisely since I don't always know the 3 letter currency code.
> 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.
This brings up the issue of "what do we mean by 'trust'". Signing allows us to say with some certainty that the code came from Citrix, but why -should- we trust Citrix more than "Snake Oil Corp"?
In order to trust Citrix, we must determine that:
-Citrix verifies the integrity of the code, ensuring nothing was added without authorization and testing.
-Citrix validates the code to ensure there are no common security flaws.
-BIG point: that the context in which the code will be used is appropriate for the needs of the recipient. This is a big issue when reusing code. A large portion of the flaws in MS products are due to careless code reuse. MS has a buffer overflow in a graphics library, and it affects everything.
> 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.
Often useless in a corporate environment. It's a lot of work to verify and maintain. So much so that many major corporations remove all use of authenticode and trust everyone.
> 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.
Unfortunately, that is how it is -sold-. This also applies to #3. It results in a false sense of security. The point is, verifying the source of the code is, in isolation, useless. The only reason to verify the code is in order to do smething with it. If the mechanisms for using authentication don't support using that authentication for anything other than identification, they aren't useful.
The biggest problem with Microsoft's implementation of code authentication is that it is really designed to be all-or-nothing. They made the same mistake in IE3, and I expect them to make it again. They divided the world into "people I trust absolutely" and "people I don't know". They started to make progress with IE4 when they added "people I know and -do not trust-", but they still don't understand that you may want to trust people -to a certain point- and no farther.
For example, I often trust a parking lot attendant with my car keys. But that doesn't mean I trust him with the keys to my safe deposit box and my credit cards.
Bruce gives 5 reasons why code signing is insecure. Let's look at your arguments that this is wrong, one by one.
Reason one: your argument is that Bruce is correct. Oh.
Reason two: you fully agree with Bruce, but point out that this particular security flaw is in there by design. Ah.
Reason three: see reason two.
Reason four: warming to your theme, you viciously agree with Bruce again.
Reason five: for variety, this time your objection is that you do not understand what Bruce means.
Are there tickets left for your talk?
~~~~~ BigLig2? You mean there's another one of me?
Profit. I can charge developers a fee for applying my signature to thier code, therefore enabling trusted installation and a trusted transaction at my bank that pays for my yacht.
Even better yet, I can expire the cert, requiring the developer to buy a signing again in a year or two.
And the best part: End users have no idea what it's all about and are totally used to getting a pop up durring the install that says click on install anyway when the security notice comes up.
But wait, there's more: One day I'll be able to embed the signing stuff in the hardware so only stuff people pay me to sign will run on the PC they paid for. Then we all make more becase we can expire certs and lock the users out then both of us get to make money when the user says uncle and wants get access to their pr0n database...
-- $G
It was killing me reading the grandfathers "if" "could" and "would" statements, covering the truth in a blanket of assumption.
cyn, free software and *nix operating systems enthusiast.
I have no idea about windows code authentication stuff, I only write unix software. Any windows users of my stuff would have to be running cygwin, in which case they have gpg.
Then they'll likely get the Big Scary Alert Box when they download Cygwin's setup.exe.
Someone could upload a public key of "bobdol@mydomain.com" instead of "bobdole@mydomain.com" and hope people make the typo when they search for the key, and then don't notice when they download and install it, but that's pretty unlikely.
The case in question was about when your site is cracked. If your site is cracked, then of course they'll change the public contact address displayed on the cracked web site and listed in the trojaned program's README from bobdole@mydomain.com to bob_dole@mydomain.com or robertdole@mydomain.com. That's very easy not to notice unless 1. you are upgrading from a previous version, 2. you check the signature of the previous version, and 3. the program has a previous version. And what happens when your site is cracked by someone who's working together with the owner of a trademark on "Mydomain" and who can take away your domain in WIPO proceedings?
Then that would be a phallacy.
OMG, I can't believe I'm lowering myself to this cheap gay-bashing humor. Somebody stop me.
You don't seem to get it. It's got nothing to do with any feature of the software to automagically assume that you trust a given cert based on who signed it. It's got to do with you explicitly deciding to trust a given cert.
When you are asked if you want to trust Paypal, and you say yes, you are implicitly trusting the CA that signed the certificate. You are trusting that verisign ( or whoever ) verified that the certificate request did in fact come from Paypal, and not Joe Cracker.
That's how the chain of trust works. The signing CA is certifiying that they have validated that what this certificate they signed says, is correct. Specifically that it belongs to whom it says it does. It is like accepting driver's licences as identification for people. You are trusting that the DMV made sure that the guy is who he says he is before they issued the license. If you don't believe that the DMV verifies the identity of applicants, then the license you are using for identification isn't worth the paper it is printed on.
My take on code signing, as nicely inspired by your hero and mine, Tommy Boy:
The point is, how do you know the Code Signing Fairy isn't a crazy glue sniffer?
"Building model airplanes" says the little fairy, but we're not buying it. Next thing you know, there's money missing off the dresser and your daughter's knocked up -- I've seen it a hundred times.
They know all you downloaded was a guaranteed piece of shit. That's all it is. Hey, if you want me to take a Word virus and code sign it, I will. I've got spare time. But for right now, for your sake, for your daughter's sake, ya might wanna think about downloading quality code from me.
Blog,Twitter
I'll skip point #1, though it's pretty important, because I think you have an idea why it's there.
#2) Just because a component is signed doesn't mean that it is safe.
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.
But it doesn't do that unless you have a secure automatic revocation mechanism. And if you have such a mechanism, you don't need Code Signing! because the only way to make sure that a piece of code you're presented with isn't on a revocation list is to check the revocation list when you're presented with it... and if you can do that, why do you need to sign the code? You can directly verify the authenticity and integrity of the code by downloading a checksum instead of a revocation list.
#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.
Two things. First, he's pointing out that Code Signing isn't useful for forensics. For example, if someone attacks you using a compromisable signed applet they can remove the evidence that they did it. Secondly and more importantly the signature database becomes a new source of exploits: if you can compromise the signature database, you can sign your exploit code!
Basically, Code Signing is a tool that you can use to reduce the risks incurred by doing something inherently risky: automatically running unrestricted code provided by a potentially untrusted source. There are two reasons you might want to do this: first, because you're concerned with the performance impact of running the untrusted code in a sandbox; second, because you want to avoid the organizational cost of distributing applications to end-users through other mechanisms.
In practice, the performance impact of sandboxing has become a moot point, given the speed of modern computers and the efficiency and capability of scripting languages. The difference between the scripted Google Maps and the native Microsoft Streets and Trips is almost entirely attributable to the difference between remote and local map storage. The user interface itself is similarly smooth and responsive when you're not hitting the network.
As for distribution, the complexity and the amount of manual work involved in making sure each computer is configured to securely allow appropriate signed applets to run without opening up security holes is significant. I find it hard to imagine that distributing software through traditional mechanisms would not be an improvement. Even Microsoft's Software Update requires at least one manual verification step the first time you use it that comparable update mechanisms that use individual package signatures (hashes) manage to avoid.
And it doesn't implement secure automatic revocation, which means that if you find an exploit in a signed package you can continue to use that package as part of an exploit... if the package had to be explicitly downloaded from a secure server, or if a hash of the package had to be fetched from a secure server before it was accepted, then this attack mechanism wouldn't exist.
So... deploying signed code reduces security when compared to explicitly installed code or checksummed packages: it opens you up for attacks from old versions of the package, and it opens you up to attacks that compromise the local signature database.
Which is why Schnier brings up these points... it's not that these are attacks that Code Signing is supposed to prevent, rather they're attacks that Code Signing makes easier.
It has always bothered me when people take the phrase "weight-bearing ambulation" and say things like "Is it OK for the patient to weight bear?"
Bruce criticisms of code signing is that it does not increase security for consumers. /IS/ code signing supposed to do for the consumer?
Your comment is that code signing wasn't meant to increaes security.
OK, so what
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.'
As you point out, signed code does nothing other than "prove" that the code was issued by its purported publisher, who you might trust. Part of the claimed benefit of signed code is that it stores a record of its publisher for later auditing, if the code does something you don't like. But Bruce's argument is that such evidence will not survive a proper malware attack which deletes that evidence once it controls your machine. So that benefit is useless, a false promise of security.
--
make install -not war