My Disclosure Rant

Thomas Ptacek | October 20th, 2005 | Filed Under: Uncategorized

A caveat: these comments are not a reaction to any current vendor I’m dealing with right now (caveat necessary due to previous two weeks worth of stalling comments)

Five Cheap Tips For Vendors Handling Security Disclosures

1. Have A Security Liason

   Far and away the most important advice I can give:

   • Have someone on staff who owns vulnerability disclosure

   • Publish their contact information

   • Escalate disclosed vulnerabilites to them immediately

   Your security contact does not need to be a developer. But it does need to be someone who at least appears to be outside the normal support escalation chain. Simply allocating this role is a very cheap way to make your company seem responsive to disclosures.

   We know your top-tier support staff is excellent, that you’ve invested lots of time and resources into equipping them to solve customer problems, and that you’ve built up years of experience on how to handle critical customer problems. But shunting security disclosures through standard support guarantees not just delay, but the strong perception of delay, and thus a major incentive to write an exploit to expedite the process.

   A good vendor security contact knows what to say and, more importantly, what not to say to a reporter —- things like, “SSL means nobody can attack the service”, or “You can prevent this server vulnerability by deleting the client binary”. A good vendor security contact creates the perception that you are taking the disclosure seriously, and that my time is better spent finding other vulnerabilities than it is in demonstrating how severe this one is.

2. Have A Dedicated Security Enhancement/Bug-Fix Process

   Your internal ticket to fix blind, pre-authentication remote code execution vulnerabilities probably looks just like other tickets, like the ones to fix spelling errors in your help files. And that’s fine. But there is no reason customers should be exposed to that piece of information.

   Don’t call security fixes “enhancements”. Your customers do not perceive “closing major vulnerabilities” as “enhancements” any more than Ford customers perceive the recalls on exploding Firestone tires to be “special bonus upgrades”.

   This is so simple to fix that it’s amazing everyone doesn’t do it. Create special bug numbers for security vulnerabilities. Don’t even call them “bugs”. Call them “urgent security issues” or “incidents”. For god’s sake, don’t call them “feature requests”. You don’t have to do anything more than changing a label to create the perception that you are on the case.

3. Confirm Vulnerabilities Rapidly

   The longer it takes you to acknowledge a potential vulnerability exists, the more worth my while it is to write an exploit. Basic risk/reward:

   	Admit Now	Admit Later
   I’m Right	Appear Responsive	Downplay Exploit
   I’m Wrong	Appear Responsive, Incur Sympathy	Feel Better

   I don’t know what kind of a premium you put on “feeling better”, but I hope it outweighs the cost of discussing the cost of the vulnerability in the context of how many measured seconds it took to compromise every installation of the product across the whole network.

4. Provide Documentation Liberally

   It’s 2005. At this stage in the game, when investigating a problem in a network service, I have access to:

   • The traffic you generated
   • Its SSL decryption
   • Reassembled TCP streams
   • Reaction to doctored messages
   • A trace of its execution
   • Its complete disassembly
   • Often with symbols
   • And in graphical form
   • Or, god help you if you wrote it in Java

   Pretty much the only secrets you’re keeping are the precise number and type of swear words in the source code comments. However, at some point around the time I got to “bothering to attach to your program in GDB”, I figured out exactly how easy it would be to prove my point with an exploit.

5. Do Not Downplay

   Further examples of things not to say to a customer reporting a security vulnerability:

   • “Don’t you have some kind of IDS in place that would detect people trying to exploit this vulnerability?”

   • “Our product is designed to be deployed BEHIND a firewall.”

   • “Because our product is not built on Windows, it is not vulnerable to buffer overflows.”

   • “Our new 9.3 version of the software is not vulnerable to this problem. We’ve been meaning to talk to you about why you should renew your maintenance contract.”

   To be perfectly frank, you are expected to have security vulnerabilities. People who look for vulnerabilities wind up in a bad mood when they don’t find them. So if you want to make yourselves feel better at the expense of vulnerability researchers, beat the hell out of your software internally before researchers get their hands on it.