Addressing Security Bugs in Your Product

If a bug is found internally, the reporting process is simple. Internal security bugs often are reported through the same process used to report functionality bugs but are flagged as security issues so they receive special attention. Bugs found internally might not require a patch but should go through a process that identifies the root cause, looks for related bugs, determines affected products/versions, and tests whether the fix works and doesnt break existing functionality.

People often wonder why it takes so long for some vendors to release patches. When fixing security bugs as compared to fixing functionality bugs, you have additional points to consider. Although there is room for improvement regarding the turnaround time on reported security issues, assessing, fixing, and testing the issue reported and related issues usually take time if done properly.

Communicating with Bug Finders

It is important have an easy way for a bug finder to report an problem to the vendor. As discussed earlier, common communication methods are dedicated security response e-mail addresses or Web forms. It is wise to have a plan in place for how to respond to reported issues.

If the issue is privately reported by someone outside of your company, its very important to communicate to the bug finder about the work you are doing investigating, fixing, testing, and releasing a fix. Remember that the bug finderwho has other options such as immediate full disclosure of the issue and who hasnt done that yetis doing you a favor by reporting the bug to you. Frequent communication about the work you are doing helps reassure the finder that you are taking seriously the issue reported and that the issue should not be disclosed further until a fix is available. You should act quickly to fix the bug. Many finders have disclosed bugs prior to patch availability because they had a bad relationship with the vendor.

Identifying the Root Cause

Fixing the root cause prevents exploitation through all code paths. If you create a fix to prevent malicious data from reaching the problematic code but you fail to fix the root cause, youre taking a big gamble: you are assuming that there is no path that you havent blocked that allows malicious data to reach the root cause and that no new code that allows this will be added later. But how sure are you, really? You also run the risk discussed in Chapter 17, Observation and Reverse Engineering, of accidentally disclosing the root cause and having attackers find the alternative paths you missed. Remember, if the root cause is in an application programming interface (API), other programs might also call into that API, so fixing how you call it doesnt help the other programs.

Once you identify the root cause of the bug, next identify the reason this bug was missed. Were the original developer and tester unaware of this type of issue? Education could prevent a similarbug from being missed in the future. Did automation miss the case? Could an automated tool be changed or developed to find this type of issue in the future?

Looking for Related Bugs

Although it is important to fix the exact bug reported, it is also important to look for similar bugs in the same product or similar products. For example, if SQL injection is found with one parameter in one product and your organization did not initially protect applications against SQL injection attacks, you should look for all places in all products that create SQL statements based on user input and test them. If the original bug was reported from an external source, it doesnt do your companys image any good to fix the first SQL injection bug only to turn around and need to fix three more. Customers dont enjoy installing patches, so by fixing all the related issues at once you make things easier for them. At the same time, you must consider the amount of time it takes to make the additional fixes and decide whether it is better to ship a comprehensive fix or to fix only the reported issue quickly and later release another fix for related issues.

Determining Affected Products and Versions

A bug is found against a specific version of the product. However, the code that contains the reported bug or related bugs might have shipped in other products and several versions. If these products and versions are currently supported, you must create patches for each.

Testing the Fix

If the bug was reported from an external source, create a patch to fix the issue. Each product and version needs to be tested carefully , not only using penetration testing but to ensure that the patch does not accidentally break functionality. If the product ships separate versions for different languages, these too must be tested.

Testing is one of the biggest time hits in releasing a patch. Testing a single line code change sometimes requires more than a month of testing. Automating testing the products functionality and creating new automated tests for the previously missed security issue significantly reduce the testing time required. This level of testing is often skipped by open source projects that release patches more quickly.

Determining Mitigations and Workarounds

If the bug is found internally in an unreleased product, doesnt affect any released products, you dont need to worry about mitigating the problem. If the problem affects a released product, your customers data is at risk. It is a good idea to spend some time understanding whether there are any steps you can take to help mitigate the issue and work around it. For example, if the problem is in an ActiveX control, users could set the kill bit (discussed in Chapter 18) so the control can no longer be called through a Web page. If the reported issue becomes public before the patch is ready, youll be able to react quickly by supplying well-thought-out steps to mitigate the issue. If for some reason customers cannot install the patch, workarounds and mitigations help even after a patch is released.

Releasing Patches Simultaneously for All Affected Products and Versions

Although it might be acceptable to release functionality fixes separately for different versions, it isnt for security fixes. As noted in Chapter 17, people reverse engineer patches. The Microsoft Security Response Center recently informed us that they release patches at 10 A.M. and sometimes have externally reported exploits by lunchtime for the original vulnerability! If all versions are not released simultaneously, the details of the bug might inadvertently be revealed when no patch is available for some versions.