Slashdot Mirror
Don't Trust Code Signed by 'Microsoft Corporation'
omarius writes "From the Microsoft Security Bulletin: 'VeriSign, Inc., recently advised Microsoft that on January 30 and 31, 2001, it issued two VeriSign Class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is "Microsoft Corporation".' See the bulletin for more information. Brings a whole new meaning to the concept of 'Windows Update.' ;)" Most users probably ignore the name on a certificate presented to them anyway, but even that minimal protection is worthless if certificate authorities don't perform their job.
In a perfect world, anyway...
- A.P.
--
* CmdrTaco is an idiot.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Better yet, how in hell is Microsoft goint to implement this "patch"? They can't do it securely. How can I trust that this "patch" is really the real one now, and not one that will permantently etch a back door into my system?
Ladies and Gentlemen, the barn door is open, and the genie is molesting the horses.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Instead, they chose to ignore the possibility that the security might be flawed and allow revoked certificates to be used. They didn't give a damn whether someone got a fraudulent code-signing certificate for J. Random Software Company, and the browser couldn't tell that it had been revoked. They've only been prompted to take action when this unexpectedly happened using their own name.
VeriSign made an error and corrected it within two months. Microsoft made a bigger error and has taken five years (and counting) to fix it, then has the gall to blame it all on VeriSign.
We can not only have one company to handle Digital Signatures. The internet community should create a non profit company to help with this problem. I am assuming that Microsoft is not the only company that this has happened to.
Ok...I hope this finally get's Microsoft and Verisign out of their complacent moods, and prompts them both to implement Certificate Revocation Lists capability that WORKS in all of thier offerings -
It is because they haven't bothered to do this yet that this is possible - think about it - if CRLs were implemented, and every application that used Certs checked the Revocation list of the issuing CA, this problem would have a trivial solution - Revoke the Cert, and this "fraudulent" issued cert becomes useless.
But since Microsoft, Netscape/AOL, and most other vendors of Certificate aware software haven't bothered until VERY recently to even think of the CRL, then this is now a rather large problem...
ame)
Anyways... I hope this causes them to go and actually implement RFC compliant CRL capabilities in all of their products - would make those of us who work with them VERY happy....
McAlister
Actually its only accepts code also signed by the identical certificate as this is a different certificate but the same name it would not automatically accept it based on a previous acceptance of "Microsoft"
No, it's due to the effects of the nonstandard "smart quotes" plague.
This goes great with this article from a couple of days ago.
I used to think that the whole idea of paying a shitload of money to goons like Verisign was that you could trust the certificates issued by them. If they make mistakes like this, how can I trust them anymore? Furthermore, how can I trust the certificate any ecommerce site that uses their certificates?
This is a huge problem for all CA's if this is a precedent. I'm really curious to see what, if anything, Verisign will do about this.
Yes, one day I may actually learn to spell...
The problem with any encryption system, neigh any protection system at all, is the point at which they break.
They super heavy deadbolts on my front door are useless if I pass out they key. The electronic security system is just a bunch of lights and buzzers if I give out the passcode or everyone ignores it. The extra heavy combination lock is just dead weight if the hinges of the safe are on the outside of the door.
Public Key cryptography is only as strong as the security on the key. The article says that this doesn't fit the strict definition of a security vulnerability, presumably because it doesn't break the software. Well, I'd like to disagree. Part of the product, part of what M$ sells with the promotion of signed inActiveX controls, is that the pieces of code are trusted. This is not a piece of software they are selling, it's an entire system. The software is only part of it. The system has been broken. This makes it a security vulnerability in the same way that giving out keys to my front door and the combination to my safe are security vulnerabilities.
The gist of my rant, and the point I'm trying to convey, is that systems are more than just the software. To concentrate only on one part of the system when defining terms to describe the safety of the whole system is foolish.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
I dunno, but it seems to me that they have the bigger problem. We put our trust in VeriSign to properly identify people requesting certificates. That trust has been broken now.
---
It's not a problem. The "always trust content from ...." is not on a name basis but on a certificate basis. These phoney (or any other) certificates won't automatically be accepted.
Guess the problem here is that it should have always been up to the end user as to which certificate signing authorities to trust, rather than for software manufacturers to decide for us. At least browsers are getting better, before if they saw a certificate that the browser didn't trust it would reject it outright.
But nowadays if a company becomes untrustworthy through malicious intent or just plain incompetence it's not possible for users to 'un-trust' a certificate authority trusted by the browser/software manufacturers.
There should be a higher degree of control at the end-user as to which CA's are trusted.
-- Greg
Slashdot, would a spell-checker for posting be too much to ask? It's not rocket science!
Don't trust certificates issued by VeriSign?
Then who will you trust?
With the amount of money verisign requires you to pay for their various types of certificates, you would think that they could take the proper steps to ensure that the application is valid? A phonecall to the posted number for the company perhaps?
Running a script to generate a key does not cost hundreds of dollars, we are paying for the extra for the cost of validation. I expect Verisign to DO that validating!
- The lack of CRL support. This is largely MS's fault (no in there) and Verisign's fault (no CDP)
- The all or nothing trust model. This is seriously flawed; you do not get the option of letting a control have a 'little' access.
Both share a good bit of the blame. OTOH, it is more fun to just bash MS.Yes, I'm joking.
(From the NTBUGTRAQ) Despite the fact that its a Microsoft Certificate (for all intents and purposes it appears as such), it WILL NOT automatically be trusted by anyone's system. Even if you have previously stated that you want to trust all signed software from Microsoft, the fact that this one is a *different* Microsoft Certificate means you will still be prompted to trust it.
So it's still a big deal, but if you keep that little bit of knowledge in hand, you wont have to worry (to much)
----------------------------------
Looking for hardware (Currently need: Large Etch-a-Sketch) Have one? See my journal!
Yeah, maybe. Research is currently being done on how to do this without the idea of a trusted party. The general idea is that the code comes with a proof of its safety (or a proof that it meets some other specification), which is "easily" verified by a small piece of software on your computer. It's not a panacea (there is a world of difficulty in specifying the right policies), but it could certainly stop updates of application-level (or especially applet-level) software from containing naughtiness.
Check out http://www.cs.cmu.edu/~petel/papers/pcc/pcc.html for more info on Proof Carrying Code.
What if i would own (I don't by the way ;-) the domain www.microsoff.nl. I register my company 'Microsoff' here in the netherlands, and claim I do window-cleaning (as long as the type of commerce you do is different, you can register a name here).
It should be possible for me to get a Verisign certificate for 'the Microsoff corporation'. Most users won't notice this, so I can trick people into running my code.
Is there anything that can be done against this? Has Microsoft trademarked all 'Microsoft'-alike names? Can Verisign refuse to give out a certificate?
--
--
If code was hard to write, it should be hard to read
Don't Trust Code Signed by 'Microsoft Corporation'
I've had that one covered for the last 18-24 months or so...
--
And the bastards charge money for this service.
Verisign gave out the wrong certificates. If browsers now already have stored these certificates as 'safe', users should remove them, but it's VERISIGN's fault. They should have been more careful when they gave out the certificates. the person who now got the certificates could also have used 'Sun' or 'Red Hat' or any other company. Would that company then be 'the faulty'? NO.
--
Never underestimate the relief of true separation of Religion and State.
This is a security story. The lock logo would have been more appropriate. Oh, wait... every time MS is mentioned on /. you get a spike in ad revenue. Carry on.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I find it very fascinating that MS doesn't mention anything about the hazards of running code from an unknown author.
I would also hope that Verisign is taking a very serious look at their procedures - if CAs don't verify identities before issuing certificates, what good are they?
For that matter, how were individuals - MS employees or not - given keys in the company's name? There's no need for an individual employee to have those - especially before calling to check with executives within the company.
Guys, Microsoft is not nearly as evil as you think it is. Yes, they had a track history, and yes clearly Bill Gates is a dick, but there are a lot of cool OS and game programmers, and hardware specialists that put out some wicked shit. You have to separate the company from the nerds like you and me.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
Hmmm... Verisign and Microsoft... now there's a team that just reaks of reliability!
Surprised? - Not really
Worried? - No more than yesterday
Still accepting certs without EVER reading them? - You Bet Your Sweet Ass!!!
It's not just an OS, It's an adventure!
I am become Troll, destroyer of threads
They make me send them multiple faxes and wait two weeks when I forgot my domain password, but some guy says he's from MS and that's good enough for them?
-- dR.fuZZo
VeriSign has revoked the certificates, and they are listed in VeriSign's current Certificate Revocation List (CRL). However, because VeriSign's code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser's CRL-checking mechanism to download the VeriSign CRL and use it. Microsoft is developing an update that rectifies this problem. The update package includes a CRL containing the two certificates, and an installable revocation handler that consults the CRL on the local machine, rather than attempting to use the CDP mechanism.
Translation: This cert is bad, but the authority issuing it can't tell you this, even though the authority claims to be responsible for doing so. Microsoft and said authority didn't think of this, and so they now have to come up with a totally kludgey patch which they promise won't break anything else.
This is so fucking confusing even to someone who is fairly technical - can you imagine Joe User's reaction to this? Makes code signing pretty much useless.
sulli
RTFJ.
We trusted MS Before?! Did i blink and miss something?
This certainly adds a new dimension to recent /. discussions about what, exactly, you get when you pay for an expensive certificate!!
-------------------------
-------------------------
A person of moderate zeal
What if the hacker(s) releases a patch before MS releases one?
I love the smell of Karma in the morning
That may sound like a bold statement, but if you think about it for a moment, can you ever trust an automated software update again, even a "secure" one?
OK,
- B
--
http://www.bradheintz.com/
- updated
I know it's Verisign's fault, but it really doesn't make the consumer side of .NET sound very trustworthy. I understand they're going to be using Kerebos for the Hailstorm identity back-end, but clearly there's plenty of room for Microsoft to botch. They're well positioned (and well funded) to actually go head with it, but the question is how much will people trust Microsoft? Even paired up with AmEx?
-- "Sucks to your ass-mar"
That dialog refers to the organization that signed the certificate. Most browsers (at least, IE and Netscape) come equipped to trust any certificate signed by Verisign. When you go to a page with a Verisign cert, the browser will trust the certificate, regardless of what company actually owns it.
Since in this case the certs were purchased from Verisign, your browser won't have any problem at all with them (it'll just assume that Verisign is trustworthy.) You won't get that dialog at all. If you look at the security info for that page, it'll show the page as registered to Microsoft corporation. Generally MS signs their own certificates, so it would be a little odd to see a cert owned by MS and signed by Verisign (although they may actually do this.)
It's usually not hard to figure out if you're getting a MS product online.
The files tend to come from domains like, oh, say, microsoft.com or mechwarrior4.com...
Now, of course, if you are trying to download 'http://ftp.goatse.cx/hotgaypr0n.exe' and it's signed by MS you a) have other problems and b) deserve whatever you get if you accept the file.
Of course, this is probably not too good for Verisign, as they now look like dumbasses, and have probably pissed off MS to boot.
Brant
Brant
Argle. Bargle.
http://www.verisign.com/repository/CPS/CPSCH2.HTM# _toc361806948
http://www.verisign.com/products/asb/faq.html
Especially interseting is the Assurance level that comes with this cert.
Even if these certiciates are never used, there will be some pretty heavy US govt. involvement as a result of this.
Anyone know if this has happened with any companies less visible than MS? A quick search did not turn anything up, but if Versign's procedures could let something like this slip through...