Not Failing Securely ('Failing Open')
Weakness ID: 636 (Weakness Class)Status: Draft
+ Description

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. At the least, it causes administrators to have a false sense of security. 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
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Integrity

intended access restrictions can be bypassed, which is often contradictory to what the product's administrator expects.

+ Demonstrative Examples

Example 1

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
ReferenceDescription
CVE-2007-5277The failure of connection attempts in a web browser resets DNS pin restrictions. An attacker can then bypass the same origin policy by rebinding a domain name to a different IP address. This was an attempt to "fail functional."
CVE-2006-4407Incorrect prioritization leads to the selection of a weaker cipher. Although it is not known whether this issue occurred in implementation or design, it is feasible that a poorly designed algorithm could be a factor.
+ Potential Mitigations

Subdivide and allocate resources and components so that a failure in one part does not affect the entire product.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory388Error Handling
Development Concepts699
ChildOfWeakness ClassWeakness Class657Violation of Secure Design Principles
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory728OWASP Top Ten 2004 Category A7 - Improper Error Handling
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness ClassWeakness Class755Improper Handling of Exceptional Conditions
Research Concepts1000
PeerOfWeakness BaseWeakness Base280Improper Handling of Insufficient Permissions or Privileges
Research Concepts1000
ParentOfWeakness BaseWeakness Base455Non-exit on Failed Initialization
Research Concepts1000
+ 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).

+ Causal Nature

Implicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
+ References
Jerome H. Saltzer and Michael D. Schroeder. "The Protection of Information in Computer Systems". Proceedings of the IEEE 63. September, 1975. <http://web.mit.edu/Saltzer/www/publications/protection/>.
Sean Barnum and Michael Gegick. "Failing Securely". 2005-12-05. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/349.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-01-18Pascal MeunierPurdue UniversityExternal Submission
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common Consequences, Description, Name, Relationships, Taxonomy Mappings, Weakness Ordinalities
2009-01-12CWE Content TeamMITREInternal
updated Description, Name
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Name
Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Design Principle Violation: Not Failing Securely
2009-01-12Design Principle Violation: Not Failing Securely (aka 'Failing Open')
2009-05-27Not Failing Securely (aka 'Failing Open')
Back to top