CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (2.11)  
ID

CWE-636: Not Failing Securely ('Failing Open')

Weakness ID: 636
Abstraction: Class
Status: Draft
Presentation Filter:
+ 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
Access Control

Technical Impact: Bypass protection mechanism

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
The 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."
Incorrect 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

Phase: Architecture and Design

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
ChildOfCategoryCategory961SFP Secondary Cluster: Incorrect Exception Behavior
Software Fault Pattern (SFP) Clusters (primary)888
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 (Improper handling of 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
2010-12-13CWE Content TeamMITREInternal
updated Research_Gaps
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
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')

More information is available — Please select a different filter.
Page Last Updated: May 05, 2017