The point of a justice system is not to punish the guilty as a deterrent. The point of a justice system is to prevent the victims from punishing the guilty and their family and their family's family.
The victims could punish the guilty just fine, and that would be a strong deterrent, probably stronger than the current US justice system, but this leads to the whole Hatfields vs. McCoys thing, back and forth retribution. In order to maintain an orderly society it is necessary to prevent direct retribution.
I do agree with you about the problem with antitrust remediation penalties though - there needs to be some punitive as well as preventative penalties. On the other hand, if Judge Kelly is starting to realize that the preventative measures aren't working, perhaps she'll think some more about breaking up MS...
The paper mentions that things like palladium may also have this kind of problem (unless they implement timing protections of some sort), which leads me to believe the 2048-bit X-Box key could also be attacked this way, and probably much faster since you might be able to attack it right on the box without going over a network.
Sorting through 50 million lines of code, finding hundreds of thousands of vulnerabilities to exploit in windows, and thereby becoming the predominant information-warfare player, at least in terms of potential mass disruption, on the planet.
And of course, the fact that BJGates is giving India $100 million to fight AIDS has nothing to do with it either.
Could BJGates really be so evil as to use a donation of $100m for "fighting AIDS" to swing a subcontinental software decision his way, while planning to get it all back and more with "upgrade" licenses in the future?
Back in late 1999, early 2000, Business.com for $7.5 million. $625k per byte of the name.
Back when there was such a thing as "domain name investing", there was a "land grab" in domain names, squatters were buying them up by the thousands...
You can still find them, in there pathetic little websites, trying to sucker $300 out of some fool who hasn't heard. The game is over, the land boom went bust, so get back in line, put your back into it boy. We need a thousand more lines of code out of you before sunrise, bonuses are cancelled, and all your friends are fired.
That's just what we need, a bunch of money-hungry real-estate magnates cutting down all the trees on the moon and polluting all the pristine streams and rivers with their construction runoff.
Not to mention all the wildlife that is displaced by this kind of thing. And why? I mean, sure, housing may be more affordable further out, but the commute is always worse...
You should read the book Security Engineering by Ross Anderson. I am in the Network Security business, but this book covers all kinds of aspects of security. Interestingly, it is all about looking at different systems and attacks, even Identify Friend or Foe systems from the military, but about a week after reading it everything seems to click together and you start to understand about how to go about engineering secure systems. There are two main points to the book. One is that systems change, their requirements change over time as they become used by more people, but often the security component does not evolve with the system. That is one source of problems. The other is that where systems interact and interface, you are likely to have security problems. Anyhow, this book spans the gamut from banks and accounting security to nuclear security, and I highly recommend it.
Arbitrary code can always be inserted. The goal is not to prevent insertion of arbitrary code, but simply to have strong authentication (on the server) of who made what changes, so that, if you are compromised, you can use a strong crypto system to detect which changes are not from somebody you trust.
Your comment about commit conflicts is probably a good point. Perhaps when a conflict occurs and there is no authoritative version (i.e. there must be multiple versions?) both versions are hashed by the server?
Signed distributions don't really protect against this - you pretty much have to audit all the changes since the last distribution before security was compromised, assuming you know when security was compromised. If you don't know when, then it's probably wise to audit the entire source for your project.
The solution to this kind of problem does involve digital signing, though - digital signing of each code check-in by the author. This way you have accountability for each check-in, and you can just prune out all the "anonymous" check-ins. As long as you keep your private key safe on your dev box, compromises to the repository can't be undetectable (though they can go undetected if you're not looking for them).
I wonder how hard it would be to modify CVS to add a little delta-signing? Might not be possible if CVS uses reverse deltas (like most repositories do).
Basically you want to be able to run a utility on the source tree that verifies the identity of each check-in by cryptographically verifying an actual file hash signature of some sort. It would need to maintain a collection of the public keys used in signing to do this, so you need some key exchange protocol. In order to verify the signature of each check-in, we need to know what the set of data is for each check in. Typically it is a "delta" (basically the output of diff), or a set of deltas for a merge.
The problem with signing the deltas is, most modern systems don't keep the deltas. Instead, they update the "tip" with your changes (this is an optimization, since the tip is the most requested version (with the exception of our waitress the other day, who said "I don't want the tip, baby, I want the whole thing!")), and then generate "reverse deltas" which are applied to the tip version if you need to go back in time.
On the other hand, the forward deltas can probably be computed from the reverse deltas, so signatures on normal deltas could be verified with some computation. Alternately, the reverse deltas could be computed by the client (this is probably bad performance-wise) and signed.
Better yet, since we're client-server-ish with CVS, you could submit your changes, the server could hash the set of reverse deltas after it's computed them, send the hash back to you, and you could sign (encrypt with your private key) the hash and send it back.
That way, there is a quick way to verify who made each set of changes, without too much network bandwidth lost. To verify, the server can take the hash of the existing set of reverse deltas from a particular merge, then use your public key to decrypt the "signature" hash, and compare. If they are the same, then the delta files have not been tampered with.
The question with this approach is, how do you protect the tip? In a reverse delta system, protecting the deltas is only half the battle (well a lot of things are half the battle! Losing is half the battle!) If you can't verify the authenticity of the tip, then an intruder can modify the tip and not touch the deltas, and you couldn't detect it. That's bad. I think in order to protect the tip, in addition to signing the hashes of the deltas, you should also sign a hash generated from the full and updated versions of all the files you touched with your merge. This way we should be able to verify both the tip versions and all the deltas, and have some accountability (we can associate 'nyms with each public key we have).
Sounds like you would need to alter the pserver protocol, add some hashing to the post-merge processing, and update the clients with some GPG code so they could sign hashes.
"Before (the hurricane) has a chance to gather much strength and speed as it travels westward toward Florida, oil is spread over the sea and ignited. There is an updraft. Air from the surrounding region, which includes the developing hurricane, rushes in to fill the void. The rising air condenses so that some of the water in the whirling mass falls as rain."
One thing we do, in particular when evaluating which bugs to fix in the next release, is look at pain (severity in other posts), what problem this defect is causing to the users, and also look at the number of users having this problem (in the case of a bug that is found before it is shipped, this would be the likelihood that the defect will occur in the field).
We have shipped a product that bluescreened under somewhat obscure conditions. I think of our 10,000 customers, one managed to get it to happen. We knew about it beforehand, the dev and QA staff had a fit, but we shipped anyway (of course, two of the twenty developers is still on that project anymore, but that's a different story;)
Some defects that seemed trivial, like stupid cosmetic errors in reporting, were fixed, because every single user saw them and complained about them (well not every single user)
Of course, we did try to track down the blue screen, but we never did. According to MS, blue screens (on NT/w2k) are never the fault of the app running in user mode anyway, so we were able to shift the blame to MS. The point is, another factor in what you fix is whether or not it is fixable by your dev staff (how long you are willing to spend trying to fix it before you give up).
So the three big factors are: How severe is the defect, how many people see it or are likely to see it, and how long do we think it will take (or how long have we spent trying) to fix it.
Personally I like the "pride" idea, but it doesn't sit well with management/sales. Where you see this is in private companies like id software, that doesn't have to maintain earnings to the street will keep their stock at a reasonable level, etc. In a public company, management needs to cut their losses and get product out the door - they can always fix bugs in the next version, but they can't make revenue from the current version until they ship it.
An interesting dilemma to be sure, especially when dealing with four or five year old applications that nobody really understands anymore...
I'm still trying to understand how democracy is so easily usurped by capitalism
Which part of campaign contribution don't you understand? Democracy is easily usurped because it costs money to get votes, and the capitalists have all the money. So the would-be policy-maker has to pander to the capitalists' twisted desires in order to win.
How about a 3D version of those cool 2D puzzle games like The Incredible Machine (TM?)? In these games, you had to create a Rube Goldberg device to accomplish a specific task (such as getting a basketball into a particular location), given a set of pieces like light bulbs, magnifying glasses, hamster wheels (for generating power for the light bulb), magnifying glasses (for lighting fuses on the...), dynamite, pulleys, gears, etc.
I always wondered why nobody did a 3D version - perhaps because it would be more difficult than the 2D version?
There was a recent alert on Cisco IOS predictability (http://archives.neohapsis.com/archives/cisco/2001 -q1/0009.html) , and when I saw that I wondered if this might lead to a problem with BGP? BGP an internetworking routing protocol (i.e. for routing between autonomous networks), it runs over TCP, but my understanding is one typical security measure used is that it only accepts connections from its nearest neighbors (perhaps based on ARPing their IP addresses?).
Anyhow, if you could spoof BGP traffic from a trusted IP address to a backbone router, you could probably do a lot of harm. I'm not sure that it's possible, but if it is, perhaps that's what the Guardent advisory is about.
Phil
Slashdot Mirror
Boy does this ever miss the point.
The point of a justice system is not to punish the guilty as a deterrent. The point of a justice system is to prevent the victims from punishing the guilty and their family and their family's family.
The victims could punish the guilty just fine, and that would be a strong deterrent, probably stronger than the current US justice system, but this leads to the whole Hatfields vs. McCoys thing, back and forth retribution. In order to maintain an orderly society it is necessary to prevent direct retribution.
I do agree with you about the problem with antitrust remediation penalties though - there needs to be some punitive as well as preventative penalties. On the other hand, if Judge Kelly is starting to realize that the preventative measures aren't working, perhaps she'll think some more about breaking up MS...
The paper mentions that things like palladium may also have this kind of problem (unless they implement timing protections of some sort), which leads me to believe the 2048-bit X-Box key could also be attacked this way, and probably much faster since you might be able to attack it right on the box without going over a network.
But I could be wrong.
Phil
Sorting through 50 million lines of code, finding hundreds of thousands of vulnerabilities to exploit in windows, and thereby becoming the predominant information-warfare player, at least in terms of potential mass disruption, on the planet.
Someone in China is smiling sagely over this one.
Could BJGates really be so evil as to use a donation of $100m for "fighting AIDS" to swing a subcontinental software decision his way, while planning to get it all back and more with "upgrade" licenses in the future?
Yeah, perhaps he could...
Phil
Back in late 1999, early 2000, Business.com for $7.5 million. $625k per byte of the name.
Back when there was such a thing as "domain name investing", there was a "land grab" in domain names, squatters were buying them up by the thousands...
You can still find them, in there pathetic little websites, trying to sucker $300 out of some fool who hasn't heard. The game is over, the land boom went bust, so get back in line, put your back into it boy. We need a thousand more lines of code out of you before sunrise, bonuses are cancelled, and all your friends are fired.
How much is business.com worth now?
That's just what we need, a bunch of money-hungry real-estate magnates cutting down all the trees on the moon and polluting all the pristine streams and rivers with their construction runoff.
Not to mention all the wildlife that is displaced by this kind of thing. And why? I mean, sure, housing may be more affordable further out, but the commute is always worse...
Phil
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?Vi
Check it out! $360 last I checked...
Phil
I'll upgrade to Windows Me:
Right away 6009 (13%)
In a few months 4153 (9%)
When I buy a new computer 9693 (22%)
When Hell freezes over 24835 (56%)
To vote yourself, go to http://www.zdnet.com/anchordesk/stories/story/0,10 738,2627324,00.html?chkpt=zdhpnews02 and show them what you think!
Phil
Arbitrary code can always be inserted. The goal is not to prevent insertion of arbitrary code, but simply to have strong authentication (on the server) of who made what changes, so that, if you are compromised, you can use a strong crypto system to detect which changes are not from somebody you trust.
Your comment about commit conflicts is probably a good point. Perhaps when a conflict occurs and there is no authoritative version (i.e. there must be multiple versions?) both versions are hashed by the server?
Phil
Signed distributions don't really protect against this - you pretty much have to audit all the changes since the last distribution before security was compromised, assuming you know when security was compromised. If you don't know when, then it's probably wise to audit the entire source for your project.
The solution to this kind of problem does involve digital signing, though - digital signing of each code check-in by the author. This way you have accountability for each check-in, and you can just prune out all the "anonymous" check-ins. As long as you keep your private key safe on your dev box, compromises to the repository can't be undetectable (though they can go undetected if you're not looking for them).
I wonder how hard it would be to modify CVS to add a little delta-signing? Might not be possible if CVS uses reverse deltas (like most repositories do).
Basically you want to be able to run a utility on the source tree that verifies the identity of each check-in by cryptographically verifying an actual file hash signature of some sort. It would need to maintain a collection of the public keys used in signing to do this, so you need some key exchange protocol. In order to verify the signature of each check-in, we need to know what the set of data is for each check in. Typically it is a "delta" (basically the output of diff), or a set of deltas for a merge.
The problem with signing the deltas is, most modern systems don't keep the deltas. Instead, they update the "tip" with your changes (this is an optimization, since the tip is the most requested version (with the exception of our waitress the other day, who said "I don't want the tip, baby, I want the whole thing!")), and then generate "reverse deltas" which are applied to the tip version if you need to go back in time.
On the other hand, the forward deltas can probably be computed from the reverse deltas, so signatures on normal deltas could be verified with some computation. Alternately, the reverse deltas could be computed by the client (this is probably bad performance-wise) and signed.
Better yet, since we're client-server-ish with CVS, you could submit your changes, the server could hash the set of reverse deltas after it's computed them, send the hash back to you, and you could sign (encrypt with your private key) the hash and send it back.
That way, there is a quick way to verify who made each set of changes, without too much network bandwidth lost. To verify, the server can take the hash of the existing set of reverse deltas from a particular merge, then use your public key to decrypt the "signature" hash, and compare. If they are the same, then the delta files have not been tampered with.
The question with this approach is, how do you protect the tip? In a reverse delta system, protecting the deltas is only half the battle (well a lot of things are half the battle! Losing is half the battle!) If you can't verify the authenticity of the tip, then an intruder can modify the tip and not touch the deltas, and you couldn't detect it. That's bad. I think in order to protect the tip, in addition to signing the hashes of the deltas, you should also sign a hash generated from the full and updated versions of all the files you touched with your merge. This way we should be able to verify both the tip versions and all the deltas, and have some accountability (we can associate 'nyms with each public key we have).
Sounds like you would need to alter the pserver protocol, add some hashing to the post-merge processing, and update the clients with some GPG code so they could sign hashes.
Any volunteers? ;)
Phil
Doesn't heat *fuel* hurricanes?
Phil
One thing we do, in particular when evaluating which bugs to fix in the next release, is look at pain (severity in other posts), what problem this defect is causing to the users, and also look at the number of users having this problem (in the case of a bug that is found before it is shipped, this would be the likelihood that the defect will occur in the field).
We have shipped a product that bluescreened under somewhat obscure conditions. I think of our 10,000 customers, one managed to get it to happen. We knew about it beforehand, the dev and QA staff had a fit, but we shipped anyway (of course, two of the twenty developers is still on that project anymore, but that's a different story ;)
Some defects that seemed trivial, like stupid cosmetic errors in reporting, were fixed, because every single user saw them and complained about them (well not every single user)
Of course, we did try to track down the blue screen, but we never did. According to MS, blue screens (on NT/w2k) are never the fault of the app running in user mode anyway, so we were able to shift the blame to MS. The point is, another factor in what you fix is whether or not it is fixable by your dev staff (how long you are willing to spend trying to fix it before you give up).
So the three big factors are: How severe is the defect, how many people see it or are likely to see it, and how long do we think it will take (or how long have we spent trying) to fix it.
Personally I like the "pride" idea, but it doesn't sit well with management/sales. Where you see this is in private companies like id software, that doesn't have to maintain earnings to the street will keep their stock at a reasonable level, etc. In a public company, management needs to cut their losses and get product out the door - they can always fix bugs in the next version, but they can't make revenue from the current version until they ship it.
An interesting dilemma to be sure, especially when dealing with four or five year old applications that nobody really understands anymore...
PhilTheChill
Which part of campaign contribution don't you understand? Democracy is easily usurped because it costs money to get votes, and the capitalists have all the money. So the would-be policy-maker has to pander to the capitalists' twisted desires in order to win.
Simple as that.
Phil
How about a 3D version of those cool 2D puzzle games like The Incredible Machine (TM?)? In these games, you had to create a Rube Goldberg device to accomplish a specific task (such as getting a basketball into a particular location), given a set of pieces like light bulbs, magnifying glasses, hamster wheels (for generating power for the light bulb), magnifying glasses (for lighting fuses on the...), dynamite, pulleys, gears, etc.
I always wondered why nobody did a 3D version - perhaps because it would be more difficult than the 2D version?
Phil
Anyhow, if you could spoof BGP traffic from a trusted IP address to a backbone router, you could probably do a lot of harm. I'm not sure that it's possible, but if it is, perhaps that's what the Guardent advisory is about. Phil