Partial Disclosure - The Good

The responsible disclosure process tends to break down in rare occasions where the vendor doesn’t want to fix the issue. When this occurs, the researcher is put into a difficult position whereby full disclosure could put users’ systems at high risk of compromise. The other case where partial disclosure becomes an alternative is when the researcher has discovered a design flaw in a protocol or underlying multiple vendor component. Examples of this case include the DNS flaws published this past summer by Dan Kaminsky and the TCP denial of service condition discovered by Robert E. Lee and Jack Louis that is currently in the disclosure process. When the flaw affects a very large number of vendors and the actual problem is located within the underlying protocols that support the communications of the Internet as a whole, one possible solution is to follow a partial disclosure model where phasing the details to the general public can be used to encourage adoption and creation of patches throughout the enormous target audience.

Partial Disclosure - The Bad

What is driving the fear surrounding partial disclosure is the potential for abuse. When a major flaw is partially disclosed, a number of potential issues may occur. First and foremost, the further along the partial disclosure path we are, the more details will be released to the public, and the higher the probability that someone (either good or bad intentioned) will figure out the exploit and disclose the details. Second, when partially disclosing, the vendor’s hand is being forced into a situation that could speed up fixes, reduce testing, and cause ripple problems elsewhere within the infrastructure. It is difficult enough to dance the fine time line when doing responsible disclosure, but if we are escalated to the point of partial disclosure, additional fuel is added to the fire.

The Ugly

The real ugly part of partial disclosure is when we add to the equation the ability to spread fear, uncertainty, and doubt into the normal user community. It is generally well accepted that FUD can be used to drive additional revenue. If it is possible to increase the perceived magnitude of the “problem” that your product or service solves, it is possible to directly impact the demand for that product or service. That is the major fear imposed by the growing trend of partial disclosure. By releasing just enough information to trigger wide scale speculation into the flaw, it is possible to create buzz and garner media attention resulting in a lot of speculation and very little hard facts around the issue. The potential for abuse by the security industry at large is enormous.

The Fix

Some have suggested a group of security researchers be convened to vet the requirement of partial disclosure and to allow for independent peer review of any security research that requires the partial disclosure process. This suggestion leaves questions regarding who would stand on this group and who would be impartial enough to ensure that the right thing was always done regardless of profit potential. It also leaves open the opportunity for member researchers to utilize the information gathered during the vetting process to position themselves to profit from the data upon release. It might be wiser to rely on a higher level authority or government entity to manage this process and use the services of security researchers as required for subject matter expertise. While a group of this type wouldn’t ensure that all partial disclosure is appropriate, it would hopefully limit the potential for abuse and the ever present chance that people try to profit from the FUD that surrounds the current partial disclosure process.

Synopsis:  Blue Box #84: New Cisco, Avaya, Nortel VoIP security vulnerabilities from VoIPShield, Skype in China, UCSniff and other new tools, news and more

Welcome to Blue Box: The VoIP Security Podcast #84, a 30-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, MB) or subscribe to the RSS feed to download the show automatically. 

You may also listen to this podcast right now:

Show Content:

• 00:20 - Intro to the show, contact information and how to provide comments.  Welcome to all the new listeners - and to all those listeners who have been here for so long!
• Programming notes:
  • Three-year anniversary of Blue Box coming up on October 24th - any thoughts you'd like to share with us? (Please send them to us by October 23rd.)
• VoIPShield announces new vulnerabilities and http://www.voipshield.com/research.php
• http://www.theregister.co.uk/2008/09/30/voip_eavesdropping_tool/
• "Sipera Develops VoIP Spy Program - to Prove a Point" - http://www.voipplanet.com/trends/article.php/3776136
• SecureLogix Announces Free Availability of VoIP Security Tools
• NY Times: Surveillance of Skype Messages Found in China - http://www.nytimes.com/2008/10/02/technology/internet/02skype.html?_r=2&partner=rssnyt&pagewanted=print
• http://securitywatch.eweek.com/privacy/skypechina_breach_is_anyone_really_surprised.html
• http://www.informationweek.com/news/telecom/voip/showArticle.jhtml?articleID=210605439
• Skype CEO's blog post about the issue: http://share.skype.com/sites/en/2008/10/answers_to_some_commonly_asked.html
• http://www.itbusinessedge.com/blogs/top/?p=398
• http://www.voip-news.com/feature/google-phone-europe-growth-092408/
• http://www.itnewsafrica.com/?p=1269
• http://news.cnet.com/8301-1009_3-10052393-83.html
• http://www.broadbandreports.com/shownews/VoIP-Vulnerabilities-Being-Exposed-Today-98039
• http://www.itbusinessedge.com/blogs/top/?p=402
• http://voipsa.org/blog/2008/10/07/5th-emergency-services-workshop-to-be-held-oct-21-23-in-vienna/
• http://eon.businesswire.com/news/eon/20080924005342/en
• http://www.crn.com/security/210602442
• http://it.tmcnet.com/topics/it/articles/41236-infoblox-unveils-dns-firewall-address-dns-vulnerability-concerns.htm
• http://www.newswire.ca/en/releases/archive/September2008/29/c9005.html
• No comments this week.
  
• Review of the last week's traffic on the VOIPSEC public mailing list
  
• Wrap-up of the show
  
• 30:26 - End of show 

NOTE: Long-time listeners will note that the show notes above are in a less descriptive form than usual. After almost three years of using one wiki for preparing for our shows, Jonathan and I switched to using a new system and are still working out some of the details that will speed the input into show notes.

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

• The user is logged on as a local administrator
• The user, or some code the user runs, enables IP routing

By default, all forms of IP routing (including NIC bridging) are disabled. Only local administrators (or group policy) can enable them. So the risk, actually, is minimal.

If you have a stroll through group policy, you'll discover this setting: "Prohibit installation and configuration of Network Bridge on your DNS domain network" (more here, here). This setting allows you turn a computer into a router that bridges two networks. The bridging works only when one of the interfaces is in the same DNS namespace it was in when the bridge setting was enabled, and it works only when the Windows firewall is disabled on both interfaces (never a good idea). Additionally, regardless of the group policy setting, the function doesn’t even appear as an option when the user is logged in as a non-admin. The group policy setting simply removes the option from people who are local admins of their computers. So here's a way you can remove the ability even for local admins to enable routing.

However, let me admit that I wish we did have a way to implement your request, but for an entirely different reason: IP address preservation. Consider what happens when I'm on my own corpnet in my office. I put my laptop in its dock, which is connected to the Ethernet. I never bother disabling my wireless (I'm lazy). So whenever I'm in my office I'm taking up two IP addresses: one on the Ethernet and one on the wireless. Such wasteful profligacy, I know! (Note this isn’t a problem for any Bluetooth adapter, which always uses APIPA in its default configuration; I can’t imagine a scenario where you’d want Bluetooth to use DHCP.)

If you agree with me that this is something we should address post Windows 7, not for "security" reasons but as a good general networking practice of being conservative with address allocation, please speak up. Now's the time for your input.