|
|
Design Principle Violation: Not Failing Securely (aka 'Failing Open') Status: Draft Weakness ID: 636 (Weakness Class)Description Summary When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions. Extended Description By entering a less secure state, the product inherits the weaknesses associated with that state, making it easier to compromise. This weakness typically occurs as a result of wanting to "fail functional" to minimize administration and support costs, instead of "failing safe." Alternate Terms Failing Open Weakness Ordinalities Primary (where the weakness exists independent of other weaknesses) Causal Nature Implicit Common Consequences Integrity intended access restrictions can be bypassed, which is often contradictory to what the product's administrator expects. Potential Mitigations Subdivide and allocate resources and components so that a failure in one part does not affect the entire product. Demonstrative Examples Switches may revert their functionality to that of hubs when the table used to map ARP information to the switch interface overflows, such as when under a spoofing attack. This results in traffic being broadcast to an eavesdropper, instead of being sent only on the relevant switch interface. To mitigate this type of problem, the developer could limit the number of ARP entries that can be recorded for a given switch interface, while other interfaces may keep functioning normally. Configuration options can be provided on the appropriate actions to be taken in case of a detected failure, but safe defaults should be used. Observed Examples
Research Gaps Since design issues are hard to fix, they are rarely publicly reported, so there are few CVE examples of this problem as of January 2008. Most publicly reported issues occur as the result of an implementation error instead of design, such as CVE-2005-3177 (failure to handle large numbers of resources) or CVE-2005-2969 (inadvertently disabling a verification step, leading to selection of a weaker protocol). References Jerome H. Saltzer and
Michael D. Schroeder. "The Protection of Information in Computer Systems". Proceedings of the IEEE 63. September, 1975. <http:/ Sean Barnum and
Michael Gegick. "Failing Securely". 2005-12-05. <https:/ Relationships
Taxonomy Mappings
Applicable Platforms Languages All Time of Introduction  Architecture and Design ImplementationContent History Submissions Pascal Meunier. Purdue University. 2008-01-18. (External Submission) Modifications Eric Dalci. Cigital. 2008-07-01. (External) updated Time_of_Introduction CWE Content Team. MITRE. 2008-09-08. (Internal) updated Common_Consequences, Description, Name, Relationships, Taxonomy_Mappings, Weakness_Ordinalities Previous Entry Names Design Principle Violation: Not Failing Securely (changed 2008-09-09) |
|
|
|||
