You could. But you haven't. In fact, there is no big crime wave of criminals replacing Mozilla dowloads with Microsoft Bob installers. Ergo, it's not currently a big problem in practice.
So all of those email worms don't entice users to open the attachment by naming their payload as awesomescreensaver.exe huh?
No, you are missing the point. The point is that Microsoft is wasting time on fixing hypothetical problems while failing to fix their actual security problems adequately.
I suppose you don't recall an incident years ago where some virus managed to make its way onto a cd and onto store shelves.
A hole is a hole. Saying "well, it isn't a problem yet" doesn't change that.
So your answer is "just download it and pray that the site you're getting it from hasn't been 0wn3d?"
So, for the sake of arguement, lets say I follow this approach. I download a copy. Two days later I'm reading a website that in big red letters announces that a Mozilla mirror got hacked and the install was replaced with something that does something nasty. How do I know that I have a hacked binary? "Just download it and re-install and you should be ok". So, having done that, how do I know that copy hasn't been hacked as well?
What you are defining as a "trust" layer is not sufficient evidence to determine that the binary that you think you have is what you really have. 99% of the time that is probably sufficient. It's the remaining 1% of the time that hurts.
Ordering a phsyical cd would be sufficient. But that isn't a download, now is it?
Then the signature on the md5sum makes sure the filename hasn't been changed. I suppose this is what you meant.
I was saying that you could compare the MD5 sum of the unknown but untampered with file to well known MD5 sums of file produced by (for example) the Mozilla Foundation to determine which binary it was that you actually got.
But that would be overly complicated.
However, in this case what you said about compromised MD5 sums doesn't make sense. Both the MD5 and the GPG signatures would be generated in a secure environment. If we do things this way, the MD5 would be signed, which makes any tampering trivially detectable.
Unfortunately, MD5 is just a checksum. It doesn't matter where you generate it -- it will have collisions. You should not solely trust a checksum for anything where security is involved (ie: don't depend on it to say that the file hasn't been altered). That's the the PGP signature is for.
Forgive me if a ramble a bit; it's late and I'm tired.:)
That would be a limitation imposed by "limiations"/lack of functionality on the unix side. In the Windows world, you'd be easily able to tell that this occured by looking at the version tab on the binary properties.
That aside, it is still a problem. However, it is mitigated somewhat by the fact that you can still be certain that the binary is not malware (if you trust Mozilla to not produce any malware) and that it did indeed come from the people you thought you downloaded it from. You will not know if it is a version that fixes a certain security hole before starting it up, but this is something that can be solved by software ("A new version is available" dialog boxes and the like which appear before you start surfing). You can trust such mechanisms to work because you know that an attacker can't modify that process, because they are not able to sign the binary. This does, of course, assume that there was not a version available with bugged update checks and the like.
If you use the PGP signature in conjunction with MD5 sums, it should be possible to identify authoratively which file you actually obtained before you execute it. But again, this depends on the site you obtain the MD5 sums from is not compromised.
The only comprehensive solution I can think of would involve placing all of the information required to verify the authenticity of a binary in the file itself in a manner which cannot be modified once it gets "signed." Which is pretty much what binary signing does in the Windows world.
For linux, the best solution today would probably be sticking everything required to verify the authenticity of a binary into an archive and make the PGP signature of that archive available. That way you can verify that the archive hasn't been tampered with, and can examine the version/contents before installing it to assure yourself that you're dealing with what you intended to deal with.
It is one step in the verification. You know that it has to be something that Mozilla Foundation signed, and that the contents of the file haven't been altered since they signed it. This means that the description of the executable in the version tab could not have been altered.
So if you trust the Mozilla Foundation enough to think that they produce a binary that won't bork your machine, you probably trust them enough not to produce an incorrect desciption for the file. If you don't trust them that much, you shouldn't trust a binary signed by them in the first place.
The thing to look at is the record, plain and simple. And the record shows that, until now, code signing does not address the major security problems that people have with IE
It isn't supposed to. But congrats on completely missing the point. The point is that when you download Mozilla you don't have a way to verify that you really downloaded Mozilla.
In other words, I could rename the Microsoft Bob installer to the same name as the Mozilla installer, give it to you to download, and you wouldn't have a clue that it wasn't Mozilla until you ran the program.
He raises some interesting concerns about the download locations I think, legitimate concerns, but beyond that it's a bunch of obvious FUD drivel. The security warning dialogs he mentions, while legitimate issues for novice users, are a result of the way IE handles potentially unsafe content, NOT the fault of Firefox.
Actually, it is the fault of Firefox. They aren't signing their binary in a way that allows the content of the download to be verified.
The content of the warning is not "ooh, IE has a problem with this", its "I can't tell you if this program is from who it claims to be".
As well it should make you nervous. Looks a lot like the urls you see on phishing mails.
So, now that you are wishy washy on the source you're downloading a program from, what do you do? Do you run it anyway and hope for the best, or do you take two seconds to check the signature on the binary first to verify that it was signed by Microsoft?
In the meantime, the trojan'd binary will turn off the AV scanners and turn the machine into a zombie for spammers.
You should NEVER Ever EVER *EVER* let malicious code run on your system. Once it runs, you're fucked. The damage is done. Such a passive dismissive attitude towards such events is just retarded. Deplorable even.
Instead of doing something right, you're advocating doing it in a half assed manner for no good reason at all. But that's ok, because Ma will be told on the news that the shiney new program everyone was telling her to download has a huge problem and she needs to have her nephew who knows computers to come by and clean up the mess.
Yes, that's exactly what OSS needs to advance the cause. *rolls eyes*
SSL connections to a webserver don't have a damn thing to do with signing the binary. You don't sign a binary when you download it; the signing occurs as part of the build process.
Except it isn't. You know exactly what you're getting when you look at that signature. If the site claimed it was a VRML viewer and the binary wasn't signed, you wouldn't have the slightest clue if it was a VRML ActiveX control or something else designed to 0wn your box.
Signatures aren't there to tell you if the software is safe to run or not. It's there to let you know where it came from and that it hasn't been tampered with.
I guess I was trying to say, though, complete (or near complete) confidence in knowing the code you're downloading really isn't "tampered with" is a relatively minor issue for most people.
Which is a HUGE problem. Blind trust in software you download from a random location is a very, very bad thing. Think of the other system which depends on blind trust in the internet community that is in common use today: SMTP. Get much spam lately?
Microsoft is really grasping at straws, trying to punch holes in Mozilla/Firefox credibility, by bringing up relative non-issues like this. The fact remains, people are much more confident they have a "safe browser" when they use Firefox than when they use IE, and this is because of everyone's actual experiences using both products and witnessing the results others are reporting.
He isn't saying Firefox isn't a safe browser. He's saying you have no way of knowing if you are using the real Firefox in the first place!
Not worthless, but merely having an MD5 doesn't prove anything one way or the other. It tells you nothing about the point of origin -- it is just a file checksum.
So, you would now have to get that checksum from somewhere. Which means you need to get that checksum from a trusted location (ie: the mozilla website and only the mozilla website). And then you have to trust that checksum is correct, and that the site you're looking at hasn't been hacked (it's easier to hack a site than it is to steal a signing key if a company manages their keys properly). You must also use tools from a trusted source to verify that hash (because otherwise, the hash you're checking may have a sequence encoded in it that says "always report success for this file").
That last part is the kicker, because if you use MD5 hashes to verify the tool you use the validate MD5s, you get stuck in a catch22 situation.
So if you manage to solve all of the above problems, you now have to perform a manual process before you launch the application to verify that the binary hasn't been mucked with since the last time you ran it. Though when you do this, there is still a short window of time between when you verify the checksum and launch the application in which the application could be modified/replaced. Ideally this check would occur at an OS level after the binary has been loaded into memory for best effect and no user intervention would be requred.
Also, something else to keep in mind is that an MD5 sum is a checksum; there are ways to modify binaries such that MD5 sums will not change (though still probably impracticle to accomplish) and there are also hash collisions. There is no cyrptography involved in the generation of an MD5 sum.
I would argue that a PGP signature would be more appropriate than an MD5 sum for this purpose.
Slashdot Mirror
Great. 3 years from now when you've read through all the source and are certain that it hasn't been tampered with, let me know.
You could. But you haven't. In fact, there is no big crime wave of criminals replacing Mozilla dowloads with Microsoft Bob installers. Ergo, it's not currently a big problem in practice.
So all of those email worms don't entice users to open the attachment by naming their payload as awesomescreensaver.exe huh?
No, you are missing the point. The point is that Microsoft is wasting time on fixing hypothetical problems while failing to fix their actual security problems adequately.
I suppose you don't recall an incident years ago where some virus managed to make its way onto a cd and onto store shelves.
A hole is a hole. Saying "well, it isn't a problem yet" doesn't change that.
So your answer is "just download it and pray that the site you're getting it from hasn't been 0wn3d?"
So, for the sake of arguement, lets say I follow this approach. I download a copy. Two days later I'm reading a website that in big red letters announces that a Mozilla mirror got hacked and the install was replaced with something that does something nasty. How do I know that I have a hacked binary? "Just download it and re-install and you should be ok". So, having done that, how do I know that copy hasn't been hacked as well?
What you are defining as a "trust" layer is not sufficient evidence to determine that the binary that you think you have is what you really have. 99% of the time that is probably sufficient. It's the remaining 1% of the time that hurts.
Ordering a phsyical cd would be sufficient. But that isn't a download, now is it?
It means that someone doesn't understand the purpose of a signature.
So tell me, how do you know that the binary you download off of a Mozilla mirror is really Mozzila without some sort of signature?
"Because it's a site Mozilla links to" is insufficient, as 'I' don't trust anything but the content under the control of the Mozilla website.
The alternative is to build and sign the binary properly. There isn't some magic bit Microsoft is hiding preventing this from happening.
Then the signature on the md5sum makes sure the filename hasn't been changed. I suppose this is what you meant.
I was saying that you could compare the MD5 sum of the unknown but untampered with file to well known MD5 sums of file produced by (for example) the Mozilla Foundation to determine which binary it was that you actually got.
But that would be overly complicated.
However, in this case what you said about compromised MD5 sums doesn't make sense. Both the MD5 and the GPG signatures would be generated in a secure environment. If we do things this way, the MD5 would be signed, which makes any tampering trivially detectable.
Unfortunately, MD5 is just a checksum. It doesn't matter where you generate it -- it will have collisions. You should not solely trust a checksum for anything where security is involved (ie: don't depend on it to say that the file hasn't been altered). That's the the PGP signature is for.
Forgive me if a ramble a bit; it's late and I'm tired. :)
That would be a limitation imposed by "limiations"/lack of functionality on the unix side. In the Windows world, you'd be easily able to tell that this occured by looking at the version tab on the binary properties.
That aside, it is still a problem. However, it is mitigated somewhat by the fact that you can still be certain that the binary is not malware (if you trust Mozilla to not produce any malware) and that it did indeed come from the people you thought you downloaded it from. You will not know if it is a version that fixes a certain security hole before starting it up, but this is something that can be solved by software ("A new version is available" dialog boxes and the like which appear before you start surfing). You can trust such mechanisms to work because you know that an attacker can't modify that process, because they are not able to sign the binary. This does, of course, assume that there was not a version available with bugged update checks and the like.
If you use the PGP signature in conjunction with MD5 sums, it should be possible to identify authoratively which file you actually obtained before you execute it. But again, this depends on the site you obtain the MD5 sums from is not compromised.
The only comprehensive solution I can think of would involve placing all of the information required to verify the authenticity of a binary in the file itself in a manner which cannot be modified once it gets "signed." Which is pretty much what binary signing does in the Windows world.
For linux, the best solution today would probably be sticking everything required to verify the authenticity of a binary into an archive and make the PGP signature of that archive available. That way you can verify that the archive hasn't been tampered with, and can examine the version/contents before installing it to assure yourself that you're dealing with what you intended to deal with.
The kind of moron who uses a computer that isn't 5 years old. :p
It is one step in the verification. You know that it has to be something that Mozilla Foundation signed, and that the contents of the file haven't been altered since they signed it. This means that the description of the executable in the version tab could not have been altered.
So if you trust the Mozilla Foundation enough to think that they produce a binary that won't bork your machine, you probably trust them enough not to produce an incorrect desciption for the file. If you don't trust them that much, you shouldn't trust a binary signed by them in the first place.
You're still downloading something. How do you know that the source code you downloaded hasn't been tampered with?
Get SP2 already, geeze...
That's not a bad position to take for internal projects. The instant you expect outside sources to trust YOU, it no longer works.
As an outside, self signed material does not give me any more reason to trust you than unsigned content.
The thing to look at is the record, plain and simple. And the record shows that, until now, code signing does not address the major security problems that people have with IE
It isn't supposed to. But congrats on completely missing the point. The point is that when you download Mozilla you don't have a way to verify that you really downloaded Mozilla.
In other words, I could rename the Microsoft Bob installer to the same name as the Mozilla installer, give it to you to download, and you wouldn't have a clue that it wasn't Mozilla until you ran the program.
He raises some interesting concerns about the download locations I think, legitimate concerns, but beyond that it's a bunch of obvious FUD drivel. The security warning dialogs he mentions, while legitimate issues for novice users, are a result of the way IE handles potentially unsafe content, NOT the fault of Firefox.
Actually, it is the fault of Firefox. They aren't signing their binary in a way that allows the content of the download to be verified.
The content of the warning is not "ooh, IE has a problem with this", its "I can't tell you if this program is from who it claims to be".
As well it should make you nervous. Looks a lot like the urls you see on phishing mails.
So, now that you are wishy washy on the source you're downloading a program from, what do you do? Do you run it anyway and hope for the best, or do you take two seconds to check the signature on the binary first to verify that it was signed by Microsoft?
In the meantime, the trojan'd binary will turn off the AV scanners and turn the machine into a zombie for spammers.
You should NEVER Ever EVER *EVER* let malicious code run on your system. Once it runs, you're fucked. The damage is done. Such a passive dismissive attitude towards such events is just retarded. Deplorable even.
Instead of doing something right, you're advocating doing it in a half assed manner for no good reason at all. But that's ok, because Ma will be told on the news that the shiney new program everyone was telling her to download has a huge problem and she needs to have her nephew who knows computers to come by and clean up the mess.
Yes, that's exactly what OSS needs to advance the cause. *rolls eyes*
No, it means that he doesn't give a crap if he downloads a trojan that formats the harddrive, because he's running everything inside of VPC.
Good grief; I need to break out my cluebat.
SSL connections to a webserver don't have a damn thing to do with signing the binary. You don't sign a binary when you download it; the signing occurs as part of the build process.
Except it isn't. You know exactly what you're getting when you look at that signature. If the site claimed it was a VRML viewer and the binary wasn't signed, you wouldn't have the slightest clue if it was a VRML ActiveX control or something else designed to 0wn your box.
Signatures aren't there to tell you if the software is safe to run or not. It's there to let you know where it came from and that it hasn't been tampered with.
You can't. This is one of the many problems with "manual" verification.
Maybe I'm dense, but that didn't make much sense to me ...
I guess I was trying to say, though, complete (or near complete) confidence in knowing the code you're downloading really isn't "tampered with" is a relatively minor issue for most people.
Which is a HUGE problem. Blind trust in software you download from a random location is a very, very bad thing. Think of the other system which depends on blind trust in the internet community that is in common use today: SMTP. Get much spam lately?
Microsoft is really grasping at straws, trying to punch holes in Mozilla/Firefox credibility, by bringing up relative non-issues like this. The fact remains, people are much more confident they have a "safe browser" when they use Firefox than when they use IE, and this is because of everyone's actual experiences using both products and witnessing the results others are reporting.
He isn't saying Firefox isn't a safe browser. He's saying you have no way of knowing if you are using the real Firefox in the first place!
A numeric IP address, the likes of which you only see on a regular basis in phishing email scams.
Not worthless, but merely having an MD5 doesn't prove anything one way or the other. It tells you nothing about the point of origin -- it is just a file checksum.
So, you would now have to get that checksum from somewhere. Which means you need to get that checksum from a trusted location (ie: the mozilla website and only the mozilla website). And then you have to trust that checksum is correct, and that the site you're looking at hasn't been hacked (it's easier to hack a site than it is to steal a signing key if a company manages their keys properly). You must also use tools from a trusted source to verify that hash (because otherwise, the hash you're checking may have a sequence encoded in it that says "always report success for this file").
That last part is the kicker, because if you use MD5 hashes to verify the tool you use the validate MD5s, you get stuck in a catch22 situation.
So if you manage to solve all of the above problems, you now have to perform a manual process before you launch the application to verify that the binary hasn't been mucked with since the last time you ran it. Though when you do this, there is still a short window of time between when you verify the checksum and launch the application in which the application could be modified/replaced. Ideally this check would occur at an OS level after the binary has been loaded into memory for best effect and no user intervention would be requred.
Also, something else to keep in mind is that an MD5 sum is a checksum; there are ways to modify binaries such that MD5 sums will not change (though still probably impracticle to accomplish) and there are also hash collisions. There is no cyrptography involved in the generation of an MD5 sum.
I would argue that a PGP signature would be more appropriate than an MD5 sum for this purpose.