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...

[RealityMogul]

Are you talking from a customers standpoint, or a vendor?

At the place I work, if we find a severe bug, we personally call every company that has that version of the software and have them download an update. My company doesn't produce networking software though and we only have 50-75 companies running any given version of our product at one time. This is usually bugs that affect mathematical calculations though or cause database corruptions.

From the point of view of a customer: if I found a serious flaw in our Cisco routers, I would report it to them and ask for a way to protect myself against it until an official patch could be released. If a means of protection could not be recommended I would work on a solution myself. I would not make the information public. I would have already informed the ones that are capable of truly fixing the problem. Publicly releasing the info would not benefit me in any way unless I was a security products vendor hoping to cash in on Cisco's failure.

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

[SteveM]

Publicly releasing the info would not benefit me in any way unless I was a security products vendor hoping to cash in on Cisco's failure.

I mostly agree.

If the vendor refuses, within a reasonable time frame, to fix the problem taking it public may be the only way to force them to do so.

You might also consider that while you may have a means of protection (vendor supplied or home grown) others are still vunerable. And this may impact you. And thus it may be to your benefit to alert others.

SteveM

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.

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

[E-Rock]

Yea, the same users who don't install well known years old patches are going to search out and early adopt a patch from 'some guy'. Puhleeze.

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

[theLOUDroom]

Yea, the same users who don't install well known years old patches are going to search out and early adopt a patch from 'some guy'. Puhleeze.

Those are the users who are going to ge hosed no matter what. It doesn't matter if you choose A or B they're still going to get owned.
Since you can't do anything about them, you should be worried about they people who are actually going to do something once they hear the announcement.

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

[Anonymous Coward]

There's a fundamental difference between your scenario and the traditional vulnerability discovery: the existance of an attack in the wild. In your case, you are not so much writing up the discovery a vulnerability as you are writing up a report on an attack that just in your scenario exploits a previously unknown vulnerability.

Why is this important? Most people have this dualistic view of the world that tends to come down to the concept of inevitability. See, in your scenario, the attack is already out there, that is, it is inevitable there will be an attack because an attack already exists. Releasing an immediate writeup of workarounds is considered a good thing because you will be protecting people from an attack in the wild. Of course, informing the vendor and the antivirus/personal firewall crowds at the same time would be a good thing. Not only will this increase the likelyhood of your workarounds being implemented while the vendor works on the patch (by being recommended on "reputable" sites), but it could provide increased protection against the attack if the AV vendors could incorporate signatures into their products.

Now compare this to a vulnerability report about a new vulnerability without any attacks in the wild. In this case, most people don't see the attacks as inevitable. In fact, thanks to certain minor propoganda that occurs these days, they see the report as precipitating the attack. Thus if you release the report without reasonable effort to contact the vendor for a patch, they see you as the "evil" one for "telling" the malware writers a new way into their system. In their minds, if you hadn't of released the report then the inevitability would be that there would be no attack (let's not get into how this isn't technically correct, we're talking about Joe Public here, not security experts). That's why most vulnerability discovers should work with the vendor on patches or mitigations before releasing the report. Otherwise people will really start to make the false assumption that it's the vulnerability discovery that's the problem, instead of the vendor's flaws.

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.

Re:I'm of 2 minds on this

[iabervon]

You're not vulnerable, because this only affects TCP connections with easily guessed source ports and known hosts that last for a significant amount of time and where things can't be restarted efficiently. This matters primarily for BGP which you don't use unless you're running a backbone (which is why they contacted the backbone providers first). The main other possibility is that if you have an SSH connection going for a long time, another user on either of the machines (who can get netstat info) who has root on some other machine which can reach one of them can break your connection. So, if you are constantly monitoring logs on a machine by sending them offsite, someone could break your connection before using a local root exploit that would appear in those logs, thus preventing you from knowing what happened.

still on topic, troll

[bodrell]

You're naive if you think a TCP vulnerability and Windows security problems have nothing to do with each other. There are people who use Windows boxes as routers or servers. And I think the point was that admins are already swamped fixing the existing Windows exploits, thereby making this new flaw an even bigger deal.

Trolls like to play the martyr--"You're trying to cover up what I'm saying because it's true; reply to my posts instead of modding me down." Well here's your reply, bitch. When Micro$oft's crappy software allows vulnerable machines to act as spam relays, or spread worms around the internet, everyone suffers. No matter what OS they use.

Re:Security through Obscurity proves itself again

[Anonymous Coward]

When was this "totally open" approach widely used? Sometime after 1992 I guess, right? Must have missed it.

I think the whole reason the "totally open" approach exists, and will always exist, is to deal with unresponsive vendors. If a software vendor (who shall remain nameless) sits on a major security bug for six months, there is a problem with the "security through obscurity" model, and it's this--there is no profit motive to fix security bugs nobody knows about. If customers think they're safe, that's exactly the same as having them actually be safe, but a lot less work (from a profit-motive point of view). Happy uninformed customers are just as good as happy informed customers.

"Security through obscurity" is, and always has been, step 1. Found a bug? Tell the vendor. "Totally open" is step 2. Vendor has shown no action to fix the bug in a week or two? Make the information public.

You can't have a system of just one or the other. We absolutely must have a "totally open" option to hold over software vendors.

(Interesting side-note: "totally open" isn't necessary for open-source software. The discoverer of the bug can patch the software and release the fix themselves. It's only where we rely on the vendor for fixes where this is necessary)

Re:Net threat overstated, says Paul Watson

[AndroidCat]

The assumption seems to be that someone would use this to take down sites or other disruption. Haven't there been cases of IP block hijacking using lax BGP security in the past? (Wasn't that how one company rerouted root DNS for a while several years back?)

There have been cases of "fossil" IP blocks being hijacked in the last few years by spammers. (Sometimes as simple as registering an expired domain that an ancient contact email address points to.) They seem to be paying for malware to be written. Don't think that spammers and other net-vermin won't take a look at this exploit for their uses.

Re:"super" exploits

[the morgawr]

It can't be targeted unless the vendor has both an unsecure BGP protocal and a crappy TCP implementaion.

This isn't a TCP problem, it's just being billed that way because a bunch of vendors have crappy implementations of the above protocals. Yes, in theory this could affect everyone, but the difficulty of doing this type of attack on a system with a good TCP implementation is next to nothing.

Basically, the attack takes advantage of certain predictable behaviors that arn't in the spec but that most of the TCP implementations have to reduce the possible space of packets to something that is reasonably tryable.