Search: Home Bugtraq Vulnerabilities Mailing Lists Jobs Tools Beta Programs
Digg this story   Add to del.icio.us  
How To Hide^H^H^Handle Security Problems in Your Products
Thomas Ptacek, Matasano 2008-06-26

Editor’s note: I wrote this over 10 years ago, after an aggressively bad experience reporting problems in Ascend routers. Everything in here has happened. The original URL for this essay broke long ago, and I felt like giving it a new home.

Anyone in the software industry knows that it’s much harder to build a system than it is to tear them down (ignore what those tree-hugging hippy cryptographers say; these are the same people who want you to give your source code away for free!). So why is it that security bug reports get so much more publicity than your press releases about new product features? Probably because you’re mishandling bug reports! Know what the pros know; don’t let security problems get out of hand. The following 10 tips should help you contain and control security problems.

For examples of how real software companies employ these techniques in their daily business, simply jump over to CNet’s NEWS.COM and search for stories with the words “security” and “flaw” in them. See how simple and effective these real-world strategies are. Remember: your company pays for every letter of publicity it obtains. Don’t let childish hackers get a free ride at your expense.

1. Deny Everything

Never, ever admit that there’s a problem. When you receive a bug report, discredit the report. Did the report come from a competitor? Bias! Slander! Remember: if 99 percent of your customers can’t reproduce the problem, 99 percent of your customers won’t be able to disprove you when you say the problem doesn’t exist. Remember handy key phrases: “that’s not a bug, it’s a feature!” and “the product was NEVER designed to handle that!”.

2. Keep It Secret

Bury the report. Inform the reporters that the problem will take months to fix, or that the fix can’t be released until all your products are sent back through regression testing. Remind them how irresponsible it would be to announce a problem for which there is no fix. Congratulate them for their cleverness and assure them there there is no way any evil crackers will ever find the problem themselves. If all else fails, bribe.

3. Forget The Report

Route the bug report to level-1 technical support. For best effect, ensure that the support technician assigned to the problem speaks minimal English. Delete the report from your bug tracking system. When the reporters give up on you and announce publically, claim you never heard about the problem, and inform the press and your customers that the reporters are simply seeking publicity. Proceed directly to step1.

4. Make Excuses

Blame the operating system. Make sure your customers realize that the problem would never have occurred if Windows 95 popped up a modal dialog asking users if they’d like to wipe their swap file and start a new one every time a program exits. Blame the network. Make sure the press knows that the problem will never, ever occur on “real” networks, where only well-formed web traffic is passed through the packet filters. Blame the reporter. Remember handy key statement: “what was once an obscure problem is now a widely-known problem that hackers can use”.

5. Downplay

Make sure your customers know every limitation of the security problem being reported. If the bug lets attackers read any file, remind your customers that attackers can’t use it to reformat hard drives. If the attack is complicated, make sure your customers know that it would take an evil genius to exploit the problem, and that it isn’t a problem for anyone in the real world. If the press calls, be ready to inform them that nobody is known to actually be exploiting the problem, and thus the problem isn’t important.

6. Wait For Next Release

Frequent updates confuse customers. Loads of bug fixes give customers the impression that your software is less reliable than you know it really is. Don’t give your customers the wrong idea about your quality assurance and testing practices… silently roll fixes into the next release of the software. Added bonus: you can claim “significant security enhancements” in the advertising for the next version!

7. Beta-Test The Fix

Bug fixes are much easier to produce when you take absolutely no responsibility for problems caused by the patch. Easier means faster (not to mention cheaper), and faster is always better when it comes to security. Tell your customers that you’re acting in their best interests by getting them a fix as quickly as possible, and that an official version of the patch will be available soon (see step 6). Save valuable tech support resources by refusing to provide any assistance for any aspect of your software to customers who have moved to an unsupported, experimental configuration by installing your security patch.

8. Patch The Exploit

Capitalize on free quality assurance work by waiting for the exploit to be released instead of finding and reproducing the problem yourself. Add “3” to every fixed constant in your source code. Rebuild software. Try exploit. Repeat until exploit ceases to work. If this fails to solve the problem, convert all strings in your source code to Unicode. Rebuild software. Inform customers that you have resolved the problem.

9. Shoot The Messenger

Anybody who would purposely look for security problems, or tell someone about a security problem they found “accidentally” (yeah, right), is clearly a dope-smuggling pedophile. Accuse reporter of attempting to blackmail your company. From this point on, refer to bug reporters as “hackers”, as in this statement to concerned customers: “hackers like these will always be finding problems in software products, and we will continue to quickly resolve these problems after notifying the proper authorities.” Remember: the messenger is expendable. The value of your stock options is not.

10. Threaten Lawsuit

Sneak clause forbidding reverse engineering of your products into your license. Inform reporter that you believe there could be no way to find security bugs in your software without violating the license. Too late to modify license? Accuse reporter of libel, and claim hundreds of thousands of dollars of damage to your company’s reputation if the reporter lies to the public about nonexistant flaws in your software. Remember: it is highly unlikely that anyone who finds bugs in programs can afford to defend themself in court. Make sure the reporter remembers that too.


Comments


The information, views, and opinions contained on this page are those of the author and do not necessarily reflect the views and opinions of SecurityFocus.






 

Privacy Statement
Copyright 2009, SecurityFocus