Secret Repairs Preceded TCP Flaw Release

efranco cuts and pastes: "Only the math had changed. But the emergence of a workable exploit for an old TCP security hole prompted a secret initiative to fix the Internet, giving network operators a week to secure vulnerable routers. The clandestine repair effort livened an already intense period for security pros already juggling a bevy of Windows security patches." We ran a story on a this a few days ago.

Comments

Looks like this is the way it's gonna be...

[pointbeing]

These days it's risky to release information about a security vulnerability without having a patch in place first. Look at Blaster - I believe that the author *used a security bulletin* to write the worm and then just targeted unpatched machines.

I think we're gonna see a lot more of this. If you release information before you fix it these days you're just inviting people to test your shiny new vulnerability ;-)

Re:Looks like this is the way it's gonna be...

[WwWonka]

I think the scary thing is the average shrinking time period between published vulnerability and working published exploit/worm.

In the past it was well over thirty days, but recently that has dramatically decreased to less than that. With Microsoft's new policy of new patches every thirty days (if there is a need for them) it more than widens that window of oppurtunity for mass system compromising prior to a patch.

Re:Looks like this is the way it's gonna be...

[adrianbaugh]

You could always release it to the company whose product is affected and give them $suitable_time to fix the vulnerability before you post on Bugtraq. That way it isn't just you that's working on a fix, and you look like you've tried to be a responsible netizen when, having failed to fix the problem in $reasonable_time, their shit gets cracked to pieces. That has always been the responsible way of announcing vulnerabilities; I don't see that this changes the situation.

Re:Looks like this is the way it's gonna be...

[Anonymous Coward]

Yes, "script kiddies" and amateur hackers will definitely continue exploiting already-widely-known vulnerabilities, and automated worm tools will make it easier for them to do it quickly.

However, moderately talented hackers will still be able to find and exploit vulnerabilities before they are widely known (i.e. when they are known only to a handful of hackers and possibly the software vendor, but no public disclosure has been made). This latter group makes fewer headlines but is far more dangerous.

Already, the industry is making noises that details about the nature of the exploit should not be made available--that the vendor should just release a patch and announce to their customers "Install this. We can't tell you why." As a customer, you don't know what component you're touching, you don't know what's changing, and you don't know how to test to see if the bug was actually fixed. Blindly installing unlabelled patches is the end result of this "disclosure creates exploits" discussion.

Disclosure does not create exploits, however. Disclosure increases the ability of amateurs to add their exploits to the pile of existing exploits. Pros, generally speaking, don't write worms that hit the whole internet. Pros break into single systems and steal data. They don't make the news, but the damage they do is much worse.

Don't buy the Microsoft-Symantec party line. Full disclosure helps more people than it hurts. The day you become vulnerable is the day you start using software with bugs, not they day the vendor is finally convinced to make a vulnerability announcement.

Re:Looks like this is the way it's gonna be...

[dubdays]

That is an interesting question. I guess it would depend on where the vulnerability resides. For example, if the TCP problem could be fixed at routers of the internet backbone, then would it be beneficial for the public to have specific knowledge of the vulnerability? No, because it would lead to attacks before all equipment/software could be fixed.

However, I can see how it would definitely be beneficial to release data to he public in other circumstances. Think about any/all OS specific threats. If those aren't released to the public, no one would even have the opportunity to fix them.

Ultimately, I would say that vulnerabilities that lie within the realm of the end user should be made public. Those threats that would undermine the entire internet infrastructure are probably best left in the hands of those who can be trusted (as much as possible) with the knowledge, because publicly documented threats do not only go into the hands of those who are benevolent.

Re:Looks like this is the way it's gonna be...

[innocent_white_lamb]

You could always release it to the company whose product is affected and give them $suitable_time to fix the vulnerability before you post on Bugtraq.

The obvious problem with that approach is that the fact that there is no guarantee that you, as the discoverer of the vulnerability, are the first or even the fiftieth person to discover it.

Therefore, while you're being a nice guy and letting Company X have the time to repair their software, the other 49 (or 4900) black hats are exploiting the hell out of other peoples' networks.

Tell me there is a bug and no fix available yet, I can take my systems offline or disable something or at least consider some protective action of some kind. Don't tell me there's a bug and I'm a sitting duck until someone bothers to make mention.

The first option seems better to me.

Re:Looks like this is the way it's gonna be...

[theLOUDroom]

You could always release it to the company whose product is affected and give them $suitable_time to fix the vulnerability before you post on Bugtraq. That way it isn't just you that's working on a fix, and you look like you've tried to be a responsible netizen when, having failed to fix the problem in $reasonable_time, their shit gets cracked to pieces. That has always been the responsible way of announcing vulnerabilities; I don't see that this changes the situation.

Well, let me give you a hypothetical situation where this is NOT the reasonable solution:
You discover an OS vulnerability, not by chance, but because someone exploited it to steal your online banking information. With a little reseach, you find out that the work is being done by some zombie net with thousands of nodes that will take forever to shut down.
The OS vendor has a piss-poor security record and you KNOW that they will take forever to release a patch, but you've found a temporary fix that while removing certain functionality, prevents the exploit.
Should you:
A) A post full-disclosure immediately, allowing users to quick-fix their systems and preventing countless acts of information theft.
B) Send an email to the vendor and wait when they tell you it's going to take 6 weeks to fix.

The problem with your approach is that it assumes no one but the vendor can do anything about the problem. The user always has the choice to quit using the affected product.

I'm of 2 minds on this

[platypibri]

Yes, I would prefer to know immediately if I was vulnerable. However, the vast majority of defense is against script kiddies who wait to have exploits handed to them so they can copy and paste some malicious code together to prove what "hackers" they are. Why should we tell them before there's a patch? I dunno. Hopefully someone smarter than me is working on it.