Implementation Rarely Matches the Specification or Threat Model

While implementing a feature, a developer often encounters parts of the specification that are unclear and must make a decision on how to write the code. Additionally, many times the original design changes after the specification is written, and often the specification is not updated. Even if the specification matches the code, there will be bugs in that code. Testers are familiar with exactly how the product works, including which places are buggy and don t match the specification. These discrepancies change what should be included in the threat model because they either invalidate some threats or create new ones. Threat models should be updated when the design changes.

As mentioned earlier, all software has bugs. Of the bugs found prior to shipping the software, some are deemed noncrucial and so the team deliberately leaves them unfixed. These bugs are typically small issues that happen only in rare circumstances. However, many security issues occur in the same uncommon code paths in which these bugs are found, and so it is often the case that the unfixed insignificant bugs can be combined with other issues to create an exploitable security issue. To find many of the deeper security bugs, testers start by conducting normal functionality testing and taking advantage of small functionality nuances .

For example, an application s code to save a file might terminate the filename with a null character. A user might be able to specify a filename containing a null character and have parts of the filename ignored. This bug might not be fixed because of the belief that users shouldn t put a null character in filenames, and users doing so is rather uncommon. Because executable files can be dangerous, the example file save routine contains filtering code to verify that only text files (using the .txt extension) are saved. The filtering code does not terminate a filename when it recognizes a null. An attacker might be able to take advantage of this and specify a filename such as test.exe [NULL CHARACTER] .txt. The file passes the .txt extension check, and is then saved as test.exe. This specific example is a canonicalization issue and is discussed in more detail in Chapter 12, Canonicalization Issues.

Important  

Don t think attack tools and system utilities are the only means to learn about a product s implementation. You can use the product in boundary and nonstandard scenarios to learn a great deal about it. How the product reacts in these situations often lets you know more about the implementation of the product. With this increased knowledge, you can construct more advanced attacks.

Threat models are read by people who are building functionality that depends on features contained in the threat model. For this reason, it is important to keep threat models up-to-date. As the design changes to mitigate threats, these changes should be included in the threat model because these changes can introduce additional threats that must be carefully modeled and tested .