Gag Order Fuels Responsible Disclosure Debate

jvatcw writes "The Boston subway hack case has exposed a familiar rift in the security industry over responsible disclosure standards. Many see the temporary restraining order preventing three MIT undergrads from publicly discussing vulnerabilities they discovered in Boston's mass transit system as a violation of their First Amendment rights. Others, though, see the entire episode as yet another example of irresponsible, publicity-hungry security researchers trying to grab a few headlines." We discussed the temporary restraining order last weekend, and later the EFF's plans to fight it. CNet reports that another judge has reviewed the order and left it intact. Reader canuck57 contributes a related story about recent comments by Linus Torvalds concerning his frustration over the issue of security disclosure.

Comments

IMO, this is really a simple issue

[zappepcs]

Linus is dead on right. If you find it, tell the author(s). If they don't respond? Tell the world. Software makers should credit those that find the bugs as well. This will eventually lead to credit where credit is due, and subsequent reputation building in a reasonable manner.

Gag orders just make things worse. This is where I believe the law should take a stand. If someone makes reasonable due diligence to report the vulnerability to the author(s) and nothing happens in response to the report, then the authors have no recourse on what happens when it is made public. This is in line with the intent of our legal framework now, and would not IMO violate legal values.

"Unsafe at any speed" was not exactly something the auto industry wanted to deal with, but they had to. Those lessons are very applicable here. Those who don't play nice and disclose to the public too soon should be penalized if actual damages can be shown. Restraint and respect. These two things have no dependency on reciprocal action.

I read Linus' rant and he's absolutely correct. The bigger the flame war over vulnerabilities, the more security companies make off of unwarranted fears etc. It's just a game, and where the law is concerned, we have prior examples to look at... and goddamnit, they are about cars! No analogy needed here

Re:IMO, this is really a simple issue

[Z00L00K]

And gag orders are today's version of "shoot the messenger".

The problem is there even if you don't tell the world.

Anyway - being a security person is more than revealing or hiding facts. It's also about having the insight to realize that there are always security failures in a system. The point isn't to track down each individual security failure but to create a layered solution that can change a security problem from being critical to moderate.

It's impossible to catch all security problems in a system, and sometimes a security weakness is in place because it isn't possible to make the system more secure without causing it to be impossibly hard to use.

But there are of course stupid security failures too. Autorun in Windows is one... Very effective when you want to spread viruses and other malicious features. And now and then we hear about USB devices that are infected.

They're a bunch of attention whores

[Anonymous Coward]

However...

"...yet another example of irresponsible, publicity-hungry security researchers trying to grab a few headlines" <-- this does not invalidate this --> "First Amendment rights" ...no matter what the neo-cons or lobbyists might say.

The Boston system is really dumb

[Animats]

The MTA is trying to cover up the fact that their system design is very weak. The value of the card is actually stored on the card, and there's no central validation. That's embarrassing, considering that the MTA implemented fare cards quite late, long after other cities.

The NYC MetroCard system, in comparison, is totally paranoid. Cards have unique serial numbers and are validated by the entry gate, the station computer, and central servers at MetroCard HQ. Creating new cards with new IDs won't work. Duplicating cards is possible, but is detected the second time the card is used. NYC is so paranoid that equipment maintenance is performed by an outside company, but NYC employees handle the money and blank cards, so that no single party has full access. The New York City subway system was losing about $20 million a year to token fraud, and when the new system went in, they were determined that would stop. They had some fraud back in 1995, when someone stole a supply of blank cards and was able to encode them, but it turned out to be a rip-off for buyers - the cards only worked once, then were invalidated.

The first fare card system, San Francisco's BART, isn't that secure, but has an big advantage - BART has exit gates. So, while it doesn't have real-time validation against a central database, gate info is being transmitted in background to a central system, and if centralized analysis indicates something funny going on, central control can flag the card, trap the user at the exit gate, and alert station security to check the card.

Comments

[RAMMS EIN]

My thoughts:

First amendmend rights are a red herring. The fact that you have a right to say something doesn't make it a good idea to say it.

Publicity-hungry researchers trying to grab a few headlines also aren't the issue here.

The issue here is security. And that raises the question of who we are trying to protect. As far as I am concerned, we _should_ be trying to maximize overall security. I think the best way to do that is to protect the users of products. So, the question then becomes: What kind of disclosure yields the best security for users?

Unfortunately, the answer to that question depends on a variety of factors. I think the three most important ones are:

1. How will the vendor react to being informed of the vulnerability?
2. How will the users react to being informed of the vulnerability?
3. How will the black hats (bad guys) react to being informed of the vulnerability?

None of these questions can be answered generally. In particular, in general, you cannot know how the black hats will react, because you cannot know if the black hats were already aware of the vulnerability. If they weren't, you have just given them a new attack vector. This is a Bad Thing, and one of the most common arguments against full disclosure. On the other hand, if they were already aware of the vulnerability, you have just told them nothing they didn't already know. Since you can't know, in general, if the black hats already know of a vulnerability, it seems that full disclosure is a bad idea, overally. But that's if you only consider point 3.

Once you factor in points 1 and 2, the picture changes. The fact that you found a vulnerability is always interesting news to the vendor and the users. If they didn't know about it already, the vendor now knows that they have a problem that affects their users and that they need to fix, and the users know they have a problem that the vendor hasn't fixed yet, and that they should protect themselves against. If the vendor or the users did know about the vulnerability, they now know that _another_ person has found it, and that, perhaps, more priority should be given to fixing it and protecting against it. In case of full disclosure, everybody now knows for sure that the black hats know about the vulnerability, that they _will_ use it to attack systems, and that it _must_ be protected against and fixed as soon as possible.

Now, I am going to say a couple of things that aren't really factual, but that seem reasonable to me.

First of all, protecting yourself from vulnerabilities and getting them fixed is _always_ the right way to deal with vulnerabilities. Doing so as soon as possible minimizes the time you are vulnerable, and thus is a Good Thing. Not everyone realizes the importance of this. But, once a vulnerability has been announced publicly, you _know_ that the black hats know about it, so it is clearly risky to not protect yourself against it.

Secondly, in general, you will never make all users aware of a vulnerability. It may seem that a vendor could inform the users of their product of a vulnerability. However, vendors are notoriously reluctant to provide their users with information about vulnerabilities. If they provide information at all, it is usually not detailed enough to allow users to take protective measures, or comes long after the black hats have already started exploiting the vulnerability. Moreover, even the vendor will not know everyone who uses a product. And nobody can exclude the possibility that some of these users may be black hats, or that the information may leak to the black hats. Public disclosure at least gives every user of the product the possibility to inform themselves of a vulnerability.

Thirdly, historically, vendors have been reluctant to fix vulnerabilities unless they were publicly known. This is a Bad Thing, because the fact that a vulnerability is not publicly known does not mean it is not being exploited. Now, of course, vendors could change. And some of them have changed. But, hi