Even laptops that don't sport a wireless disabler button usually provide a mechanism in the BIOS for disabling the wireless.

I'm glad you said "Security researcher" versus "Security professional" - what professional would release and publicize an exploit?

>what professional would release and publicize an exploit?

Perhaps one who had reason to believe that he/she was not the only one who might have uncovered the flaw, and who was unhappy with the speed with which the responsible party(ies) were responding with a fix? Perhaps one who thought that the evidence of a working exploit (as opposed to an ambiguous warning) would help get the attention of the user base (as well as the aforementioned responsible parties), and provide the opportunity to suggest stop-gap measures, such as disabling the wireless function on your computer in situations where it is not necessary?

Hypothetical, of course.

There are two common reasons for releasing an exploit.

1. To force the vendor to issue a patch.

You might ask why this is necessary if the exploit is not released. It's necessary because the researcher has no way of knowing that he or she is the only person to have found the vulnerability--someone else may have found it and written exploit code, and may be actively exploiting the vulnerability. This is what "full disclosure" is about--making the vulnerability public knowledge eliminates the possibility that it is already being exploited by a limited population.

Many vendors, unless they know for certain that a vulnerability is being exploited, will drag their feet on producing a patch, preferring to keep their engineers on building new features, despite the fact that some users may be actively harmed. Full disclosure is arguably the most efficient way to refocus an irresponsible vendor's energy on security.

Note that the usual protocol is to inform the vendor about the vulnerability first, wait a few weeks, then inform the world. Thirty days, more or less, is the accepted window. Note that the researcher is vulnerable to accusations during that window. Suppose someone else independently discovers the vulnerability and starts exploiting it after the researcher has informed the vendor, but before public disclosure. The researcher then becomes a target for investigation because he or she is the only person the vendor can point to who had knowledge of the vulnerability.

2. So that people can independently determine whether they are vulnerable. Releasing an exploit allows the community to develop tests to determine whether a given target is vulnerable. In a case like this, where the vulnerable code may express in many different vendors' drivers, it's especially important to have a general tool for locating the ones with a problem.

Brian: While I have been unable to get the exploit to work with my current equipment, I would offer a possible mitigation for people with XP. While the announcement says that a buffer overflow condition is triggered by a very long name attached to a malevlent wireless access point when a vulnerable box scans for local access points, I suspect -- but do not know for certain -- that the impact can be minimized by turning off the "Automatically connect to non-preferred networks" toggle. To get there, click on the START key on the lower left, then click on "connect to..." in the middle of the second column. Choose wireless, make sure the "General" tab is active on the tob left, then click on the "Properties" button on the lower left of the panel. On the bottom right, chose the "Advanced" button above the cancel button at the bottom. When the new panel pops up, uncheck the bottom line, "Automatically connect to non-preferred networks." I might also suggest choosing "Access point (infrastructure connections) only" using the radio buttons above that. Hit close, then okay. Again, not sure if this will provide any protection in this instance, but it's a good practice in any event, and shouldn't cause most people much pain.

I really don't get it. Jon and I were called fakes in August for not releasing code, now he is being called unprofessional for releasing code. You can't have it both ways, make up your mind.

How do you tell if you have a Broadcom Wireless driver? And how can you find out what version it is? Thanks.

David Maynor - In this case Jon is an unprofessional non-fake, but with the other fictitious wireless issue you both were just fakes. I hope that helps clear things up.

BTW - The next time you come up with an issue be sure to provide the company in question information that would allow them to replicate your results. This is how real researchers do it.

Bob J, what Johnny Cache did in this case is exactly what pretty much any other professional would do: notify vendor, wait thirty days, disclose to the public. By asserting he is "unprofessional", you simply demonstrate that you don't understand the protocols of the profession.

David Maynor, don't let the turkeys get you down, especially with Thanksgiving coming up soon.

The link below specifies the generally agreed upon protocol for the disclosure of security issues. I can assure you from first hand knowledge that neither DM or JC know anything about these protocols and have only acted like preadolescences with ADD in any of their communications.

As for your statement "you simply demonstrate that you don't understand the protocols of the profession." really just underscores that you are the anti antibozo.

There is a lot more than just giving 30-days to a vendor and then publishing your findings. A real security professional would know that...

http://www.oisafety.com/guidelines/

Bob J> The link below specifies the generally agreed upon protocol for the disclosure of security issues.

You are obviously mistaken in asserting that the guidelines you cite establish the "generally agreed upon protocol" for disclosure, given that very few researchers actually follow those guidelines.

The general community follows RFPolicy:

http://www.wiretrip.net/rfp/policy.html

This establishes five working days as the minimum waiting period from contact to the researcher doing whatever he or she feels is appropriate. If you have the patience to follow full-disclosure you'll see that thirty days is generally considered a reasonable period for most vendors to prepare a patch. Every day the vulnerability is not fully disclosed is a day on which the researcher may be accused of actively exploiting it. Full disclosure is the professional's self-defense. The most cautious professional will keep that time period as short as possible, while still giving the vendor adequate time to prepare a patch.

Personally, I disclose to US-CERT and leave it to them to negotiate a public disclosure schedule with the vendor, but that is not what the majority do, and if I were interested in getting maximum credit I would do otherwise.

Bob J> I can assure you from first hand knowledge that neither DM or JC know anything about these protocols and have only acted like preadolescences with ADD in any of their communications.

Your assurance is pointless as I don't even know you. If you have further specific information to provide, that might be interesting.

Bob J> There is a lot more than just giving 30-days to a vendor and then publishing your findings.

Naturally, but that doesn't mean following that procedure is "unprofessional". This nonsense of dismissing people's actions as unprofessional is a barely disguised ad hominem attack. If you can demonstrate that JC has done something in this case that would raise eyebrows in the security community, by all means, please do. But name-calling is no substitute for evidence.