Graph This view (graph) attempts to classify weaknesses based on their inherent characteristics, in a way that is as independent of particular languages, technologies, and frameworks as possible. Ideally, it will only cover weakness-to-weakness relationships, with minimal overlap. Its development is borrowing from - and contributing to - vulnerability theory, which will help CWE become more consistent. Once stable, this hierarchy should be useful in mapping to CWE and identifying theoretical gaps. Implicit_Slice This view (slice) covers all the elements in CWE. true() Explicit_Slice CWE nodes in this view (slice) have been deprecated. There should be a reference pointing to the replacement in each deprecated weakness. Explicit_Slice CWE nodes in this view (slice) are associated with the OWASP Top Ten. Explicit_Slice CWE nodes in this view (slice) are being focused on by SAMATE. http://samate.nist.gov/index.php/Source_Code_Security_Analysis Graph CWE nodes in this view (graph) occur when the application handles particular system resources. Explicit_Slice CWE nodes in this view (slice) are used by NIST to categorize vulnerabilities within NVD. Implicit_Slice This view (slice) covers issues that are found in C that are not common to all languages. .//Applicable_Platforms/Platform='C' Implicit_Slice This view (slice) covers issues that are found in C++ that are not common to all languages. .//Applicable_Platforms/Platform='C++' Implicit_Slice This view (slice) covers issues that are found in Java that are not common to all languages. .//Applicable_Platforms/Platform='Java' Implicit_Slice This view (slice) covers issues that are found in PHP that are not common to all languages. .//Applicable_Platforms/Platform='PHP' Implicit_Slice This view (slice) displays only weakness base elements. .//@Weakness_Abstraction='Base' Implicit_Slice This view (slice) displays only composite weaknesses. .//@Compound_Element_Structure='Composite' Implicit_Slice This view (slice) displays only weakness elements that are part of a chain. (.//Relationship_Nature='CanPrecede') or (@*[contains(name(),'ID')] = //Relationship_Target_ID[../Relationship_Nature='CanPrecede']) Weaknesses in this category are organized based on which phase they are introduced during the software development and deployment process. 1000 View ChildOf 1000 ASP.NET framework/language related environment issues with security implications. 1000 Category ChildOf 519 Weaknesses in this category are related to the creation and modification of strings. 1000 Weakness ChildOf 119 Weaknesses in this category are caused by improper data type transformation or improper handling of multiple data types. 1000 Category ChildOf 19 Weaknesses in this category are introduced when inserting or converting data from one representation into another. 1000 Category ChildOf 19 Every language has its own special elements such as characters and reserved words. The following weaknesses (under this category) are expressed in general terms. Technology-specific problems that involve special elements, such as cross-site scripting and SQL injection, are covered in another CWE node. non-specific, parsing Developers should anticipate that special elements (e.g. delimiters, symbols) will be injected into input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Some of these types of special chars have been observed at one point or another, but it's difficult to find suitable examples after the fact. In an attempt to be complete about what kinds of "special characters" exist, some types may have been added to this list without any publicly reported vulnerability for those types. 1000 Weakness ChildOf 138 General Special Element Problems All Weaknesses in this category are typically introduced during the configuration of the software. 1000 Category ChildOf 1 635 View ChildOf 635 Weaknesses in this category are related to improper handling of special elements within particular technologies. Developers should anticipate that technology-specific special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. Note that special elements problems can arise from designs or languages that (1) do not separate "code" from "data" or (2) mix meta-information with information. 1000 Weakness ChildOf 138 Technology-Specific Special Elements All Weaknesses in this category are typically introduced during code development, including specification, design, and implementation. 1000 Category ChildOf 1 Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform sanity checks for untrusted data. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). M. Howard D. LeBlanc Writing Secure Code 2nd Edition Microsoft 2003 1000 Category ChildOf 137 1000 Weakness CanPrecede 289 Cleansing, Canonicalization, and Comparison Errors All 80 79 71 53 72 64 3 78 52 43 Weaknesses in this category are typically found within source code. 1000 Category ChildOf 17 Source Code Weaknesses in this category are related to improper calculation or conversion of numbers. 1000 Category ChildOf 19 635 View ChildOf 635 Numeric Errors All Weaknesses in this category are typically found in functionality that processes data. 1000 Category ChildOf 18 100 99 Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types. Medium Availability: Integer coercion often leads to undefined states of execution resulting in infinite loops or crashes. Access Control: In some cases, integer coercion errors can lead to exploitable buffer overflow conditions, resulting in the execution of arbitrary code. Integrity: Integer coercion errors result in an incorrect value being stored for the variable in question. Requirements specification: A language which throws exceptions on ambiguous data casts might be chosen. Design: Design objects and program flow such that multiple or complex casts are unnecessary Implementation: Ensure that any data type casting that you must used is entirely understood in order to reduce the plausibility of error in use. See the Examples section of the problem type Unsigned to signed conversion error for an example of integer coercion errors. Several flaws fall under the category of integer coercion errors. For the most part, these errors in and of themselves result only in availability and data integrity issues. However, in some circumstances, they may result in other, more complicated security related flaws, such as buffer overflow conditions. 1000 Category ChildOf 189 1000 Weakness CanAlsoBe 195 1000 Weakness CanAlsoBe 196 1000 Weakness CanAlsoBe 197 1000 Weakness CanAlsoBe 194 Integer coercion error C C++ Java .NET Implementation Weaknesses in this category are related to improper handling of sensitive information. 1000 Category ChildOf 19 All Weaknesses in this category are typically introduced during unexpected environmental conditions. 1000 Category ChildOf 1 Functions that manipulate strings encourage buffer overflows. Memory Windows provides the _mbs family of functions to perform various operations on multibyte strings. When these functions are passed a malformed multibyte string, such as a string containing a valid leading byte followed by a single null byte, they can read or write past the end of the string buffer causing a buffer overflow. The following functions all pose a risk of buffer overflow: _mbsinc _mbsdec _mbsncat _mbsncpy _mbsnextc _mbsnset _mbsrev _mbsset _mbsstr _mbstok _mbccpy _mbslen 1000 Category ChildOf 133 630 View ChildOf 630 631 Category ChildOf 633 Often Misused: Strings C C++ Software security is not security software. Here we're concerned with topics like authentication, access control, confidentiality, cryptography, and privilege management. 1000 Category ChildOf 18 Security Features Weaknesses in this category are related to the management of credentials. 1000 Category ChildOf 254 635 View ChildOf 635 All Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control. Follow the principle of least privilege when assigning access rights to entities in a software system. 1000 Category ChildOf 254 635 View ChildOf 635 Permissions, Privileges, and ACLs All 35 17 76 58 5 69 A variety of vulnerabilities occur with improper handling, assignment, or management of privileges. These are especially present in sandbox environments, although it could be argued that any privilege problem occurs within the context of some sort of sandbox. Note: can heavily overlap authorization errors Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Follow the principle of least privilege when assigning access rights to entities in a software system. Many of the following concepts require deeper study. Most privilege problems are not classified at such a low level of detail, and terminology is very sparse. Certain classes of software, such as web browsers and software bug trackers, provide a rich set of examples for further research; operating systems have matured to the point that these kinds of weaknesses are rare. 1000 Category ChildOf 264 Privilege / sandbox errors Weaknesses in this category are related to improper assignment or handling of permissions. File processing, non-specific. File/Directory 1000 Category ChildOf 264 631 Category ChildOf 632 Permission errors 35 17 A certificate is a token that associates an identity (principle) to a cryptographic key. Certificates can be used to check if a public key belongs to the assumed owner. Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key. M. Bishop Computer Security: Art and Science Addison-Wesley 2003 1000 Weakness ChildOf 287 All Weaknesses in this category are typically introduced during unexpected environmental conditions in particular technologies. 1000 Category ChildOf 2 Weaknesses in this category are related to the use of cryptography. Cryptography This category is incomplete and needs refinement, as there is good documentation of cryptographic flaws and related attacks. Note: some of these can be resultant. 1000 Category ChildOf 254 635 View ChildOf 635 Cryptographic Issues All Weaknesses in this category are related to errors in the management of cryptographic keys. CVE-2005-2146 insecure permissions when generating secret key, allowing spoofing CVE-2001-1527 administration passwords in cleartext in executable CVE-2000-0762 default installation of product uses a default encryption key, allowing others to spoof the administrator CVE-2002-1947 static key / global shared key -- "global shared key" - product uses same SSL key for all installations, allowing attackers to eavesdrop or hijack session. CVE-2005-4002 static key / global shared key -- "global shared key" - product uses same secret key for all installations, allowing attackers to decrypt data. CVE-2005-2196 static key / global shared key -- Product uses default WEP key when not connected to a known or trusted network, which can cause it to automatically connect to a malicious network. Overlaps: default. CVE-2005-1794 Exposed or accessible private key (overlaps information leak) -- Private key stored in executable CVE-2001-0072 Exposed or accessible private key (overlaps information leak) -- Crypto program imports both public and private keys but does not tell the user about the private keys, possibly breaking the web of trust. CVE-2005-3256 Misc -- Encryption product accidentally selects the wrong key if the key doesn't have additional fields that are normally expected, leading to infoleak to the owner of that wrong key This category should probably be split into multiple sub-categories. 1000 Category ChildOf 310 Key Management Errors All Weaknesses in this category are related to or introduced in the User Interface (UI). User interface errors that are relevant to security have not been studied at a high level. 1000 Category ChildOf 254 (UI) User Interface Errors All Distributed computation is about time and state. That is, in order for more than one component to communicate, state must be shared, and all that takes time. Most programmers anthropomorphize their work. They think about one thread of control carrying out the entire program in the same way they would if they had to do the job themselves. Modern computers, however, switch between tasks very quickly, and in multi-core, multi-CPU, or distributed systems, two events may take place at exactly the same time. Defects rush to fill the gap between the programmer's model of how a program executes and what happens in reality. These defects are related to unexpected interactions between threads, processes, time, and information. These interactions happen through shared state: semaphores, variables, the file system, and, basically, anything that can store information. 1000 Category ChildOf 18 Time and State 61 Weaknesses in this category are related to improper management of system state. 1000 Category ChildOf 361 74 Weaknesses in this category are related to improper handling of temporary files. File/Directory 1000 Category ChildOf 361 631 Category ChildOf 632 Weaknesses in this category are related to improper handling of time or state within particular technologies. 1000 Category ChildOf 361 Weaknesses in this category are related to improper handling of time or state within J2EE. 1000 Category ChildOf 380 Error handling problems occur when an application does not properly handle errors that occur during processing. An attacker may discover this type of error, as forcing these errors can occur with a variety of corrupt input. Generally, the consequences of improper error handling are the disclosure of the internal workings of the application to the attacker, providing details to use in further attacks. Web applications that do not properly handle error conditions frequently generate error messages such as stack traces, detailed diagnostics, and other inner details of the application. Use a standard exception handling mechanism to be sure that your application properly handles all types of processing errors. All error messages sent to the user should contain as little detail as necessary to explain what happened. If the error was caused by unexpected and likely malicious input, it may be appropriate to send the user no error message other than a simple "could not process the request" response. The details of the error and its cause should be recorded in a detailed diagnostic log for later analysis. Do not allow the application to throw errors up to the application container, generally the web application server. Be sure that the container is properly configured to handle errors if you choose to let any errors propagate up to it. 1000 Category ChildOf 18 Error Handling 28 If a function in a product does not generate the correct return/status codes, or if the product does not handle all possible return/status codes that could be generated by a function, then security issues may result. This type of problem is most often found in conditions that are rarely encountered during the normal operation of the product. Presumably, most bugs related to common conditions are found and eliminated during development and testing. In some cases, the attacker can directly control or influence the environment to trigger the rare conditions. This category is often primary to a variety of other weaknesses. Many researchers focus on the resultant weaknesses and do not necessarily diagnose whether a rare condition is the primary factor. However, since 2005 it seems to be reported more frequently than in the past. This subject needs more study. 1000 Category ChildOf 388 Error Conditions, Return Values, Status Codes All Weaknesses in this category are related to improper management of system resources. Resource management errors can lead to consumption, exhaustion, etc. Often a resultant vulnerability 1000 Weakness ChildOf 398 635 View ChildOf 635 Resource Management Errors All J2EE framework related environment issues with security implications. 1000 Category ChildOf 3 Weaknesses in this category are related to improper handling of locks that are used to control access to resources. 1000 Category ChildOf 399 Resource Locking problems Weaknesses in this category are related to improper handling of communication channels and access paths. A number of vulnerabilities are specifically related to problems in creating, managing, or removing alternate channels and alternate paths. Some of these can overlap virtual file problems (CHAP.VIRTFILE), and they can are commonly used in "bypass" attacks, such as those that exploit authentication errors. Most of these issues are probably under-studied. Only a handful of public reports exist. 1000 Weakness ChildOf 398 Channel and Path Errors All Weaknesses in this category are related to improper handling of communication channels. 1000 Category ChildOf 417 Channel Errors All Weaknesses in this category are related to improper management of handlers. May be resultant This concept is under-defined and needs more research. 1000 Weakness ChildOf 398 Handler Errors Weaknesses in this category are related to unexpected behaviors from code that an application uses. 1000 Weakness ChildOf 435 Behavioral problems Weaknesses in this category involve interaction errors that are specific to WWW technology. 1000 Weakness ChildOf 435 Web problems Weaknesses in this category occur within the user interface. User interface errors that are relevant to security have not been studied at a high level. 1000 Weakness ChildOf 398 (UI) User Interface Errors All Weaknesses in this category occur in behaviors that are used for initialization and breakdown. Most of these initialization errors are significant factors in other weaknesses. Researchers tend to ignore these, concentrating instead on the resultant weaknesses, so their frequency is uncertain, at least based on published vulnerabilities. 1000 Weakness ChildOf 398 Initialization and Cleanup Errors All Weaknesses in this category are related to improper handling of specific data structures. 1000 Weakness ChildOf 398 Weaknesses in this category are related to improper handling of pointers. 1000 Weakness ChildOf 398 Weaknesses in this category are frequently found in mobile code. 1000 Weakness ChildOf 485 Weaknesses in this category are typically found within byte code or object code. 1000 Category ChildOf 17 Object Code This category intends to capture the motivations and intentions of developers that lead to weaknesses that are found within CWE. 1000 View ChildOf 1000 Genesis Weaknesses in this category were intentionally introduced by the developer, typically as a result of prioritizing other aspects of the program over security, such as maintenance. Characterizing intention is tricky: some features intentionally placed in programs can at the same time inadvertently introduce security flaws. For example, a feature that facilitates remote debugging or system maintenance may at the same time provide a trapdoor to a system. Where such cases can be distinguished, they are categorized as intentional but nonmalicious. Not wishing to endow programs with intentions, we nevertheless use the terms "malicious flaw," "malicious code," and so on, as shorthand for flaws, code, etc., that have been introduced into a system by an individual with malicious intent. Although some malicious flaws could be disguised as inadvertent flaws, this distinction can be easy to make in practice. Inadvertently created Trojan horse programs are hardly likely, although an intentionally-introduced buffer overflow might plausibly seem to be an error. 1000 Category ChildOf 504 Intentional Nonmalicious introduction of weaknesses into software can still render it vulnerable to various attacks. 1000 Category ChildOf 505 Nonmalicious Other kinds of intentional but nonmalicious security flaws are possible. Functional requirements that are written without regard to security requirements can lead to such flaws; one of the flaws exploited by the "Internet worm" [3] (case U10) could be placed in this category. 1000 Category ChildOf 513 Other Inadvertent flaws may occur in requirements; they may also find their way into software during specification and coding. Although many of these are detected and removed through testing, some flaws can remain undetected and later cause problems during operation and maintenance of the software system. For a software system composed of many modules and involving many programmers, flaws are often difficult to find and correct because module interfaces are inadequately documented and global variables are used. The lack of documentation is especially troublesome during maintenance when attempts to fix existing flaws often generate new flaws because maintainers lack understanding of the system as a whole. Although inadvertent flaws do not usually pose an immediate threat to the security of the system, the weakness resulting from a flaw may be exploited by an intruder (see case D1). 1000 Category ChildOf 504 Inadvertent Requirements Architecture and Design Implementation This category lists weaknesses related to environmental problems in .NET framework applications. 1000 Category ChildOf 3 Weaknesses in this category are related to concurrent use of shared resources. 1000 Category ChildOf 361 1000 Weakness CanAlsoBe 362 1000 Category PeerOf 371 Weaknesses in this category are related to improper use of arguments or parameters within function calls. This category is closely related to CWE-628, Incorrectly Specified Arguments, and might be the same. However, CWE-628 is a base weakness, not a category. 1000 Weakness ChildOf 227 Weaknesses in this category are related to incorrectly written expressions within code. 1000 Weakness ChildOf 398 Weaknesses in this category are related to improper handling of links within Unix-based operating systems. 1000 Weakness ChildOf 59 UNIX Path Link problems All Weaknesses in this category are related to improper handling of links within Windows-based operating systems. 1000 Weakness ChildOf 59 All Weaknesses in this category affect file or directory resources. 631 View ChildOf 631 Weaknesses in this category affect memory resources. 631 View ChildOf 631 Weaknesses in this category affect system process resources during process invocation or inter-process communication (IPC). 631 View ChildOf 631 Weaknesses in this category are related to improper handling of virtual files within Windows-based operating systems. 1000 Weakness ChildOf 66 Windows Virtual File problems All Weaknesses in this category are related to improper handling of virtual files within Mac-based operating systems. File/Directory 1000 Weakness ChildOf 66 631 Category ChildOf 632 Mac Virtual File problems All Weaknesses in this category are caused by inadequately implemented input validation within particular technologies. 1000 Weakness ChildOf 20 Weaknesses in this category are caused by inadequately implemented protection schemes that use the STRUTS framework. 1000 Weakness ChildOf 100 Java The application uses multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect. This could introduce other weaknesses and indicates that validation logic is not up-to-date. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Two validation forms with the same name.

...

...

]]> It is critically important that validation logic be maintained and kept in sync with the rest of the application. If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations. Moreover, it indicates that the validation logic is not being maintained, and can indicate that other, more subtle validation errors are present. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities can all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Duplicate Validation Forms Java The application has a validator form that either fails to define a validate() method, or defines a validate() method but fails to call super.validate(). This could introduce other weaknesses related to missing input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) The Struts Validator uses a form's validate() method to check the contents of the form properties against the constraints specified in the associated validation form. That means the following classes have a validate() method that is part of the validation framework: ValidatorForm, ValidatorActionForm, DynaValidatorForm, and DynaValidatorActionForm. If you create a class that extends one of these classes, and if your class implements custom validation logic by overriding the validate() method, you must call super.validate() in your validate() implementation. If you do not, the Validation Framework cannot check the contents of the form against a validation form. In other words, the validation framework will be disabled for the given form. Disabling the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Erroneous validate() Method Java If a form bean does not extend an ActionForm subclass of the Validator framework, it can expose the application to other weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) In order to use the Struts Validator, a form must extend one of the following: ValidatorForm, ValidatorActionForm, DynaValidatorActionForm, and DynaValidatorForm. You must extend one of these classes because the Struts Validator ties in to your application by implementing the validate() method in these classes. Forms derived from the ActionForm and DynaActionForm classes cannot use the Struts Validator. Bypassing the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is an important component of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Form Bean Does Not Extend Validation Class Java The application has a form field that is not validated by a corresponding validation form, which can introduce other weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Ensure that you validate all form fields. If a field is unused, it is still important to constrain them so that they are empty or undefined. Omitting validation for even a single input field may give attackers the leeway they need to compromise your application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities can stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. Some applications use the same ActionForm for more than one purpose. In situations like this, some fields may go unused under some action mappings. It is critical that unused fields be validated too. Preferably, unused fields should be constrained so that they can only be empty or undefined. If unused fields are not validated, shared business logic in an action may allow attackers to bypass the validation checks that are performed for other uses of the form. 1000 Weakness ChildOf 101 Struts: Form Field Without Validator Java When an application does not use an input validation framework such as the Struts Validator, there is a greater risk of introducing weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Unchecked input is the leading cause of vulnerabilities in J2EE applications. Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. To prevent such attacks, use the Struts Validator to check all program input before it is processed by the application. Ensure that there are no holes in your configuration of the Struts Validator. Example uses of the validator include checking to ensure that: * Phone number fields contain only valid characters in phone numbers * Boolean values are only "T" or "F" * Free-form strings are of a reasonable length and composition 1000 Weakness ChildOf 101 Struts: Plug-in Framework Not In Use Java An unused validation form indicates that validation logic is not up-to-date. Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an unused validation form. 1000 Weakness ChildOf 101 Struts: Unused Validation Form Java Every Action Form must have a corresponding validation form. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) If a Struts Action Form Mapping specifies a form, it must have a validation form defined under the Struts Validator. If an action form mapping does not have a validation form defined, it may be vulnerable to a number of attacks that rely on unchecked input. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. An action or a form may perform validation in other ways, but the Struts Validator provides an excellent way to verify that all input receives at least a basic level of checking. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated. 1000 Weakness ChildOf 101 Struts: Unvalidated Action Form Java Automatic filtering via a Struts bean has been turned off, which disables the Struts Validator and custom validation logic. This exposes the application to other weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Ensure that an action form mapping enables validation. An action form mapping that disables validation. ]]> Disabling validation exposes this action to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. The Action Form mapping in the demonstrative example disables the form's validate() method. The Struts bean: write tag automatically filters special HTML characters, replacing a < with &lt and a > with &gt. This action can be disabled by specifying filter="false" as an attribute of the tag to disable specified JSP pages. However, being disabled makes these pages susceptible to cross-site scripting attacks. An attacker may be able to insert malicious scripts as user input to write to these JSP pages. 1000 Weakness ChildOf 101 Struts: Validator Turned Off Java Debugging messages help attackers learn about the system and plan a form of attack. Avoid releasing debug binaries into the production environment. ASP .NET applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. The debug attribute of the <compilation> tag defines whether compiled binaries should include debugging information. The use of debug binaries causes an application to provide as much information about itself as possible to the user. Debug binaries are meant to be used in a development or testing environment and can pose a security risk if they are deployed to production. Attackers can leverage the additional information they gain from debugging output to mount attacks targeted on the framework, database, or other resources used by the application. 1000 Category ChildOf 10 ASP.NET Misconfiguration: Creating Debug Binary .NET Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Example 1.a: An action form with two fields. Example 1.a shows an action form that has two fields, startDate and endDate. Example 1.b: A validation form with a third field. ]]> Example 1.b lists a validation form for the action form. The validation form lists a third field: scale. The presence of the third field suggests that DateRangeForm was modified without taking validation into account. It is easy for developers to forget to update validation logic when they make changes to an ActionForm class. One indication that validation logic is not being properly maintained is inconsistencies between the action form and the validation form. It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Validator Without Form Field Java When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) The following code defines a class named Echo. The class declares one native method (defined below), which uses C to echo commands entered on the console back to the user. class Echo { public native void runEcho(); static { System.loadLibrary("echo"); } public static void main(String[] args) { new Echo().runEcho(); } } The following C code defines the native method implemented in the Echo class: Java #include "Echo.h"//the java class above compiled with javah #include JNIEXPORT void JNICALL Java_Echo_runEcho(JNIEnv *env, jobject obj) { char buf[64]; gets(buf); printf(buf); }]]> Because the example is implemented in Java, it may appear that it is immune to memory issues like buffer overflow vulnerabilities. Although Java does do a good job of making memory operations safe, this protection does not extend to vulnerabilities occurring in source code written in other languages that are accessed using the Java Native Interface. Despite the memory protections offered in Java, the C code in this example is vulnerable to a buffer overflow because it makes use of gets(), which does not perform any bounds checking on its input. The Sun Java(TM) Tutorial provides the following description of JNI [See Reference]: The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them. The vulnerability in the example above could easily be detected through a source code audit of the native method implementation. This may not be practical or possible depending on the availability of the C source code and the way the project is built, but in many cases it may suffice. However, the ability to share objects between Java and native methods expands the potential risk to much more insidious cases where improper data handling in Java may lead to unexpected vulnerabilities in native code or unsafe operations in native code corrupt data structures in Java. Vulnerabilities in native code accessed through a Java application are typically exploited in the same manner as they are in applications written in the native language. The only challenge to such an attack is for the attacker to identify that the Java application uses native code to perform certain operations. This can be accomplished in a variety of ways, including identifying specific behaviors that are often implemented with native code or by exploiting a system information leak in the Java application that exposes its use of JNI [See Reference]. Native code is unprotected by the security features enforced by the runtime environment, such as strong typing and array bounds checking. Many safety features that programmers may take for granted simply do not apply for native code, so you must carefully review all such code for potential problems. Other programming languages that may be more susceptible to buffer overflows and other attacks, such as C or C++, usually implement native code. Language-based encapsulation is broken. Fortify Software Fortify Descriptions http://vulncat.fortifysoftware.com B. Stearns The Java™ Tutorial: The Java Native Interface Sun Microsystems 2005 http://java.sun.com/docs/books/tutorial/native1.1/ 1000 Weakness ChildOf 100 Unsafe JNI Java Failure to enable validation when parsing XML gives an attacker the opportunity to supply malicious input. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Always validate XML input against a known XML Schema or DTD. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Most successful attacks begin with a violation of the programmer's assumptions. By accepting an XML document without validating it against a DTD or XML schema, the programmer leaves a door open for attackers to provide unexpected, unreasonable, or malicious input. It is not possible for an XML parser to validate all aspects of a document's content; a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed. 1000 Weakness ChildOf 20 Missing XML Validation All 99 The software fails to adequately filter HTTP headers for CR and LF characters. Including unvalidated data in an HTTP header allows an attacker to specify the entirety of the HTTP response rendered by the browser. When an HTTP request contains unexpected CR and LF characters the server may respond with an output stream that is interpreted as two different HTTP responses (instead of one). An attacker can control the second response and mount attacks such as cross-site scripting and cache poisoning attacks. Construct HTTP headers very carefully, avoiding the use of non-validated input data. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Input (specifically, unexpected CRLFs) that is not appropriate should not be processed into HTTP headers. The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response. Assuming a string consisting of standard alpha-numeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form: HTTP/1.1 200 OK ... Set-Cookie: author=Jane Smith ... However, because the value of the cookie is formed of unvalidated user input the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form: HTTP/1.1 200 OK ... Set-Cookie: author=Wiley Hacker HTTP/1.1 200 OK ... Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: cross-user defacement, web and browser cache poisoning, cross-site scripting and page hijacking. Others examples: Cross-User Defacement: An attacker can make a single request to a vulnerable server that will cause the sever to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the sever. This can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server. In the best case, an attacker can leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application. In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker. Cache Poisoning: The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although the user of the local browser instance will be affected. Cross-Site Scripting: Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users. Cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site. The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account. Page Hijacking: In addition to using a vulnerable application to send malicious content to a user, the same root vulnerability can also be leveraged to redirect sensitive content generated by the server and intended for the user to the attacker instead. By submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker can cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server for the user to the attacker. Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim. CVE-2005-1951 Application accepts CRLF in an object ID, allowing HTTP response splitting. CVE-2004-2146 Application accepts CRLF in an object ID, allowing HTTP response splitting. CVE-2004-1620 HTTP response splitting via CRLF in parameter related to URL. CVE-2004-1656 HTTP response splitting via CRLF in parameter related to URL. CVE-2004-1687 HTTP response splitting via CRLF in parameter related to URL. CVE-2005-2060 Bulletin board allows response splitting via CRLF in parameter. CVE-2005-2065 Bulletin board allows response splitting via CRLF in parameter. CVE-2004-2512 Response splitting via CRLF in PHPSESSID. CVE-2005-1951 Chain: Application accepts CRLF in an object ID, allowing HTTP response splitting. CVE-2004-1687 Chain: HTTP response splitting via CRLF in parameter related to URL. HTTP response splitting vulnerabilities occur when: 1. Data enters a web application through an untrusted source, most frequently an HTTP request. 2. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. As with many software security vulnerabilities, HTTP response splitting is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. To mount a successful exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allows them to create additional responses entirely under their control. Note that HTTP response splitting is probably only multi-factor in an environment that uses intermediaries. 1000 Weakness ChildOf 93 1000 Weakness CanPrecede 79 1000 Category PeerOf 442 HTTP response splitting HTTP Response Splitting All 63 31 85 34 Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker. System Process Libraries that are loaded should be well understood and come from a trusted source. The application can execute code contained in the native libraries, which often contain calls that are susceptible to other security problems, such as buffer overflows or command injection. All native libraries should be validated to determine if the application requires the use of the library. It is very difficult to determine what these native libraries actually do, and the potential for malicious code is high. In addition, the potential for an inadvertent mistake in these native libraries is also high, as many are written in C or C++ and may be susceptible to buffer overflow or race condition problems. To help prevent buffer overflow attacks, validate all input to native calls for content and length. If the native library does not come from a trusted source, review the source code of the library. The library should be built from the reviewed source before using it. The following code uses System.loadLibrary() to load code from a native library named library.dll, which is normally found in a standard system directory. The problem here is that System.loadLibrary() accepts a library name, not a path, for the library to be loaded. From the Java 1.4.2 API documentation this function behaves as follows [1]: A file containing native code is loaded from the local file system from a place where library files are conventionally obtained. The details of this process are implementation-dependent. The mapping from a library name to a specific filename is done in a system-specific manner. If an attacker is able to place a malicious copy of library.dll higher in the search order than file the application intends to load, then the application will load the malicious copy instead of the intended file. Because of the nature of the application, it runs with elevated privileges, which means the contents of the attacker's library.dll will now be run with elevated privileges, possibly giving them complete control of the system. The following code from a privileged application uses a registry entry to determine the directory in which it is installed and loads a library file based on a relative path from the specified directory. C The code in this example allows an attacker to load an arbitrary library, from which code will be executed with the elevated privilege of the application, by modifying a registry key to specify a different path containing a malicious version of INITLIB. Because the program does not validate the value read from the environment, if an attacker can control the value of APPHOME, they can fool the application into running malicious code. The following code is from a web-based administration utility that allows users access to an interface through which they can update their profile on the system. The utility makes use of a library named =;liberty.dll, which is normally found in a standard system directory. The problem is that the program does not specify an absolute path for liberty.dll. If an attacker is able to place a malicious library named liberty.dll higher in the search order than file the application intends to load, then the application will load the malicious copy instead of the intended file. Because of the nature of the application, it runs with elevated privileges, which means the contents of the attacker's liberty.dll will now be run with elevated privileges, possibly giving the attacker complete control of the system. The type of attack seen in this example is made possible because of the search order used by LoadLibrary() when an absolute path is not specified. If the current directory is searched before system directories, as was the case up until the most recent versions of Windows, then this type of attack becomes trivial if the attacker can execute the program locally. The search order is operating system version dependent, and is controlled on newer operating systems by the value of the registry key: HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode Process control vulnerabilities take two forms: - An attacker can change the command that the program executes: the attacker explicitly controls what the command is. - An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means. We will first consider the first scenario, the possibility that an attacker may be able to control the command that is executed. Process control vulnerabilities of this type occur when: - Data enters the application from an untrusted source. - The data is used as or as part of a string representing a command that is executed by the application. - By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have. 1000 Weakness ChildOf 20 631 Category ChildOf 634 Process Control All The software misinterprets an input, whether from an attacker or another product, in a security-relevant fashion. CVE-2005-2225 Product sees dangerous file extension in free text of a group discussion, disconnects all users. CVE-2001-0003 Product does not correctly import and process security settings from another product. This concept needs further study. It is likely a factor in several weaknesses, possibly resultant as well. Overlaps Multiple Interpretation Errors (MIE). 1000 Weakness ChildOf 20 1000 Weakness CanAlsoBe 436 Misinterpretation Error All The software does not sufficiently sanitize output before it is sent to a different control sphere. 1000 Category ChildOf 19 All 81 63 18 73 85 86 Writing unsanitized user input into log files can allow an attacker to forge log entries or inject malicious content into logs. Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate data is written to log files. The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened. If a user submits the string "twenty-one" for val, the following entry is logged: INFO: Failed to parse val=twenty-one However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged: INFO: Failed to parse val=twenty-one INFO: User logged out=badguy Clearly, attackers can use this same mechanism to insert arbitrary log entries. CVE-2006-4624 Chain: inject fake log entries with fake timestamps using CRLF injection Log forging vulnerabilities occur when: 1. Data enters an application from an untrusted source. 2. The data is written to an application or system log file. Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information. Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [22]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [17]. G. Hoglund G. McGraw Exploiting Software: How to Break Code Addison-Wesley February 2004 A. Muffet The night the log was forged http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm 1000 Weakness ChildOf 116 Log Forging All 81 93 Weaknesses in this category occur when expected boundaries can be exceeded. 1000 Category ChildOf 19 All 10 14 24 8 9 45 46 47 The software may potentially allow operations, such as reading or writing, to be performed at addresses not intended by the developer. When software permits read or write operations on memory located outside of an allocated range, an attacker may be able to access/modify sensitive information, cause the system to crash, alter the intended control flow, or execute arbitrary code. Memory 1000 Weakness ChildOf 118 635 View ChildOf 635 631 Category ChildOf 633 100 10 14 42 24 8 44 9 45 46 47 An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses. Handle exceptions appropriately in source code. Do not attempt to process an error or attempt to mask it. Verify return values are correct and do not supply sensitive information about the system. ASP .NET applications should be configured to use custom error pages instead of the framework default page. The default error page gives detailed information about the error that occurred, and should not be used in production environments. The mode attribute of the <customErrors> tag defines whether custom or default error pages are used. Attackers can leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application. M. Howard D. LeBlanc J. Viega 19 Deadly Sins of Software Security McGraw-Hill/Osborne 2005 1000 Category ChildOf 10 1000 Weakness ChildOf 209 ASP.NET Misconfiguration: Missing Custom Error Handling .NET A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function). Stack Overflow Very high Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Availability: Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop. Access control (memory and instruction processing): Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service. Pre-design: Use a language or compiler that performs automatic bounds checking. Design: Use an abstraction library to abstract away risky APIs. Not a complete solution. Pre-design through Build: Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution. Operational: Use OS-level preventative functionality. Not a complete solution. While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, stack-based buffer overflows: C There are generally several security-critical data on an execution stack that can lead to arbitrary code execution. The most prominent is the stored return address, the memory address at which execution should continue once the current function is finished executing. The attacker can overwrite this value with some memory address to which the attacker also has write access, into which he places arbitrary code to be run with the full privileges of the vulnerable program. Alternately, the attacker can supply the address of an important call, for instance the POSIX system() call, leaving arguments to the call on the stack. This is often called a return into libc exploit, since the attacker generally forces the program to jump at return time into an interesting routine in the C standard library (libc). Other important data commonly on the stack include the stack pointer and frame pointer, two values that indicate offsets for computing memory addresses. Modifying those values can often be leveraged into a "write-what-where" condition. Stack-based buffer overflows can instantiate in return address overwrites, stack pointer overwrites or frame pointer overwrites. They can also be considered function pointer overwrites, array indexer overwrites or write-what-where condition, etc. Terminology Note: "Stack Overflow" is often used to mean the same thing as stack-based buffer overflow, however it is also used on occasion to mean stack exhaustion, usually a result from an excessively recursive function call. Due to the ambiguity of the term, use of stack overflow to describe either circumstance is discouraged. 1000 Compound_Element ChildOf 120 630 View ChildOf 630 Stack overflow C C++ Implementation A buffer overflow where the buffer from the Buffer Write Operation is statically allocated A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). High to Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Memory Availability: Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop. Access control (memory and instruction processing): Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service. Pre-design: Use a language or compiler that performs automatic bounds checking. Design: Use an abstraction library to abstract away risky APIs. Not a complete solution. Pre-design through Build: Canary style bounds checking, library changes which ensure the validity of chunk data, and other such fixes are possible, but should not be relied upon. Operational: Use OS-level preventative functionality. Not a complete solution. C CVE-2007-4268 Chain: integer signedness passes signed comparison, leads to heap overflow Heap-based buffer overflows are usually just as dangerous as stack-based buffer overflows. Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker's code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime. 1000 Compound_Element ChildOf 120 630 View ChildOf 630 631 Category ChildOf 633 Heap overflow C C++ Implementation 92 A buffer overflow where the buffer from the Buffer Write Operation is dynamically allocated Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow. High Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Access control (memory and instruction processing): Clearly, write-what-where conditions can be used to write data to areas of memory outside the scope of a policy. Also, they almost invariably can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Availability: Many memory accesses can lead to program termination, such as when writing to addresses that are invalid for the current process. Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service. Pre-design: Use a language that provides appropriate memory abstractions. Design: Integrate technologies that try to prevent the consequences of this problem. Implementation: Take note of mitigations provided for other flaws in this taxonomy that lead to write-what-where conditions. Operational: Use OS-level preventative functionality integrated after the fact. Not a complete solution. When the attacker has the ability to write arbitrary data to an arbitrary location in memory, the consequences are often arbitrary code execution. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), he can redirect a function pointer to his own malicious code. Even when the attacker can only modify a single byte using a write-what-where problem, arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator. 1000 Weakness ChildOf 119 1000 Weakness PeerOf 134 Write-what-where condition C C++ The software allows a condition where buffers are written to using buffer access mechanisms such as indexes or pointers that reference memory locations prior to the targeted buffer. This typically occurs when indexes are negative numbers or when pointer arithmetic results in a position before the beginning of the valid memory location. This can occur when a negative number is used as an offset, or if the pointer or its index is decremented to a position before the buffer. Some prominent vendors and researchers use the term "buffer underrun". "Buffer underflow" is more commonly used, although both terms are also sometimes used to describe a buffer under-read (CWE-127). Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Availability: Buffer underwrites will very likely result in the corruption of relevant memory, and perhaps instructions, leading to a crash. Access Control (memory and instruction processing): If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code. If the corrupted memory is data rather than instructions, the system will continue to function with improper changes, possibly in violation of an implicit or explicit policy. The consequences would only be limited by how the affected data is used, such as an adjacent memory location that is used to specify whether the user has special privileges. Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Implementation: Sanity checks should be performed on all calculated values used as index or for pointer arithmetic. The following is an example of code that may result in a buffer underwrite, if find() returns a negative value to indicate that ch is not found in srcBuf: C If the index to srcBuf is somehow under user control, this is an arbitrary write-what-where condition. CVE-2002-2227 Unchecked length of SSLv2 challenge value leads to buffer underflow. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-2227 CVE-2007-4580 Buffer underflow from a small size value with a large buffer (length parameter inconsistency, CWE-130) http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4580 CVE-2007-1584 Buffer underflow from an all-whitespace string, which causes a counter to be decremented before the buffer while looking for a non-whitespace character. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1584 CVE-2007-0886 Buffer underflow resultant from encoded data that triggers an integer overflow. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0886 CVE-2006-6171 Product sets an incorrect buffer size limit, leading to "off-by-two" buffer underflow. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6171 CVE-2006-4024 Negative value is used in a memcpy() operation, leading to buffer underflow. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4024 CVE-2004-2620 Buffer underflow due to mishandled special characters http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2620 This could be resultant from several errors, including a bad offset or an array index that decrements before the beginning of the buffer (see CWE-129). Much attention has been paid to buffer overflows, but "underflows" sometimes exist in products that are relatively free of overflows, so it is likely that this variant has been under-studied. Buffer UNDERFLOWS: What do you know about it? Vuln-Dev Mailing List 2004-01-10 http://seclists.org/vuln-dev/2004/Jan/0022.html 1000 Weakness ChildOf 119 1000 Compound_Element PeerOf 120 1000 Weakness PeerOf 129 UNDER - Boundary beginning violation ('buffer underflow' ?) Buffer underwrite C C++ Implementation The software reads data past the end, or before the beginning, of the intended buffer. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) CVE-2004-0112 out-of-bounds read due to improper length check CVE-2004-0183 packet with large number of specified elements cause out-of-bounds read. CVE-2004-0221 packet with large number of specified elements cause out-of-bounds read. CVE-2004-0184 out-of-bounds read, resultant from integer underflow CVE-2004-1940 large length value causes out-of-bounds read CVE-2004-0421 malformed image causes out-of-bounds read Under-studied and under-reported. Most issues are probably labeled as buffer overflows. 1000 Weakness ChildOf 119 Out-of-bounds Read C C++ Implementation The software reads data past the end of the intended buffer. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) 1000 Weakness ChildOf 125 Buffer over-read C C++ Implementation The software reads data before the start of the intended buffer. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Under-studied. 1000 Weakness ChildOf 125 Buffer under-read C C++ Implementation Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value. Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Availability: Wrap-around errors generally lead to undefined behavior, infinite loops, and therefore crashes. Integrity: If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the wrap around results in other conditions such as buffer overflows, further memory corruption may occur. Access control (instruction processing): A wrap around can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Design: Provide clear upper and lower bounds on the scale of any protocols designed. Implementation: Place sanity checks on all incremented variables to ensure that they remain within reasonable bounds. Due to how addition is performed by computers, if a primitive is incremented past the maximum value possible for its storage space, the system will fail to recognize this, and therefore increment each bit as if it still had extra space. Because of how negative numbers are represented in binary, primitives interpreted as signed may "wrap" to very large negative values. 1000 Weakness ChildOf 119 1000 Weakness PeerOf 190 Wrap-around error All Implementation 92 Unchecked array indexing occurs when an unchecked value is used as an index into a buffer. "out-of-bounds array index" or "index-out-of-range" or "array index underflow" Medium Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Memory Availability: Unchecked array indexing will very likely result in the corruption of relevant memory and perhaps instructions, leading to a crash, if the values are outside of the valid memory area Integrity: If the memory corrupted is data, rather than instructions, the system will continue to function with improper values. Access Control: If the memory corrupted memory can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Implementation: Include sanity checks to ensure the validity of any values used as index variables. In loops, use greater-than-or-equal-to, or less-than-or-equal-to, as opposed to simply greater-than, or less-than compare statements. CVE-2005-0369 large ID in packet used as array index CVE-2001-1009 negative array index as argument to POP LIST command CVE-2003-0721 Integer signedness error leads to negative array index CVE-2004-1189 product does not properly track a count and a maximum number, which can lead to resultant array index overflow. A single fault could allow both an overflow and underflow of the array index. An index overflow exploit might use buffer overflow techniques, but this can often be exploited without having to provide "large inputs." Array index overflows can also trigger out-of-bounds read operations, or operations on the wrong objects; i.e., "buffer overflows" are not always the result. Unchecked array indexing, depending on its instantiation, can be responsible for any number of related issues. Most prominent of these possible flaws is the buffer overflow condition. Due to this fact, consequences range from denial of service, and data corruption, to full blown arbitrary code execution. The most common condition situation leading to unchecked array indexing is the use of loop index variables as buffer indexes. If the end condition for the loop is subject to a flaw, the index can grow or shrink unbounded, therefore causing a buffer overflow or underflow. Another common situation leading to this condition is the use of a function's return value, or the resulting value of a calculation directly as an index in to a buffer. 1000 Weakness ChildOf 119 631 Category ChildOf 633 Unchecked array indexing INDEX - Array index overflow C C++ Implementation Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers. Good password management guidelines require that a password never be stored in plaintext. 1000 Category ChildOf 10 1000 Weakness ChildOf 260 ASP.NET Misconfiguration: Password in Configuration File The software operates on user-controlled input (including length parameters) without validating that the length parameters match the actual length of the input data. If an attacker can manipulate the length parameter associated with an input such that it is inconsistent with the actual length of the input, this can be leveraged to cause the target application to behave in unexpected, and possibly, malicious ways. One of the possible motives for doing so is to pass in arbitrarily large input to the application. Another possible motivation is the modification of application state by including invalid data for subsequent properties of the application. Such weaknesses commonly lead to attacks such as buffer overflows and execution of arbitrary code. length manipulation, length tampering Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) CVE-2001-0825 CVE-2001-1186 CVE-2001-0191 CVE-2003-0429 CVE-2000-0655 CVE-2004-0492 CVE-2004-0201 CVE-2003-0825 can overlap zero-length issues CVE-2004-0095 CVE-2004-0826 CVE-2004-0808 CVE-2002-1357 CVE-2004-0774 CVE-2004-0940 CVE-2004-0989 CVE-2004-0568 CVE-2003-0327 CVE-2003-0345 CVE-2004-0430 CVE-2005-0064 CVE-2004-0413 leads to memory consumption, integer overflow, and heap overflow CVE-2004-0940 is effectively an accidental double increment of a counter that prevents a length check conditional from exiting a loop. CVE-2002-1235 length field of a request not verified CVE-2005-3184 buffer overflow by modifying a length value SECUNIA:18747 length field inconsistency crashes cell phone Probably overlaps other categories including zero-length issues 1000 Weakness ChildOf 118 Length Parameter Inconsistency All Implementation 47 The software does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow. CVE-2004-1363 substitution overflow: buffer overflow using environment variables that are expanded after the length check is performed CVE-2004-0747 substitution overflow: buffer overflow using expansion of environment variables CVE-2005-2103 substitution overflow: buffer overflow using a large number of substitution strings CVE-2005-3120 transformation overflow: product adds extra escape characters to incoming data, but does not account for them in the buffer length CVE-2003-0899 transformation overflow: buffer overflow when expanding ">" to "&gt;", etc. CVE-2001-0334 expansion overflow: buffer overflow using wildcards CVE-2001-0248 expansion overflow: long pathname + glob = overflow CVE-2001-0249 expansion overflow: long pathname + glob = overflow CVE-2002-0184 special characters in argument are not properly expanded CVE-2004-0434 small length value leads to heap overflow CVE-2002-1347 multiple variants CVE-2005-0490 needs closer investigation, but probably expansion-based CVE-2004-0940 needs closer investigation, but probably expansion-based This is a broad category. Some examples include: (1) simple math errors, (2) incorrectly updating parallel counters, (3) not accounting for size differences when "transforming" one input to another format (e.g. URL canonicalization or other transformation that can generate a result that's larger than the original input, i.e. "expansion"). This level of detail is rarely available in public reports, so it is difficult to find good examples. 1000 Weakness ChildOf 119 Other length calculation error C C++ 47 Miscalculated null termination occurs when the placement of a null character at the end of a buffer of characters (or string) is misplaced or omitted. Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Confidentiality: Information disclosure may occur if strings with misplaced or omitted null characters are printed. Availability: A randomly placed null character may put the system into an undefined state, and therefore make it prone to crashing. Integrity: A misplaced null character may corrupt other data in memory Access Control: Should the null character corrupt the process flow, or effect a flag controlling access, it may lead to logical errors which allow for the execution of arbitrary code. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Implementation: Ensure that all string functions used are understood fully as to how they append null characters. Also, be wary of off-by-one errors when appending nulls to the end of strings. While the following example is not exploitable, it provides a good example of how nulls can be omitted or misplaced, even when "safe" functions are used: C #include int main() { char longString[] = "String signifying nothing"; char shortString[16]; strncpy(shortString, longString, 16); printf("The last character in shortString is: %c %1$x\n", shortString[15]); return (0); }]]> The above code gives the following output: The last character in shortString is: l 6c So, the shortString array does not end in a NULL character, even though the "safe" string function strncpy() was used. Miscalculated null termination is a common issue, and often difficult to detect. The most common symptoms occur infrequently (in the case of problems resulting from "safe" string functions), or in odd ways characterized by data corruption (when caused by off-by-one errors). The case of an omitted null character is the most dangerous of the possible issues. This will almost certainly result in information disclosure, and possibly a buffer overflow condition, which may be exploited to execute arbitrary code. As for misplaced null characters, the biggest issue is a subset of buffer overflow, and write-what-where conditions, where data corruption occurs from the writing of a null character over valid data, or even instructions. These logic issues may result in any number of security flaws. 1000 Weakness ChildOf 119 1000 Weakness ChildOf 682 1000 Compound_Element PeerOf 120 1000 Weakness PeerOf 123 Miscalculated null termination C C++ The software uses externally-controlled format strings in printf-style functions, which can lead to buffer overflows or data representation problems. logging, errors, general output Very High Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) Memory Confidentiality: Format string problems allow for information disclosure which can severely simplify exploitation of the program. Access Control: Format string problems can result in the execution of arbitrary code. Requirements specification: Choose a language which is not subject to this flaw. Implementation: Ensure that all format string functions are passed a static string which cannot be controlled by the user and that the proper number of arguments are always sent to that function as well. If at all possible, do not use the %n operator in format strings. Build: Heed the warnings of compilers and linkers, since they may alert you to improper usage. The following example is exploitable, due to the printf() call in the printWrapper() function. Note: The stack buffer was added to make exploitation more simple. C void printWrapper(char *string) { printf(string); } int main(int argc, char **argv) { char buf[5012]; memcpy(buf, argv[1], 5012); printWrapper(argv[1]); return (0); }]]> The following code copies a command line argument into a buffer using snprintf(). This code allows an attacker to view the contents of the stack and write to the stack using a command line argument containing a sequence of formatting directives. The attacker can read from the stack by providing more formatting directives, such as %x, than the function takes as arguments to be formatted. (In this example, the function takes no arguments to be formatted.) By using the %n formatting directive, the attacker can write to the stack, causing snprintf() to write the number of bytes output thus far to the specified argument (rather than reading a value from the argument, which is the intended behavior). A sophisticated version of this attack will use four staggered writes to completely control the value of a pointer on the stack. Certain implementations make more advanced attacks even easier by providing format directives that control the location in memory to read from or write to. An example of these directives is shown in the following code, written for glibc: This code produces the following output: 5 9 5 5 It is also possible to use half-writes (%hn) to accurately control arbitrary DWORDS in memory, which greatly reduces the complexity needed to execute an attack that would otherwise require four staggered writes, such as the one mentioned in the first example. CVE-2002-1825 format string in Perl program CVE-2001-0717 format string in bad call to syslog function CVE-2002-0573 format string in bad call to syslog function CVE-2002-1788 format strings in NNTP server responses CVE-2007-2027 Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages While Format String vulnerabilities typically fall under the Buffer Overflow category, technically they are not overflowed buffers. The Format String vulnerability is fairly new (circa 1999) and stems from the fact that there is no realistic way for a function that takes a variable number of arguments to determine just how many arguments were passed in. The most common functions that take a variable number of arguments, including C-runtime functions, are the printf() family of calls. The Format String problem appears in a number of ways. A *printf() call without a format specifier is dangerous and can be exploited. For example, printf(input); is exploitable, while printf(y, input); is not exploitable in that context. The result of the first call, used incorrectly, allows for an attacker to be able to peek at stack memory since the input string will be used as the format specifier. The attacker can stuff the input string with format specifiers and begin reading stack values, since the remaining parameters will be pulled from the stack. Worst case, this improper use may give away enough control to allow an arbitrary value (or values in the case of an exploit program) to be written into the memory of the running program Frequently targeted entities are file names, process names, identifiers Format string problems are a classic C/C++ issue that are now rare due to the ease of discovery. The reason format string vulnerabilities can be exploited is due to the %n operator. The %n operator will write the number of characters, which have been printed by the format string therefore far, to the memory pointed to by its argument. Through skilled creation of a format string, a malicious user may use values on the stack to create a write-what-where condition. Once this is achieved, he can execute arbitrary code. Format string issues are under-studied for languages other than C. Memory or disk consumption, control flow or variable alteration, and data corruption may result from format string exploitation in applications written in other languages such as Perl, PHP, Python, etc. Since format strings often occur in rarely-occurring erroneous conditions, it is highly that many latent issues exist in executables that do not have associated source code (or equivalent source). Steve Christey Format String Vulnerabilities in Perl Programs http://www.securityfocus.com/archive/1/418460/30/0/threaded Hal Burch Robert C. Seacord Programming Language Format String Vulnerabilities http://www.ddj.com/dept/security/197002914 Tim Newsham Format String Attacks Guardent September 2000 http://www.lava.net/~newsham/format-string-attacks.pdf 1000 Category ChildOf 133 1000 Weakness ChildOf 74 1000 Weakness PeerOf 123 630 View ChildOf 630 631 Category ChildOf 633 635 View ChildOf 635 Format string vulnerability Format String Format string problem All Implementation 67 A weakness where the code path has: 1. start statement that accepts input 2. end statement that passes a format to format output function where a. the input data is part of the format and b. the format is undesirable Where “undesirable” is defined through the following scenarios: 1. not validated 2. incorrectly validated The software does not properly calculate the length of strings that can contain wide or multi-byte characters. The following example would be exploitable if any of the commented incorrect malloc calls were used. C #include #include int main() { wchar_t wideString[] = L"The spazzy orange tiger jumped " \ "over the tawny jaguar."; wchar_t *newString; printf("Strlen() output: %d\nWcslen() output: %d\n", strlen(wideString), wcslen(wideString)); /* Very wrong for obvious reasons // newString = (wchar_t *) malloc(strlen(wideString)); */ /* Wrong because wide characters aren't 1 byte long! // newString = (wchar_t *) malloc(wcslen(wideString)); */ /* correct! */ newString = (wchar_t *) malloc(wcslen(wideString) * sizeof(wchar_t)); /* ... */ }]]> The output from the printf() statement would be: Strlen() output: 0 Wcslen() output: 53 There are several ways in which improper string length checking may result in an exploitable condition. All of these, however, involve the introduction of buffer overflow conditions in order to reach an exploitable state. The first of these issues takes place when the output of a wide or multi-byte character string, string-length function is used as a size for the allocation of memory. While this will result in an output of the number of characters in the string, note that the characters are most likely not a single byte, as they are with standard character strings. So, using the size returned as the size sent to new or malloc and copying the string to this newly allocated memory will result in a buffer overflow. Another common way these strings are misused involves the mixing of standard string and wide or multi-byte string functions on a single string. Invariably, this mismatched information will result in the creation of a possibly exploitable buffer overflow condition. Again, if a language subject to these flaws must be used, the most effective mitigation technique is to pay careful attention to the code at implementation time and ensure that these flaws do not occur. 1000 Weakness ChildOf 682 1000 Category ChildOf 133 Improper string length checking C C++ The software fails to prevent the introduction of special elements with control implications into a mixed data / control stream. Often times, platforms or environments have special elements that carry control implications. If software fails to prevent external control or influence over the inclusion of such special elements, the control flow of the program may be altered from what was intended. Developers should anticipate that special elements (e.g. delimiters, symbols) will be injected into input vectors of their software system. One defense is to create a while list (e.g. a regular expression) that defines valid input according to the requirements specifications. Strictly filter any input that does not match against the white list. 1000 Category ChildOf 137 Special Elements (Characters or Reserved Words) 15 Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal." Memory Overwrite sensitive data in memory prior to clearing. Where possible, encrypt sensitive data that are used by a software system. The following code reads a password from the user, uses the password to connect to a back-end mainframe and then attempts to scrub the password from memory using memset(). The code in the example will behave correctly if it is executed verbatim, but if the code is compiled using an optimizing compiler, such as Microsoft Visual C++® .NET or GCC 3.x, then the call to memset() will be removed as a dead store because the buffer pwd is not used after its value is overwritten [18]. Because the buffer pwd contains a sensitive value, the application may be vulnerable to attack if the data are left memory resident. If attackers are able to access the correct region of memory, they may use the recovered password to gain control of the system. It is common practice to overwrite sensitive data manipulated in memory, such as passwords or cryptographic keys, in order to prevent attackers from learning system secrets. However, with the advent of optimizing compilers, programs do not always behave as their source code alone would suggest. In the example, the compiler interprets the call to memset() as dead code because the memory being written to is not subsequently used, despite the fact that there is clearly a security motivation for the operation to occur. The problem here is that many compilers, and in fact many programming languages, do not take this and other security concerns into consideration in their efforts to improve efficiency. Attackers typically exploit this type of vulnerability by using a core dump or runtime mechanism to access the memory used by a particular application and recover the secret information. Once an attacker has access to the secret information, it is relatively straightforward to further exploit the system and possibly compromise other resources with which the application interacts. Compiler optimization errors occur when: 1. Secret data are stored in memory. 2. The secret data are scrubbed from memory by overwriting its contents. 3. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently. This is also an interaction error. This can be hard to diagnose. Michael Howard When scrubbing secrets in memory doesn't work BugTraq 2002-11-05 http://cert.uni-stuttgart.de/archive/bugtraq/2002/11/msg00046.html http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure10102002.asp Joseph Wagner GNU GCC: Optimizer Removes Code Necessary for Security Bugtraq 2002-11-16 http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2002-11/0257.html 1000 Category ChildOf 503 1000 Weakness CanAlsoBe 435 631 Category ChildOf 633 Insecure Compiler Optimization Sensitive memory uncleared by compiler optimization .NET The software does not properly sanitize delimiters. Developers should anticipate that delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 138 Delimiter Problems 15 Parameter delimiters injected into an application can be used to compromise a system. As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions. Developers should anticipate that parameter delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2003-0307 Attacker inserts field separator into input to specify admin privileges. 1000 Weakness ChildOf 140 Parameter Delimiter All Value delimiters injected into an application can be used to compromise a system. As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions. Developers should anticipate that value delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2000-0293 Multiple internal space, insufficient quoting - program does not use proper delimiter between values. 1000 Weakness ChildOf 140 Value Delimiter All Record delimiters injected into an application can be used to compromise a system. As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions. Developers should anticipate that record delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2004-1982 Carriage returns in subject field allow adding new records to data file. CVE-2001-0527 Attacker inserts carriage returns and "|" field separator characters to add new user/privileges. 1000 Weakness ChildOf 140 Record Delimiter All Line delimiters injected into an application can be used to compromise a system. As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions. Developers should anticipate that line delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2002-0267 Linebreak in field of PHP script allows admin privileges when written to data file. Depending on the language and syntax being used, this could be the same as the record delimiter. 1000 Weakness ChildOf 140 1000 Weakness CanAlsoBe 93 Line Delimiter All Section delimiters injected into an application can be used to compromise a system. As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions that result in an attack. One example of a section delimiter is the boundary string in a multipart MIME message. In many cases, doubled line delimiters can serve as a section delimiter. Developers should anticipate that section delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. Depending on the language and syntax being used, this could be the same as the record delimiter. 1000 Weakness ChildOf 140 1000 Weakness CanAlsoBe 93 Section Delimiter All Delimiters between expressions or commands injected into the software through input can be used to compromise a system. As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions that result in an attack. Developers should anticipate that inter-expression and inter-command delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. Shell metacharacters (covered elsewhere) is one example. 1000 Weakness ChildOf 140 Delimiter between Expressions or Commands All 15 6 Terminators injected into the software through input can be used to compromise a system. Example: a "." in SMTP signifies the end of mail message data, whereas a null character can be used for the end of a string. Developers should anticipate that terminators will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2000-0319 MFV. mail server does not properly identify terminator string to signify end of message, causing corruption, possibly in conjunction with off-by-one error. CVE-2000-0320 MFV. mail server does not properly identify terminator string to signify end of message, causing corruption, possibly in conjunction with off-by-one error. CVE-2001-0996 Mail server does not quote end-of-input terminator if it appears in the middle of a message. CVE-2002-0001 Improperly terminated comment or phrase allows commands. 1000 Weakness ChildOf 138 Input Terminator All The application does not properly handle when a leading character or sequence ("leader") is missing or malformed, or if multiple leaders are used when only one should be allowed. Developers should anticipate that leading characters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 138 Input Leader Quotes injected into an application can be used to compromise a system. As data are parsed, an injected/absent/duplicate/malformed use of quotes may cause the process to take unexpected actions. Developers should anticipate that quotes will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2003-1016 CVE-2004-0956 CVE-2003-1016 MIE. MFV too? bypass AV/security with fields that should not be quoted, duplicate quotes, missing leading/trailing quotes. 1000 Weakness ChildOf 138 Quoting Element One or more system settings or configuration elements can be externally controlled by a user. Allowing external control of system settings can disrupt service or cause an application to behave in unexpected, and potentially malicious, ways. Compartmentalize your system and determine where the trust boundaries exist. Any input/control outside the trust boundary should be treated as potentially hostile. Because setting manipulation covers a diverse set of functions, any attempt at illustrating it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control. In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker. The following C code accepts a number as one of its command line parameters and sets it as the host ID of the current machine. C Although a process must be privileged to successfully invoke sethostid(), unprivileged users may be able to invoke the program. The code in this example allows user input to directly control the value of a system setting. If an attacker provides a malicious value for host ID, the attacker can misidentify the affected machine on the network or cause other unintended behavior. The following Java code snippet reads a string from an HttpServletRequest and sets it as the active catalog for a database Connection. Java In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database. Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application. 1000 Weakness ChildOf 610 1000 Category ChildOf 2 Setting Manipulation 13 76 77 69 Escape, meta, or control character/sequence injected into an application through input can be used to compromise a system. as data is parsed, injected/absent/malformed escape, meta, or control characters/sequences may cause the process to take unexpected actions that result in an attack. Developers should anticipate that escape, meta and control characters/sequences will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2002-0542 Mail program handles special "~" escape sequence even when not in interactive mode. CVE-2000-0703 Setuid program does not filter escape sequences before calling mail program. CVE-2002-0986 Mail function does not filter control characters from arguments, allowing mail message content to be modified. CVE-2003-0020 Multi-channel issue. Terminal escape sequences not filtered from log files. CVE-2003-0083 Multi-channel issue. Terminal escape sequences not filtered from log files. CVE-2003-0021 Terminal escape sequences not filtered by terminals when displaying files. CVE-2003-0022 Terminal escape sequences not filtered by terminals when displaying files. CVE-2003-0023 Terminal escape sequences not filtered by terminals when displaying files. CVE-2003-0063 Terminal escape sequences not filtered by terminals when displaying files. CVE-2000-0476 Terminal escape sequences not filtered by terminals when displaying files. CVE-2001-1556 MFV. (multi-channel). Injection of control characters into log files that allow information hiding when using raw Unix programs to read the files. 1000 Weakness ChildOf 138 Escape, Meta, or Control Character / Sequence All 81 93 41 Comments injected into an application through input can be used to compromise a system. As data is parsed, an injected/malformed comment may cause the process to take unexpected actions. Developers should anticipate that comments will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2002-0001 Mail client command execution due to improperly terminated comment in address list. CVE-2004-0162 MIE. RFC822 comment fields may be processed as other fields by clients. CVE-2004-1686 Well-placed comment bypasses security warning. CVE-2005-1909 Information hiding using a manipulation involving injection of comment code into product. Note: these vulns are likely vulnerable to more general XSS problems, although a regexp might allow ">!--" while denying most other tags. CVE-2005-1969 Information hiding using a manipulation involving injection of comment code into product. Note: these vulns are likely vulnerable to more general XSS problems, although a regexp might allow "<!--" while denying most other tags. 1000 Weakness ChildOf 138 Comment Element All Macro symbols injected into an application through input can be used to compromise a system. As data is parsed, an injected symbol may cause the process to take unexpected actions. Developers should anticipate that macro symbols will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2002-0770 Server trusts client to expand macros, allows macro characters to be expanded to trigger resultant infoleak. Under-studied. 1000 Weakness ChildOf 138 Macro Symbol All Substitution symbols injected into an application through input can be used to compromise a system. As data is parsed, an injected symbol may cause the process to take unexpected actions. Developers should anticipate that substitution characters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2002-0770 Server trusts client to expand macros, allows macro characters to be expanded to trigger resultant infoleak. Under-studied. 1000 Weakness ChildOf 138 Substitution Character All Variable name delimiters injected into an application through input can be used to compromise a system. As data is parsed, an injected delimiter may cause the process to take unexpected actions that result in an attack. Example: "$" for an environment variable. Developers should anticipate that variable name delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2005-0129 "%" variable is expanded by wildcard function into disallowed commands. CVE-2002-0770 Server trusts client to expand macros, allows macro characters to be expanded to trigger resultant infoleak. Under-studied. 1000 Weakness ChildOf 138 Variable Name Delimiter All 15 Wildcard or matching elements (e.g. '*') injected into an application through input can be used to compromise a system. As data is parsed, an injected element may cause the process to take unexpected actions. Developers should anticipate that wildcard or matching elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2002-0433 Bypass file restrictions using wildcard character. CVE-2002-1010 Bypass file restrictions using wildcard character. CVE-2001-0334 Wildcards generate long string on expansion. CVE-2004-1962 SQL injection involving "/**/" sequences. Under-studied. 1000 Weakness ChildOf 138 Wildcard or Matching Element All White space injected into an application through input can be used to compromise a system. As data is parsed, improperly handled white space may cause the process to take unexpected actions. White space Developers should anticipate that whitespace will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2002-0637 MIE. virus protection bypass with RFC violations involving extra whitespace, or missing whitespace. CVE-2004-0942 CPU consumption with MIME headers containing lines with many space characters, probably due to algorithmic complexity (RESOURCE.AMP.ALG). CVE-2003-1015 MIE. whitespace interpreted differently by mail clients. This can include space, tab, etc. Can overlap other separator characters or delimiters. 1000 Weakness ChildOf 138 Whitespace All The software does not properly handle the characters that are used to mark the beginning and ending of a group of entities, such as parentheses, brackets, and braces. Developers should anticipate that grouping elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. " angle brackets [*] "(" and ")" parentheses [*] "{" and "}" braces [*] "[" and "]" square brackets [*] '"' and '"' double quotes [*] "'" and "'" single quotes]]> CVE-2004-0956 Crash via missing paired delimiter (open double-quote but no closing double-quote). CVE-2000-1165 Crash via message without closing ">". CVE-2005-2933 Buffer overflow via mailbox name with an opening double quote but missing a closing double quote, causing a larger copy than expected. Under-studied. 1000 Weakness ChildOf 138 Grouping Element / Paired Delimiter All 15 NUL characters or null bytes injected into an application through input can be used to compromise a system. As data is parsed, an injected NUL character or null byte may cause the process to take unexpected actions that result in an attack. Developers should anticipate that null characters or null bytes will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2005-2008 Source code disclosure using trailing null. CVE-2005-3293 Source code disclosure using trailing null. CVE-2005-2061 Trailing null allows file include. CVE-2002-1774 Null character in MIME header allows detection bypass. CVE-2000-0149 CVE-2000-0671 CVE-2001-0738 CVE-2001-1140 CVE-2002-1031 CVE-2002-1025 CVE-2003-0768 CVE-2004-0189 Decoding function in proxy allows regular expression bypass in ACLs via URLs with null characters. CVE-2005-3153 Null byte bypasses PHP regexp check (interaction error). CVE-2005-4155 Null byte bypasses PHP regexp check (interaction error). This can be a factor in multiple interpretation errors, other interaction errors, filename equivalence, etc. 1000 Weakness ChildOf 138 Null Character / Null Byte All Implementation 53 52 Weaknesses in this attack-focused category fail to sufficiently filter and interpret special elements in user-controlled input which could cause adverse effect on the software behavior and integrity. Developers should anticipate that special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. The variety of manipulations that involve special elements is staggering. This is one reason why they are so frequently reported. As previously discussed, precise terminology for the underlying weaknesses does not exist. Therefore, these weaknesses use the terminology associated with the manipulation. weaknesses involving special characters do not always require special manipulations besides injection of the special character, but sometimes they do. This list is FAR from complete. Customized languages and grammars, even those that are specific to a particular product, are potential sources of weaknesses that are related to special elements. However, most researchers concentrate on the most commonly used representations for data transmission, such as HTML and SQL. Any representation that is commonly used is likely to be a rich source of weaknesses; researchers are encouraged to investigate previously unexplored representations. 1000 Weakness ChildOf 138 Common Special Element Manipulations All Leading special elements injected into an application through input can be used to compromise a system. As data is parsed, improperly handled leading special elements may cause the process to take unexpected actions that result in an attack. Developers should anticipate that leading special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 159 Leading Special Element All Multiple leading special elements injected into an application through input can be used to compromise a system. As data is parsed, improperly handled multiple leading special elements may cause the process to take unexpected actions that result in an attack. Developers should anticipate that multiple leading special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 160 Multiple Leading Special Elements All Trailing special elements injected into an application through input can be used to compromise a system. As data is parsed, improperly handled trailing special elements may cause the process to take unexpected actions that result in an attack. Developers should anticipate that trailing special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 159 Trailing Special Element All Multiple trailing special elements injected into an application through input can be used to compromise a system. As data is parsed, improperly handled multiple trailing special elements may cause the process to take unexpected actions that result in an attack. Developers should anticipate that multiple trailing special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 162 Multiple Trailing Special Elements All Internal special elements injected into an application through input can be used to compromise a system. As data is parsed, improperly handled internal special elements may cause the process to take unexpected actions that result in an attack. Developers should anticipate that internal special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 159 Internal Special Element All Multiple internal special elements injected into an application through input can be used to compromise a system. As data is parsed, improperly handled multiple internal special elements may cause the process to take unexpected actions that result in an attack. Developers should anticipate that multiple internal special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 164 Multiple Internal Special Element All The software does not handle when an expected special element (character or reserved word) is missing. Developers should anticipate that special elements will be removed in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2002-1362 Crash via message type without separator character CVE-2002-0729 Missing special character (separator) causes crash CVE-2002-1532 HTTP GET without \r\n\r\n CRLF sequences causes product to wait indefinitely and prevents other users from accessing it This can overlap incomplete input. 1000 Weakness ChildOf 159 Missing Special Element All The software does not handle when an additional unexpected special element (character or reserved word) is used. Developers should anticipate that extra special elements will be injected in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. CVE-2000-0116 Extra "<" in front of SCRIPT tag. CVE-2001-1157 Extra "<" in front of SCRIPT tag. CVE-2002-2086 "<script" - probably a cleansing error 1000 Weakness ChildOf 159 Extra Special Element All The software does not handle when an inconsistency exists between two or more special characters or reserved words, e.g. if paired characters appear in the wrong order, or if the special characters are not properly nested. Developers should anticipate that inconsistent special elements will be injected/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. 1000 Weakness ChildOf 159 Inconsistent Special Elements All The software does not properly terminate a string or array with a null character or equivalent terminator. Null termination errors frequently occur in two different ways. An off-by-one error could cause a null to be written out of bounds, leading to an overflow. Or, a program could use a strncpy() function call incorrectly, which prevents a null terminator from being added at all. Other scenarios are possible. High If performance constraints permit, special code can be added that validates null-termination of string buffers, this is a rather naïve and error-prone solution. Switch to bounded string manipulation functions. Inspect buffer lengths involved in the buffer overrun trace reported with the defect. Add code that fills buffers with nulls (however, the length of buffers still needs to be inspected, to ensure that the non null-terminated string is not written at the physical end of the buffer). Example 1: The following code reads from cfgfile and copies the input into inputbuf using strcpy(). The code mistakenly assumes that inputbuf will always contain a NULL terminator. The code in Example 1 will behave correctly if the data read from cfgfile is null terminated on disk as expected. But if an attacker is able to modify this input so that it does not contain the expected NULL character, the call to strcpy() will continue copying from memory until it encounters an arbitrary NULL character. This will likely overflow the destination buffer and, if the attacker can control the contents of memory immediately following inputbuf, can leave the application susceptible to a buffer overflow attack. Example 2: In the following code, readlink() expands the name of a symbolic link stored in the buffer path so that the buffer filename contains the absolute path of the file referenced by the symbolic link. The length of the resulting value is then calculated using strlen(). The code in Example 2 will not behave correctly because the value read into buf by readlink() will not be null terminated. In testing, vulnerabilities like this one might not be caught because the unused contents of buf and the memory immediately following it may be NULL, thereby causing strlen() to appear as if it is behaving correctly. However, in the wild strlen() will continue traversing memory until it encounters an arbitrary NULL character on the stack, which results in a value of length that is much larger than the size of buf and may cause a buffer overflow in subsequent uses of this value. Buffer overflows aside, whenever a single call to readlink() returns the same value that has been passed to its third argument, it is impossible to know whether the name is precisely that many bytes long, or whether readlink() has truncated the name to avoid overrunning the buffer. Traditionally, strings are represented as a region of memory containing data terminated with a NULL character. Older string-handling methods frequently rely on this NULL character to determine the length of the string. If a buffer that does not contain a NULL terminator is passed to one of these functions, the function will read past the end of the buffer. Malicious users typically exploit this type of vulnerability by injecting data with unexpected size or content into the application. They may provide the malicious input either directly as input to the program or indirectly by modifying application resources, such as configuration files. In the event that an attacker causes the application to read beyond the bounds of a buffer, the attacker may be able use a resulting buffer overflow to inject and execute arbitrary code on the system. CVE-2000-0312 Attacker does not null-terminate argv[] when invoking another program. CVE-2003-0777 Interrupted step causes resultant lack of null termination. CVE-2004-1072 Fault causes resultant lack of null termination, leading to buffer expansion. CVE-2001-1389 Multiple vulnerabilities related to improper null termination. CVE-2003-0143 Product does not null terminate a message buffer after snprintf-like call, leading to overflow. Conceptually, this does not just apply to the C language; any language or representation that involves a terminator could have this sort of problem. Factors: this is usually resultant from other weaknesses such as off-by-one errors, but it can be primary to boundary condition violations such as buffer overflows. In buffer overflows, it can act as an expander for assumed-immutable data. Overlaps missing input terminator. 1000 Category ChildOf 169 1000 Compound_Element CanPrecede 120 1000 Weakness CanAlsoBe 147 630 View ChildOf 630 Improper Null Termination String Termination Error C C++ A weakness where the code path has: 1. end statement that passes a data item to a null-terminated string function 2. start statement that removes the null-terminator from the data item Where “removes” is defined through the following scenarios: 1. data item never ended with null-terminator 2. null-terminator is re-written 3. null-terminator was purposely removed from data item The software fails to properly handle encoding or decoding of the data, resulting in unexpected values. Partially overlaps path traversal and equivalence weaknesses. Many other types of encodings should be listed in this category. 0 1000 Category ChildOf 171 0 1000 Weakness CanAlsoBe 21 Encoding Error All 80 71 53 72 64 3 78 52 The software does not properly handle when an input uses an alternate encoding that is valid for the control sphere to which the input is being sent. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). 1000 Weakness ChildOf 172 1000 Weakness CanPrecede 289 Alternate Encoding All 80 79 71 53 72 64 3 78 52 The software decodes the same input twice, which can limit the effectiveness of any protection mechanism that occurs in between the decoding operations. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). CVE-2001-0333 CVE-2005-0054 CVE-2004-1315 CVE-2004-1938 CVE-2004-1939 CVE-2001-0333 Directory traversal using double encoding. CVE-2004-1938 "%2527" (double-encoded single quote) used in SQL injection. CVE-2005-1945 Double hex-encoded data. CVE-2005-0054 Browser executes HTML at higher privileges via URL with hostnames that are double hex encoded, which are decoded twice to generate a malicious hostname. Probably under-studied. 1000 Weakness ChildOf 172 1000 Weakness ChildOf 675 Double Encoding All Implementation The software does not properly handle when the same input uses several different (mixed) encodings. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). 1000 Weakness ChildOf 172 Mixed Encoding All The software does not properly handle when an input contains Unicode encoding. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). Windows provides the MultiByteToWideChar(), WideCharToMultiByte(), UnicodeToBytes(), and BytesToUnicode() functions to convert between arbitrary multibyte (usually ANSI) character strings and Unicode (wide character) strings. The size arguments to these functions are specified in different units.. one in bytes, the other in characters.. making their use prone to error. In a multibyte character string, each character occupies a varying number of bytes, and therefore the size of such strings is most easily specified as a total number of bytes. In Unicode, however, characters are always a fixed size, and string lengths are typically given by the number of characters they contain. Mistakenly specifying the wrong units in a size argument can lead to a buffer overflow. The following function takes a username specified as a multibyte string and a pointer to a structure for user information and populates the structure with information about the specified user. Since Windows authentication uses Unicode for usernames, the username argument is first converted from a multibyte string to a Unicode string. This function incorrectly passes the size of unicodeUser in bytes instead of characters. The call to MultiByteToWideChar() can therefore write up to (UNLEN+1)*sizeof(WCHAR) wide characters, or (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, to the unicodeUser array, which has only (UNLEN+1)*sizeof(WCHAR) bytes allocated. If the username string contains more than UNLEN characters, the call to MultiByteToWideChar() will overflow the buffer unicodeUser. CVE-2000-0884 CVE-2001-0709 CVE-2001-0669 Overlaps interaction error. 1000 Weakness ChildOf 172 Unicode Encoding All 71 The software does not properly handle when all or part of an input has been URL encoded. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). CVE-2000-0900 Hex-encoded path traversal variants - "%2e%2e", "%2e%2e%2f", "%5c%2e%2e" CVE-2005-2256 Hex-encoded path traversal variants - "%2e%2e", "%2e%2e%2f", "%5c%2e%2e" CVE-2004-2121 Hex-encoded path traversal variants - "%2e%2e", "%2e%2e%2f", "%5c%2e%2e" CVE-2004-0280 "%20" (encoded space) CVE-2003-0424 "%20" (encoded space) CVE-2001-0693 "%20" (encoded space) CVE-2001-0778 "%20" (encoded space) CVE-2002-1831 Crash via hex-encoded space "%20". CVE-2000-0671 "%00" (encoded null) CVE-2004-0189 "%00" (encoded null) CVE-2002-1291 "%00" (encoded null) CVE-2002-1031 "%00" (encoded null) CVE-2001-1140 "%00" (encoded null) CVE-2004-0760 "%00" (encoded null) CVE-2002-1025 "%00" (encoded null) CVE-2004-0072 "%2e" (encoded dot) CVE-2002-1213 "%2f" (encoded slash) CVE-2004-0072 "%5c" (encoded backslash) CVE-2004-0847 "%5c" (encoded backslash) CVE-2002-1575 "%0a" (overlaps CRLF) 1000 Weakness ChildOf 172 URL Encoding (Hex Encoding) All 72 64 Improperly handled case sensitive data can lead to several possible consequences, including: - case-insensitive passwords reducing the size of the key space, making brute force attacks easier - bypassing filters or access controls using alternate names - multiple interpretation errors using alternate names. File Processing, Credentials File/Directory Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). CVE-2000-0497 CVE-2000-0498 CVE-2001-0766 CVE-2001-0795 CVE-2001-1238 CVE-2003-0411 CVE-2002-0485 Leads to interpretation error CVE-1999-0239 CVE-2005-0269 CVE-2004-1083 CVE-2004-2154 Overlaps ACL bypass CVE-2000-0499 CVE-2002-2119 Case insensitive passwords lead to search space reduction. CVE-2004-2214 HTTP server allows bypass of access restrictions using URIs with mixed case. CVE-2004-2154 Mixed upper/lowercase allows bypass of ACLs. CVE-2004-2214 Bypass access restrictions using mixed case. CVE-2005-4509 Bypass malicious script detection by using tokens that aren't case sensitive. CVE-2002-1820 Mixed case problem allows "admin" to have "Admin" rights (alternate name property). CVE-2007-3365 Chain: uppercase file extensions causes web server to return script source code instead of executing the script. These are probably under-studied in Windows and Mac environments, where file names are case-insensitive and thus are subject to equivalence manipulations involving case. 1000 Category ChildOf 171 1000 Weakness CanPrecede 433 1000 Weakness CanPrecede 289 631 Category ChildOf 632 Case Sensitivity (lowercase, uppercase, mixed case) All Software needs to validate data at the proper time, after data has been canonicalized and cleansed. Early validation is susceptible to various manipulations that result in dangerous inputs that are produced by canonicalization and cleansing. Validate data after attempts to canonicalize the resource name. Since early validation errors usually arise from improperly implemented defensive mechanisms, it is likely that these will be reported more frequently as secure programming becomes implemented more widely. These errors are mostly reported in path traversal vulnerabilities, but the concept applies anyplace where filtering occurs. 1000 Category ChildOf 171 1000 Weakness ChildOf 693 Early Validation Errors All 71 3 43 Software "validates" data before it is canonicalized, which leaves it vulnerable to certain manipulations that are later removed during canonicalization. Invalid data can then avoid detection before it is produced by canonicalization. Non-specific Validate data after attempts to canonicalize the resource name. CVE-2002-0433 CVE-2003-0332 CVE-2002-0802 CVE-2000-0191 Overlaps "fakechild/../realchild" CVE-2004-2363 Product checks URI for "<" and other literal characters, but does it before hex decoding the URI, so "%3E" and other sequences are allowed. This overlaps other categories. 1000 Category ChildOf 171 1000 Weakness ChildOf 693 Validate-Before-Canonicalize All Architecture and Design Implementation 80 79 71 3 4 78 Software validates data before it has been filtered or cleansed, which could produce dangerous data after the filtering step. Validate-before-cleanse Non-specific Filter data after attempts to canonicalize the resource name. CVE-2002-0934 CVE-2003-0282 CVE-2003-0417 Possibly This category is probably under-studied. 1000 Category ChildOf 171 1000 Weakness ChildOf 693 Validate-Before-Filter All Architecture and Design Implementation 80 79 3 78 43 Software cleanses or filters data in a way that causes the data to "collapse" into an unsafe value. Validate data after attempts to canonicalize. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). CVE-2004-0815 "/.////" in pathname collapses to absolute path. CVE-2005-3123 "/.//..//////././" is collapsed into "/.././" after ".." and "//" sequences are removed. CVE-2002-0325 ".../...//" collapsed to "..." due to removal of "./" in web server. CVE-2002-0784 "///./../.../" claimed to work - "./" removal would produce "///..." CVE-2005-2169 MFV. Regular expression intended to protect against directory traversal reduces ".../...//" to "../". Overlaps regular expressions, although an implementation might not necessarily use regexp's. 1000 Category ChildOf 171 1000 Weakness ChildOf 693 1000 Weakness CanAlsoBe 185 Collapse of Data into Unsafe Value All Architecture and Design Implementation An application uses a "whitelist" of acceptable values, but the whitelist permits at least one unsafe value. Define rigid requirements specifications for input and strictly accept input based on those specifications. Determine if any of the valid data include special characters that are associated with security exploits (use this taxonomy and the Common Vulnerabilities and Exposures as a start to determine what characters are potentially malicious). If permitted, then follow the potential mitigations associated with the weaknesses in this taxonomy. Always handle these data carefully and anticipate attempts to exploit your system. Note that a permissive whitelist produces resultant vulnerabilities. 1000 Category ChildOf 171 1000 Weakness ChildOf 693 Permissive Whitelist All Architecture and Design Implementation 71 3 43 An application uses a "blacklist" of prohibited values, but the blacklist is incomplete. Primary (Weakness exists independent of other weaknesses) Ensure black list covers all inappropriate content outlined in the Common Weakness Enumeration. Combine use of black list with appropriate use of white lists. CVE-2005-2782 PHP remote file inclusion in web application that filters "http" and "https" URLs, but not "ftp". CVE-2004-0542 Programming language does not filter certain shell metacharacters in Windows environment. CVE-2004-0595 XSS filter doesn't filter null characters before looking for dangerous tags, which are ignored by web browsers. MIE and validate-before-cleanse. CVE-2005-3287 Web-based mail product doesn't restrict dangerous extensions such as ASPX on a web server, even though others are prohibited. CVE-2004-2351 Resultant XSS from incomplete blacklist (only <script> and <style> are checked). CVE-2005-2959 Privileged program does not clear sensitive environment variables that are used by bash. Overlaps multiple interpretation error. CVE-2005-1824 SQL injection protection scheme does not quote the "\" special character. CVE-2005-2184 Incomplete blacklist prevents user from automatically executing .EXE files, but allows .LNK, allowing resultant Windows symbolic link. CVE-2007-1343 product doesn't protect one dangerous variable against external modification http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1343 CVE-2007-5727 Chain: only removes SCRIPT tags, enabling XSS CVE-2006-4308 Chain: only checks "javascript:" tag CVE-2007-3572 Chain: incomplete blacklist for OS command injection An incomplete blacklist frequently produces resultant weaknesses. Exploitation of those weaknesses using the obvious manipulations might fail, but minor variations might succeed. Some incomplete blacklist issues might arise from multiple interpretation errors, e.g. a blacklist for dangerous shell metacharacters might not include a metacharacter that only has meaning in one particular shell, not all of them; or a blacklist for XSS manipulations might ignore an unusual construct that's supported by one web browser, but not others. G. Hoglund G. McGraw Exploiting Software: How to Break Code Addison-Wesley February 2004 S. Christey Blacklist defenses as a breeding ground for vulnerability variants February 2006 http://seclists.org/fulldisclosure/2006/Feb/0040.html 1000 Category ChildOf 171 1000 Weakness ChildOf 693 1000 Weakness CanPrecede 79 1000 Weakness CanPrecede 78 1000 Compound_Element CanPrecede 434 1000 Compound_Element CanPrecede 98 1000 692 Weakness CanPrecede 79 Incomplete Blacklist All Architecture and Design Implementation 3 15 6 43 71 18 63 73 85 86 A regular expression is incorrectly specified in a way that causes data to be improperly filtered, compared, or cleansed. Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplifies one large regular expression. Also, subject your regular expression to thorough testing techniques such as equivalence partitioning, boundary value analysis, and robustness. After testing and a reasonable confidence level is achieved a regular expression may not be full proof. If an exploit is allowed to slip through, then record the exploit and refactor your regular expression. CVE-2002-2109 Regexp isn't "anchored" to the beginning or end, which allows spoofed values that have trusted values as substrings. CVE-2005-1949 Regexp for IP address isn't anchored at the end, allowing appending of shell metacharacters. CVE-2001-1072 Bypass access restrictions via multiple leading slash, which causes a regular expression to fail. CVE-2000-0115 Local user DoS via invalid regular expressions. CVE-2002-1527 Error infoleak via malformed input that generates a regular expression error. CVE-2005-0603 Error infoleak via regular expression with invalid syntax. CVE-2005-1061 Certain strings are later used in a regexp, leading to a resultant crash. CVE-2005-2169 MFV. Regular expression intended to protect against directory traversal reduces ".../...//" to "../". CVE-2005-0603 Malformed regexp syntax leads to error infoleak. CVE-2005-1820 Code injection due to improper quoting of regular expression. CVE-2005-3153 Null byte bypasses PHP regexp check. CVE-2005-4155 Null byte bypasses PHP regexp check. Keywords: regexp This can seem to overlap whitelist/blacklist problems, but it is intended to deal with improperly written regular expressions, regardless of the values that those regular expressions use. Can overlap partial comparison. Interacts with null byte in PHP. Regexp errors are likely a primary factor in many MFVs, especially those that require multiple manipulations to exploit. However, they are rarely diagnosed at this level of detail. 1000 Category ChildOf 171 1000 Weakness CanAlsoBe 187 Regular Expression Error All 79 15 6 A regular expression is overly restrictive, which prevents dangerous values from being detected. CVE-2005-1604 MIE. ".php.ns" bypasses ".php$" regexp but is still parsed as PHP by Apache. (manipulates an equivalence property under Apache) Can overlap whitelist/blacklist errors. 1000 Weakness ChildOf 185 1000 Weakness CanAlsoBe 184 1000 Weakness CanAlsoBe 183 Overly Restrictive Regular Expression All User input is only partially compared to the desired input before a match is determined. For example, an attacker might succeed in authentication by providing a small password that matches the associated portion of the larger, correct password. CVE-2004-1012 Argument parser of an IMAP server treats a partial command "body[p" as if it is "body.peek", leading to index error and out-of-bounds corruption. CVE-2004-0765 Web browser only checks the hostname portion of a certificate when the hostname portion of the URI is not a fully qualified domain name (FQDN), which allows remote attackers to spoof trusted certificates. CVE-2002-1374 One-character password by attacker checks only against first character of real password. This is conceptually similar to other weaknesses, such as insufficient verification and regular expression errors. It is primary to some weaknesses. 1000 Category ChildOf 171 Partial Comparison All The software makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior. Low Access control (including confidentiality and integrity): Can result in unintended modifications or information leaks of data. Design and Implementation: In flat address space situations, never allow computing memory addresses as offsets from another memory address. Design: Fully specify protocol layout unambiguously, providing a structured grammar (e.g., a compilable yacc grammar). Testing: Test that the implementation properly handles each case in the protocol grammar. C Here, b may not be one byte past a. It may be one byte in front of a. Or, they may have three bytes between them because they get aligned to 32-bit boundaries. When changing platforms or protocol versions, data may move in unintended ways. For example, some architectures may place local variables a and b right next to each other with a on top; some may place them next to each other with b on top; and others may add some padding to each. This ensured that each variable is aligned to a proper word size. In protocol implementations, it is common to offset relative to another field to pick out a specific piece of data. Exceptional conditions -- often involving new protocol versions -- may add corner cases that lead to the data layout changing in an unusual way. The result can be that an implementation accesses a particular part of a packet, treating data of one type as data of another type. 1000 Category ChildOf 137 Reliance on data layout C C++ An integer overflow condition exists when an integer that has not been properly sanity checked is used in the determination of an offset or size for memory allocation, copying, concatenation, or similarly. If the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing an unintended value. Non-specific, memory management, counters Medium Availability: Integer overflows generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high. Integrity: If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the integer overflow has resulted in a buffer overflow condition, data corruption will most likely take place. Access control (instruction processing): Integer overflows can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy. Pre-design: Use a language or compiler that performs automatic bounds checking. Design: Use of sanity checks and assertions at the object level. Ensure that all protocols are strictly defined, such that all out of bounds behavior can be identified simply. Pre-design through Build: Canary style bounds checking, library changes which ensure the validity of chunk data, and other such fixes are possible but should not be relied upon. Use unsigned integers where possible The following code excerpt from OpenSSH 3.3 demonstrates a classic case of integer overflow: nresp; i++) response[i] = packet_get_string(NULL); }]]> If nresp has the value 1073741824 and sizeof(char*) has its typical value of 4, then the result of the operation nresp*sizeof(char*) overflows, and the argument to xmalloc() will be 0. Most malloc() implementations will happily allocate a 0-byte buffer, causing the subsequent loop iterations to overflow the heap buffer response. This example processes user input comprised of a series of variable-length structures. The first 2 bytes of input dictate the size of the structure to be processed. The programmer has set an upper bound on the structure size: if it is larger than 512, the input will not be processed. The problem is that len is a signed integer, so the check against the maximum structure length is done with signed integers, but len is converted to an unsigned integer for the call to memcpy(). If len is negative, then it will appear that the structure has an appropriate size (the if branch will be taken), but the amount of memory copied by memcpy() will be quite large, and the attacker will be able to overflow the stack with data in strm. Integer overflows can be complicated and difficult to detect. The following example is an attempt to show how an integer overflow may lead to undefined looping behavior: C In the above case, it is entirely possible that bytesRec may overflow, continuously creating a lower number than MAXGET and also overwriting the first MAXGET-1 bytes of buf. CVE-2002-0391 Integer overflow via a large number of arguments. CVE-2005-1141 Image with large width and height leads to integer overflow. CVE-2005-0102 Length value of -1 leads to allocation of 0 bytes and resultant heap overflow. CVE-2004-2013 Length value of -1 leads to allocation of 0 bytes and resultant heap overflow. Terminology Note: "integer overflow" is used to cover several types of errors, including signedness errors, or buffer overflows that involve manipulation of integer data types instead of characters. Part of the confusion results from the fact that 0xffffffff is -1 in a signed context. Integer overflows can be primary to buffer overflows. Yves Younan An overview of common programming security vulnerabilities and possible solutions Student thesis section 5.4.3 August 2003 http://fort-knox.org/thesis.pdf blexim Basic Integer Overflows Phrack - Issue 60, Chapter 10 http://www.phrack.org/archives/60/p60-0x0a.txt 1000 Category ChildOf 189 1000 680 Compound_Element CanPrecede 120 1000 Weakness CanPrecede 122 Integer overflow (wrap or wraparound) Integer Overflow Integer overflow Implementation 92 The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result. This can happen in signed and unsigned cases. "Integer underflow" is sometimes used to identify signedness errors in which an originally positive number becomes negative as a result of subtraction. However, there are cases of bad subtraction in which unsigned integers are involved, so it's not always a signedness issue. "Integer underflow" is occasionally used to describe array index errors in which the index is negative. CVE-2004-0816 Integer underflow in firewall via malformed packet. CVE-2004-1002 Integer underflow by packet with invalid length. CVE-2005-0199 Long input causes incorrect length calculation. CVE-2005-1891 Malformed icon causes integer underflow in loop counter variable. Under-studied. 1000 Weakness ChildOf 682 1000 Category ChildOf 189 Integer underflow (wrap or wraparound) C C++ Java .NET Implementation A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value. An "off-by-five" error was reported for sudo in 2002 (CVE-2002-0184), but that is more like a "length calculation" error. Resultant: can produce resultant buffer overflows CVE-2003-0466 CVE-2003-0252 CVE-2003-0625 CVE-2001-1391 CVE-2002-0083 CVE-2002-0653 CVE-2002-0844 CVE-1999-1568 CVE-2004-0346 CVE-2004-0005 CVE-2003-0356 CVE-2001-1496 CVE-2004-0342 This is an interesting example that might not be an off-by-one. CVE-2001-0609 An off-by-one enables a terminating null to be overwritten, which causes 2 strings to be merged and enable a format string. CVE-2002-1745 Off-by-one error allows source code disclosure of files with 4 letter extensions that match an accepted 3-letter extension. CVE-2002-1816 Off-by-one buffer overflow. CVE-2002-1721 Off-by-one error causes an snprintf call to overwrite a critical internal variable with a null value. CVE-2003-0466 Off-by-one error in function used in many products leads to a buffer overflow during pathname management, as demonstrated using multiple commands in an FTP server. CVE-2003-0625 Off-by-one error allows read of sensitive memory via a malformed request. CVE-2006-4574 Chain: security monitoring product has an off-by-one error that leads to unexpected length values, triggering an assertion. This is not always a buffer overflow. For example, an off-by-one error could be a factor in a partial comparison, a read from the wrong memory location, an incorrect conditional, etc. Under-studied. It requires careful code analysis or black box testing, where inputs of excessive length might not cause an error. Off-by-ones are likely triggered by extensive fuzzing, with the attendant diagnostic problems. Halvar Flake Third Generation Exploits presentation at Black Hat Europe 2001 http://www.blackhat.com/presentations/bh-europe-01/halvar-flake/bh-europe-01-halvarflake.ppt Steve Christey Off-by-one errors: a brief explanation Secprog and SC-L mailing list posts 2004-05-05 http://marc.theaimsgroup.com/?l=secprog&m=108379742110553&w=2 klog The Frame Pointer Overwrite Phrack Issue 55, Chapter 8 1999-09-09 http://kaizo.org/mirrors/phrack/phrack55/P55-08 G. Hoglund G. McGraw Exploiting Software: How to Break Code (The buffer overflow chapter) Addison-Wesley February 2004 1000 Weakness ChildOf 682 1000 Category ChildOf 189 1000 Weakness CanPrecede 617 1000 Weakness CanPrecede 170 Off-by-one Error All Implementation If one extends a signed number incorrectly, if negative numbers are used, an incorrect extension may result. High Integrity: If one attempts to sign extend a negative variable with an unsigned extension algorithm, it will produce an incorrect result. Authorization: Sign extension errors -- if they are used to collect information from smaller signed sources -- can often create buffer overflows and other memory based problems. Implementation: Use a sign extension library or standard function to extend signed numbers. Implementation: When extending signed numbers fill in the new bits with 0 if the sign bit is 0 or fill the new bits with 1 if the sign bit is 1. C Sign extension errors -- if they are used to collect information from smaller signed sources -- can often create buffer overflows and other memory based problems. 1000 Weakness ChildOf 682 1000 Category ChildOf 189 Sign extension error C C++ Java .NET Implementation A signed-to-unsigned conversion error takes place when a signed primitive is used as an unsigned value, usually as a size variable. Conversion between signed and unsigned values can lead to a variety of errors, but from a security standpoint is most commonly associated with integer overflow and buffer overflow vulnerabilities. In this example the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned int, amount will be implicitly converted to unsigned. If the error condition in the code above is met, then the return value of readdata() will be 4,294,967,295 on a system uses 32-bit integers. In this example, depending on the return value of accecssmainframe(), the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned value, amount will be implicitly cast to an unsigned number. If the return value of accessmainframe() is -1, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers. CVE-2007-4268 Chain: integer signedness passes signed comparison, leads to heap overflow It is dangerous to rely on implicit casts between signed and unsigned numbers because the result can take on an unexpected value and violate weak assumptions made elsewhere in the program. 1000 Weakness ChildOf 681 1000 Category ChildOf 189 1000 Weakness CanPrecede 122 Signed to unsigned conversion error C C++ Implementation An unsigned-to-signed conversion error takes place when a large unsigned primitive is used as a signed value. Medium Availability: Incorrect sign conversions generally lead to undefined behavior, and therefore crashes. Integrity: If a poor cast lead to a buffer overflow or similar condition, data integrity may be affected. Access control (instruction processing): Improper signed-to-unsigned conversions without proper checking can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy. Requirements specification: Choose a language which is not subject to these casting flaws. Design: Design object accessor functions to implicitly check values for valid sizes. Ensure that all functions which will be used as a size are checked previous to use as a size. If the language permits, throw exceptions rather than using in-band errors. Implementation: Error check the return values of all functions. Be aware of implicit casts made, and use unsigned variables for sizes if at all possible. In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed: If returnChunkSize() happens to encounter an error, and returns -1, memcpy will assume that the value is unsigned and therefore interpret it as MAXINT-1, therefore copying far more memory than is likely available in the destination buffer. Often, functions will return negative values to indicate a failure state. In the case of functions which return values which are meant to be used as sizes, negative return values can have unexpected results. If these values are passed to the standard memory copy or allocation functions, they will implicitly cast the negative error-indicating value to a large unsigned value. In the case of allocation, this may not be an issue; however, in the case of memory and string copy functions, this can lead to a buffer overflow condition which may be exploitable. Also, if the variables in question are used as indexes into a buffer, it may result in a buffer underflow condition. Although less frequent an issue than signed-to-unsigned casting, unsigned-to-signed casting can be the perfect precursor to dangerous buffer underwrite conditions that allow attackers to move down the stack where they otherwise might not have access in a normal buffer overflow condition. Buffer underwrites occur frequently when large unsigned values are cast to signed values, and then used as indexes into a buffer or for pointer arithmetic. 1000 Weakness ChildOf 681 1000 Category ChildOf 189 1000 Weakness CanAlsoBe 124 1000 Compound_Element CanAlsoBe 120 Unsigned to signed conversion error C C++ Implementation 92 Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion. Low Integrity: The true value of the data is lost and corrupted data is used. Implementation: Ensure that no casts, implicit or explicit, take place that move from a larger size primitive or a smaller size primitive. This example, while not exploitable, shows the possible mangling of values associated with truncation errors: int main() { int intPrimitive; short shortPrimitive; intPrimitive = (int)(~((int)0) ^ (1 << (sizeof(int)*8-1))); shortPrimitive = intPrimitive; printf("Int MAXINT: %d\nShort MAXINT: %d\n", intPrimitive, shortPrimitive); return (0); }]]> The above code, when compiled and run, returns the following output: Int MAXINT: 2147483647 Short MAXINT: -1 A frequent paradigm for such a problem being exploitable is when the truncated value is used as an array index, which can happen implicitly when 64-bit values are used as indexes, as they are truncated to 32 bits. When a primitive is cast to a smaller primitive, the high order bits of the large value are lost in the conversion, potentially resulting in an unexpected value that is not equal to the original value. This value may be required as an index into a buffer, a loop iterator, or simply necessary state data. In any case, the value cannot be trusted and the system will be in an undefined state. While this method may be employed viably to isolate the low bits of a value, this usage is rare, and truncation usually implies that an implementation error has occurred. Under-studied and under-reported. 1000 Weakness ChildOf 681 1000 Category ChildOf 189 1000 Weakness CanAlsoBe 195 1000 Weakness CanAlsoBe 196 1000 Category CanAlsoBe 192 1000 Weakness CanAlsoBe 194 Numeric truncation error Truncation error C C++ Java .NET Implementation The software mixes up the order in which bytes are processed (e.g. big-endian and little-endian), causing a wrong number to be used in a security-critical context. Under-reported, but probably not likely to occur frequently, as byte ordering bugs are usually very noticeable even with normal inputs. This bug is more likely to occur in rarely triggered error conditions. 1000 Weakness ChildOf 188 1000 Category ChildOf 189 Numeric Byte Ordering Error All The product has an absent or incorrect protection mechanism that fails to properly validate input that can affect the control flow or data flow of a program. One should validate input from untrusted sources before it is used. The untrusted data sources can be HTTP requests, file systems, databases, and any external systems that provide data to the application. In the case of HTTP requests, validate all parts of the request, including headers, form fields, cookies, and URL components that are used to transfer information from the browser to the server side application. Duplicate any client-side checks on the server side. This should be simple to implement in terms of time and difficulty, and will greatly reduce the likelihood of insecure parameter values being used in the application. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. In the context of web-applications it is particularly important to have adequate validation in place. Note that client-side checks should not be considered a secure means of validating parameters. These checks only help reduce the amount of server processing time for normal users who do not know the format of required input. It is a very minimal savings in terms of time. Attackers can bypass these mechanisms easily by intercepting parameters after the client-side checks and altering the values before they are submitted to the server. 1000 Category ChildOf 19 1000 Weakness ChildOf 693 635 View ChildOf 635 Input validation and representation 10 31 13 32 14 52 71 53 72 18 91 73 78 79 99 101 22 24 42 43 80 45 63 81 28 46 64 47 83 66 67 85 86 88 3 7 8 9 An information leak is the intentional or unintentional disclosure of information that either (1) is regarded as sensitive within the product's own functionality, such as a private message, or (2) provides information about the product or its environment that could be useful in an attack but is normally not available to the attacker, such as the installation path of a product that is remotely accessible. Many information leaks are resultant (e.g. path disclosure in PHP script error), but they can also be primary (e.g. timing discrepancies in crypto). There are many different types of problems that involve information leaks. Their severity can range widely depending on the type of information that is leaked. Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 1000 Category ChildOf 199 629 View ChildOf 629 635 View ChildOf 635 Information Leak (information disclosure) All 79 22 13 60 59 The accidental leaking of sensitive information through sent data refers to the transmission of data which are either sensitive in and of itself or useful in the further exploitation of the system through standard data channels. Confidentiality: Data leakage results in the compromise of data confidentiality. Requirements specification: Specify data output such that no sensitive data is sent. Implementation: Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. The following is an actual mysql error statement: SQL Accidental data leakage occurs in several places and can essentially be defined as unnecessary data leakage. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent. 1000 Weakness ChildOf 200 1000 Weakness CanAlsoBe 209 1000 Weakness CanAlsoBe 202 Accidental leaking of sensitive information through sent data All 12 When trying to keep information confidential, an attacker can often infer some of the information by using statistics. Medium Confidentiality: Sensitive information may possibly be leaked through data queries accidentally. This is a complex topic. See the book Translucent Databases for a good discussion of best practices. See the book Translucent Databases for examples. In situations where data should not be tied to individual users, but a large number of users should be able to make queries that "scrub" the identity of users, it may be possible to get information about a user -- e.g., by specifying search terms that are known to be unique to that user. 1000 Weakness ChildOf 200 Accidental leaking of sensitive information through data queries All A discrepancy information leak is an information leak in which the product behaves differently, or sends different responses, in a way that reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not. Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 1000 Weakness ChildOf 200 Discrepancy Information Leaks All A response discrepancy information leak occurs when the product sends different messages in direct response to an attacker's request, in a way that allows the attacker to learn about the inner state of the product. The leaks can be inadvertent (bug) or intentional (design). Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. CVE-2002-2094 This, and others, use ".." attacks and monitor error responses, so there is overlap with directory traversal. CVE-2001-1483 User enumeration by infoleak from inconsistent responses. CVE-2001-1528 Account number enumeration via inconsistent response infoleak. CVE-2004-2150 User enumeration via error message discrepancy infoleak. CVE-2005-1650 Infoleak by inconsistent responses. CVE-2004-0294 CVE-2004-0243 CVE-2002-0514 CVE-2002-0515 CVE-2001-1387 CVE-2004-0778 CVE-2004-1428 can overlap errors related to escalated privileges 1000 Weakness ChildOf 203 Response discrepancy infoleak All A behavioral discrepancy information leak occurs when the product's actions indicate important differences based on (1) the internal state of the product or (2) differences from other products in the same class. Attacks such as OS fingerprinting rely heavily on both behavioral and response discrepancies. Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 1000 Weakness ChildOf 203 Behavioral Discrepancy Infoleak All Two separate operations in a product cause the product to behave differently in a way that is observable to an attacker and reveals security-relevant information about the internal state of the product, such as whether a particular operation was successful or not. CVE-2002-2031 File existence via infoleak monitoring whether "onerror" handler fires or not. CVE-2005-2025 Valid groupname enumeration via behavioral infoleak (sends response if valid, doesn't respond if not). CVE-2001-1497 Behavioral infoleak in GUI allows attackers to distinguish between alphanumeric and non-alphanumeric characters in a password, thus reducing the search space. CVE-2003-0190 Product immediately sends an error message when user does not exist instead of waiting until the password is provided, allowing username enumeration. 1000 Weakness ChildOf 205 Internal behavioral inconsistency infoleak All The software behaves differently than other products like it, in a way that is observable to an attacker and reveals security-relevant information about which product is being used, or its operating state. CVE-2002-0208 Product modifies TCP/IP stack and ICMP error messages in unusual ways that show the product is in use. CVE-2004-2252 Behavioral infoleak by responding to SYN-FIN packets. CVE-2000-1142 Honeypot generates an error with a "pwd" command in a particular directory, allowing attacker to know they are in a honeypot system. 1000 Weakness ChildOf 205 External behavioral inconsistency infoleak All Two separate operations in a product require different amounts of time to complete, in a way that is observable to an attacker and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not. Cryptography, authentication CVE-2003-0078 CVE-2000-1117 CVE-2003-0637 CVE-2003-0190 CVE-2004-1602 CVE-2005-0918 Attack: Timing attack Often primary in cryptographic applications and algorithms. 1000 Weakness ChildOf 203 1000 Category CanAlsoBe 310 Timing discrepancy infoleak All The product includes sensitive information within an error message. High Confidentiality: Often this will either reveal sensitive information which may be used for a later attack or private information stored in the server. Design: When an application detects illegal input, error messages should only provide generic feedback, such as "Illegal characters were detected." Messages should provide few, if any, implementation details. Implementation: Any error should be parsed for dangerous revelations. Build: Debugging information should not make its way into a production release. Handle exceptions internally and do not display errors containing potentially sensitive information to a user. Create default error pages if necessary. Java Here you are passing much more data than is needed. Another example is passing the SQL exceptions to a WebUser without filtering. Error messages should not provide attackers with any implementation details when the application detects an illegal action. This includes indicating exactly what is allowable, or exactly what was illegal about the user input. Such detailed information can help an attacker craft another attack that now will pass through the validation filters. The first thing an attacker may use -- once an attack has failed -- to stage the next attack is the error information provided by the server. SQL Injection attacks generally probe the server for information in order to stage a successful attack. 1000 Weakness ChildOf 200 Accidental leaking of sensitive information through error messages All 54 7 Files, directories, and folders are so central to information technology that many different weaknesses and variants have been discovered. The manipulations generally involve special characters or sequences in pathnames, or the use of alternate references or channels. They can be used to access files outside of a restricted directory (path traversal or link following) or to access files that are otherwise protected (path equivalence). Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. 1000 Weakness ChildOf 20 Pathname Traversal and Equivalence Errors All 80 79 72 64 78 The software identifies an error condition and creates its own diagnostic or error messages that contain sensitive information. Non-specific Implementation: Any error should be parsed for dangerous revelations. Build: Debugging information should not make its way into a production release. Handle exceptions internally and do not display errors containing potentially sensitive information to a user. Create default error pages if necessary. CVE-2005-1745 Infoleak of sensitive information in error message (physical access required). Attack: trigger error, monitor responses. 1000 Weakness ChildOf 209 Product-Generated Error Message Infoleak All The software performs an operation that triggers a diagnostic or error message that is not under direct control of the product, e.g. an error generated by the programming language that the product uses. This is inherently a resultant vulnerability from a weakness within the product or an interaction error. It might be controllable by configuration, e.g. in PHP error messages. Non-specific Implementation: Any error should be parsed for dangerous revelations. Build: Debugging information should not make its way into a production release. Handle exceptions internally and do not display errors containing potentially sensitive information to a user. Create default error pages if necessary. CVE-2004-1581 CVE-2004-1579 CVE-2005-0459 CVE-2005-0443 CVE-2005-0433 CVE-2005-0326 CVE-2004-1101 VisualBasic Attack: trigger error, monitor responses. PHP applications are often targeted for having this issue when the PHP interpreter generates the error outside of the application's control. However, it's not just restricted to PHP, as other languages/environments exhibit the same issue. 1000 Weakness ChildOf 209 Product-External Error Message Infoleak All The software does not properly remove sensitive data from a source when preparing it for, or transferring it to, an untrusted destination. For example, an internal IP address might be discovered. This discloses information about the IP addressing scheme of the internal network and can be valuable to attackers. Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. CVE-2005-0406 Some image editors modify a JPEG image, but the original EXIF thumbnail image intact within the JPEG. (Also an interaction error). CVE-2002-0704 NAT feature in firewall leaks internal IP addresses in ICMP error messages. This entry is intended to be different from resultant information leaks, including those that occur from improper buffer initialization and reuse, interaction errors, and multiple interpretation errors. This entry could be regarded as a privacy leak. Some examples include features that export or copy documents without removing sensitive information such as edit history in a Word and PDF. 1000 Weakness ChildOf 200 Cross-Boundary Cleansing Infoleak All A product's design or configuration explicitly requires the publication of information that could be regarded as sensitive by an administrator. Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Consider what information might be regarded as sensitive by your product's users, even if it is not important for the safe operation of your system. CVE-2002-1725 Script calls phpinfo() CVE-2004-0033 Script calls phpinfo() CVE-2003-1181 Script calls phpinfo() CVE-2004-1422 Script calls phpinfo() CVE-2004-1590 Script calls phpinfo() CVE-2003-1038 Product lists DLLs and full pathnames. CVE-2005-1205 Telnet protocol allows servers to obtain sensitive environment information from clients. CVE-2005-0488 Telnet protocol allows servers to obtain sensitive environment information from clients. This overlaps other categories, but it is distinct from the error message infoleaks. It's not always clear whether an infoleak is intentional or not. For example, CVE-2005-3261 identifies a PHP script that lists file versions, but it could be that the developer did not intend for this information to be public, but introduced a direct request issue instead. In vulnerability theory terms, this covers cases in which the developer's Intended Policy allows the information to be made available, but the information might be in violation of a Universal Policy in which the product's administrator should have control over which 1000 Weakness ChildOf 200 Intended information leak All Certain information about a process could be obtained from other processes within the operating system, including arguments and environment variables. This can be an externally controlled infoleak, but some protective mechanisms may exist that could make it internally controlled. System Process Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. CVE-2005-1387 password passed on command line CVE-2005-2291 password passed on command line CVE-2001-1565 username/password on command line allows local users to view via "ps" or other process listing programs CVE-2004-1948 Username/password on command line allows local users to view via "ps" or other process listing programs. CVE-1999-1270 PGP passphrase provided as command line argument. CVE-2004-1058 Kernel race condition allows reading of environment variables of a process that is still spawning. Under-studied, especially environment variables. 1000 Weakness ChildOf 200 631 Category ChildOf 634 Process information infoleak to other processes All The application contains debugging code that can leak sensitive information to untrusted parties. Do not leave debug statements that could be executed in the source code. Assure that all debug information is eradicated before releasing the software. Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. CVE-2004-2268 Debug information infoleak of password. CVE-2002-0918 CGI script includes sensitive information in debug messages when an error is triggered. CVE-2003-1078 FTP client with debug option enabled shows password to the screen. This overlaps other categories. 1000 Weakness ChildOf 200 Infoleak Using Debug Information All This tries to cover various problems in which improper data are included within a "container." Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. This overlaps many other weaknesses. Most vulnerabilities could be regarded as "container" problems. 1000 Category ChildOf 199 Containment errors (container errors) All Data should be protected from direct modification. Containment error, container error Medium Integrity: The object could be tampered with. Design through Implementation: Use private members, and class accessor methods to their full benefit. This is the recommended mitigation. Make all public members private, and -- if external access is necessary-- use accessor functions to do input validation on all values. Implementation: Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access and preventing tampering. Implementation: Use sealed classes. Using sealed classes protects object oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways. Implementation: Use class accessor methods to their full benefit. Use the accessor functions to do input validation on all values intended for private values. C++ Java C C++ Java One of the main advantages of object-oriented code is the ability to limit access to fields and other resources by way of accessor functions. Utilize accessor functions to make sure your objects are well-formed. Final provides security by only allowing non-mutable objects to be changed after being set. However, only objects which are not extended can be made final. 1000 Weakness ChildOf 216 Failure to protect stored data from modification ACC - Sensitive Entity in Accessible Container All 69 Non-final public fields should be avoided, if possible, as the code is easily temperable. Containment error, container error High Integrity: The object could potentially be tampered with. Confidentiality: The object could potentially allow the object to be read. Implementation: Make any non-final field private. C++ Java Now this field is readable from any function and can be changed by any function. If a field is non-final and public, it can be changed once their value is set by any function which has access to the class which contains the field. 1000 Weakness ChildOf 216 Failure to provide confidentiality for stored data ACC - Sensitive Entity in Accessible Container All The application stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties. Avoid storing information under the web root directory. Access control permissions should be set to prevent reading/writing of sensitive files inside/outside of the web directory. CVE-2005-1835 Data file under web root. CVE-2005-2217 Data file under web root. CVE-2002-1449 Username/password in data file under web root. CVE-2002-0943 Database file under web root. CVE-2005-1645 database file under web root. 1000 Weakness ChildOf 216 Sensitive Data Under Web Root All System Configuration Architecture and Design Installation The software, when constructing file or directory names from input, does not properly sanitize special character sequences that resolve to a file or directory name that is outside of the intended directory or directories. Directory traversal "Path traversal" is preferred over "directory traversal." Like other Weaknesses, terminology is often based on the types of manipulations used, instead of the underlying Weaknesses. Some people use "directory traversal" only to refer to the injection of ".." and equivalent sequences whose specific meaning is to traverse directories. Other variants like "absolute pathname" and "drive letter" have the *effect* of directory traversal, but some people may not call it such, since it doesn't involve ".." or equivalent. File processing Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) File/Directory Assume all input is malicious. Attackers can insert paths into input vectors and traverse the file system. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Warning: if you attempt to cleanse your data, then do so that the end result is not in the form that can be dangerous. A sanitizing mechanism can remove characters such as ‘.' and ‘;' which may be required for some exploits. An attacker can try to fool the sanitizing mechanism into "cleaning" data into a dangerous form. Suppose the attacker injects a ‘.' inside a filename (e.g. "sensi.tiveFile") and the sanitizing mechanism removes the character resulting in the valid filename, "sensitiveFile". If the input data are now assumed to be safe, then the file may be compromised. Pathname equivalence can be regarded as a type of canonicalization error. Some pathname equivalence issues are not directly related to directory traversal, rather are used to bypass security-relevant checks for whether a file/directory can be accessed by the attacker (e.g. a trailing "/" on a filename could bypass access rules that don't expect a trailing /, causing a server to provide the file when it normally would not). Incomplete diagnosis or reporting of vulnerabilities can make it difficult to know which variant is affected. For example, a researcher might say that "..\" is vulnerable, but not test "../" which may also be vulnerable. Any combination of the items below can provide its own variant, e.g. "//../" is not listed (CVE-2004-0325). Most of these issues are probably under-studied 1000 Weakness ChildOf 21 1000 Weakness ChildOf 610 629 View ChildOf 629 631 Category ChildOf 632 635 View ChildOf 635 Path Traversal All 76 23 The application stores sensitive data under the FTP document root with insufficient access control, which might make it accessible to untrusted parties. Avoid storing information under the FTP root directory. Access control permissions should be set to prevent reading/writing of sensitive files inside/outside of the FTP directory. Various Unix FTP servers require a password file that is under the FTP root, due to use of chroot. 1000 Weakness ChildOf 216 Sensitive Data Under FTP Root All System Configuration Architecture and Design Installation The software does not record, or improperly records, security-relevant information that leads to an incorrect decision or hampers later analysis. This can be resultant, e.g. a buffer overflow might trigger a crash before the product can log the event. 1000 Category ChildOf 199 Information loss or omission All 81 The application truncates the display, recording, or processing of security-relevant information in a way that can obscure the source or nature of an attack. CVE-2005-0585 Web browser truncates long sub-domains or paths, facilitating phishing. CVE-2004-2032 Bypass URL filter via a long URL with a large number of trailing hex-encoded space characters. CVE-2003-0412 Does not log complete URI of a long request (truncation). 1000 Weakness ChildOf 221 Truncation of Security-relevant Information All The application does not record or display information that would be important for identifying the source or nature of an attack, or determining if an action is safe. CVE-1999-1029 Login attempts not recorded if user disconnects before maximum number of tries. CVE-2002-1839 Sender's IP address not recorded in outgoing e-mail. CVE-2000-0542 Failed authentication attempt not recorded if later attempt succeeds. 1000 Weakness ChildOf 221 Omission of Security-relevant Information All The software records security-relevant information according to an alternate name of the affected entity, instead of the canonical name. Avoid making decisions based on names of resources if those resources can have alternate names. CVE-2002-0725 Attacker performs malicious actions on a hard link to a file, obscuring the real target file. M. Howard D. LeBlanc Writing Secure Code 2nd Edition Microsoft 2003 1000 Weakness ChildOf 221 Obscured Security-relevant Information by Alternate Name All This weakness can be found at CWE-199. 604 View ChildOf 604 The software does not fully clear previously used information in a data structure, file, or other resource, before making that resource available to a party in another control sphere. Non-specific, memory management, networking. Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Memory CVE-2003-0001 Ethernet NIC drivers do not pad frames with null bytes, leading to infoleak from malformed packets. CVE-2003-0291 router does not clear information from DHCP packets that have been previously used CVE-2005-1406 Products do not fully clear memory buffers when less data is stored into the buffer than previous. CVE-2005-1858 Products do not fully clear memory buffers when less data is stored into the buffer than previous. CVE-2005-3180 Products do not fully clear memory buffers when less data is stored into the buffer than previous. CVE-2005-3276 Product does not clear a data structure before writing to part of it, yielding information leak of previously used memory. CVE-2002-2077 Memory not properly cleared before reuse. This typically involves memory in which the new data are not as long as the old data, which leaves portions of the old data still available ("memory disclosure"). However, equivalent errors can occur in other situations where the length of data is variable but the associated data structure is not. Can overlap cryptographic errors, cross-boundary cleansing infoleaks. Currently frequently found for network packets, but it can also exist in local memory allocation, files, etc. 1000 Weakness ChildOf 200 1000 Category CanAlsoBe 310 1000 Weakness CanAlsoBe 212 631 Category ChildOf 633 Sensitive Information Uncleared Before Use All The software uses an API in a manner contrary to its intended use. An API is a contract between a caller and a callee. The most common forms of API misuse are caused by the caller failing to honor its end of this contract. For example, if a program fails to call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller misuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated. API Abuse Always utilize APIs in the specified manner. CVE-2006-7140 crypto implementation removes padding when they shouldn't, allowing forged signatures CVE-2006-4339 crypto implementation removes padding when they shouldn't, allowing forged signatures 1000 Category ChildOf 18 API Abuse 96 Weaknesses in this category are related to improper handling of data that is invalid and/or improperly structured. 1000 Category ChildOf 137 Structure and Validity Problems Weaknesses in this category are related to improper handling of values that are associated with parameters, fields, or arguments. 1000 Weakness ChildOf 228 The software, when constructing file or directory names from input, does not properly sanitize sequences such as ".." that resolve to a file or directory name that is outside of the intended directory. see the vulnerability category "Path Traversal" 1000 Weakness ChildOf 22 Relative Path Traversal All 76 23 The software does not handle when a parameter, field, or argument name is specified, but the associated value is missing, i.e. it is empty, blank, or null. CVE-2002-0422 Blank Host header triggers resultant infoleak. CVE-2000-1006 Blank "charset" attribute in MIME header triggers crash. CVE-2004-1504 Blank parameter causes external error infoleak. CVE-2005-2053 Blank parameter causes external error infoleak. Some "crash by port scan" bugs are probably due to this, but lack of diagnosis makes it difficult to be certain. 1000 Weakness ChildOf 229 Missing Value Error All The software does not handle when more values are specified than expected. This typically occurs in situations when only one value is expected. This can overlap buffer overflows. 1000 Weakness ChildOf 229 1000 Compound_Element CanAlsoBe 120 Extra Value Error All The software does not handle when a value is not defined or supported for the associated parameter, field, or argument name. CVE-2000-1003 Client crash when server returns unknown driver type. 1000 Weakness ChildOf 229 Undefined Value Error All Weaknesses in this category are related to improper handling of parameters, fields, or arguments. 1000 Weakness ChildOf 228 Parameter Problems 39 If too few arguments are sent to a function, the function will still pop the expected number of arguments from the stack. Potentially, a variable number of arguments could be exhausted in a function as well. High Authorization: There is the potential for arbitrary code execution with privileges of the vulnerable program if function parameter list is exhausted. Availability: Potentially a program could fail if it needs more arguments then are available. Implementation: Forward declare all functions. This is the recommended solution. Properly forward declaration of all used functions will result in a compiler error if too few arguments are sent to a function. C C++ C C++ This can be exploited to disclose information with no work whatsoever. In fact, each time this function is run, it will print out the next 4 bytes on the stack after the two numbers sent to it. CVE-2004-0276 CVE-2002-1488 CVE-2002-1169 CVE-2000-0521 CVE-2001-0590 CVE-2002-1236 CVE-2003-0239 CVE-2003-0477 CVE-2003-0422 CVE-2002-1531 CVE-2002-1077 CVE-2002-1358 CVE-2002-1023 CVE-2002-1236 CGI crashes when called without any arguments. CVE-2003-0422 CGI crashes when called without any arguments. CVE-2002-1531 Crash in HTTP request without a Content-Length field. CVE-2002-1077 Crash in HTTP request without a Content-Length field. CVE-2002-1358 Empty elements/strings in protocol test suite affect many SSH2 servers/clients. CVE-2003-0477 FTP server crashes in PORT command without an argument. CVE-2002-0107 Resultant infoleak in web server via GET requests without HTTP/1.0 version string. CVE-2002-0596 GET request with empty parameter leads to error message infoleak (path disclosure). This issue can be simply combated with the use of proper build process. 1000 Weakness ChildOf 233 Missing Parameter Error Missing parameter All The software does not handle when a particular parameter, field, or argument name is specified two or more times. CVE-2003-1014 MIE. multiple gateway/security products allow restriction bypass using multiple MIME fields with the same name, which are interpreted differently by clients. This typically occurs in situations when only one element is expected to be specified. This type of problem has a big role in multiple interpretation vulnerabilities and various HTTP attacks. 1000 Weakness ChildOf 233 Extra Parameter Error All The software does not handle when a particular parameter, field, or argument name is not defined or supported by the product. CVE-2001-0650 CVE-2002-1488 Crash in IRC client via PART message from a channel the user is not in. CVE-2001-0650 Router crash or bad route modification using BGP updates with invalid transitive attribute. 1000 Weakness ChildOf 233 Undefined Parameter Error All Weaknesses in this category are caused by improper handling of complex structures. 1000 Weakness ChildOf 228 Element Problems The software improperly handles the situation where an expected element is not provided. Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Can overlap other problems. 1000 Weakness ChildOf 237 Missing Element Error All The application does not properly handle when a particular element is not completely specified. CVE-2002-1532 CVE-2003-0195 CVE-2002-1532 HTTP GET without \r\n\r\n CRLF sequences causes product to wait indefinitely and prevents other users from accessing it. CVE-2003-0195 Partial request is not timed out. CVE-2005-2526 MFV. CPU exhaustion in printer via partial printing request then early termination of connection. CVE-2002-1906 CPU consumption by sending incomplete HTTP requests and leaving the connections open. 1000 Weakness ChildOf 237 1000 Weakness PeerOf 404 Incomplete Element All A software system that accepts input in the form of dot dot slash ('../') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. Note that '..' is ignored if the current working directory is the root directory. see the vulnerability category "Path Traversal" 1000 Weakness ChildOf 23 '../filedir All The software does not handle when multiple parameters, fields, arguments, or values should be consistent, but are not. This can overlap other weaknesses such as Length Parameter Inconsistency. 1000 Weakness ChildOf 237 1000 Weakness CanAlsoBe 130 Inconsistent Elements All The application does not properly handle when a particular element is of the wrong type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z). Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. CVE-1999-1156 FTP server crash via PORT command with non-numeric character. CVE-2004-0270 Anti-virus product has assert error when line length is non-numeric. Probably under-studied. 1000 Weakness ChildOf 228 Wrong Data Type All 48 The program calls a function that can never be guaranteed to work safely. High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account. The gets() function is unsafe because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to gets() and overflow the destination buffer. The > operator is unsafe to use when reading into a character buffer because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to the > operator and overflow the destination buffer. 1000 Category ChildOf 18 Dangerous Functions C C++ Implementation When a product uses the chroot() system call to create a jail, but does not change the working directory afterward, this might allow attackers to access files outside of the jail. High Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) File/Directory Example: Consider the following source code from a (hypothetical) FTP server: This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server fails to change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file. The chroot() system call allows a process to change its perception of the root directory of the file system. After properly invoking chroot(), a process cannot access any files outside the directory tree defined by the new root directory. Such an environment is called a chroot jail and is commonly used to prevent the possibility that a processes could be subverted and used to access unauthorized files. For instance, many FTP servers run in chroot jails to prevent an attacker who discovers a new vulnerability in the server from being able to download the password file or other sensitive files on the system. Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called. 1000 Weakness ChildOf 573 1000 Weakness ChildOf 669 631 Category ChildOf 632 Directory Restriction C C++ Implementation Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory. Memory The following code calls realloc() on a buffer containing sensitive data: There is an attempt to scrub the sensitive data from memory, but realloc() is used, so a copy of the data can still be exposed in the memory originally allocated for cleartext_buffer. Heap inspection vulnerabilities occur when sensitive data, such as a password or an encryption key, can be exposed to an attacker because they are not removed from memory. The realloc() function is commonly used to increase the size of a block of allocated memory. This operation often requires copying the contents of the old memory block into a new and larger block. This operation leaves the contents of the original block intact but inaccessible to the program, preventing the program from being able to scrub sensitive data from memory. If an attacker can later examine the contents of a memory dump, the sensitive data could be exposed. Be careful using {vfork, fork} in security sensitive code. The process state will not be cleaned up and will contain traces of data from past use. 1000 Weakness ChildOf 404 1000 Weakness ChildOf 669 630 View ChildOf 630 631 Category ChildOf 633 Heap Inspection C C++ Implementation The J2EE application directly manages connections, instead of using the container's connection management facilities. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) The J2EE standard forbids the direct management of connections. It requires that applications use the container's resource management facilities to obtain connections to resources. For example, a J2EE application should obtain a database connection as follows: ctx = new InitialContext(); datasource = (DataSource)ctx.lookup(DB_DATASRC_REF); conn = datasource.getConnection(); and should avoid obtaining a connection in this way: conn = DriverManager.getConnection(CONNECT_STRING); Every major web application container provides pooled database connection management as part of its resource management framework. Duplicating this functionality in an application is difficult and error prone, which is part of the reason it is forbidden under the J2EE standard. 1000 Weakness ChildOf 573 J2EE Bad Practices: getConnection() Java The J2EE application directly uses sockets instead of using framework method calls. Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Use framework method calls instead of using sockets directly. The J2EE standard permits the use of sockets only for the purpose of communication with legacy systems when no higher-level protocol is available. Authoring your own communication protocol requires wrestling with difficult security issues, including: - In-band versus out-of-band signaling - Compatibility between protocol versions - Channel security - Error handling - Network constraints (firewalls) - Session management Without significant scrutiny by a security expert, chances are good that a custom communication protocol will suffer from security problems. Many of the same issues apply to a custom implementation of a standard protocol. While there are usually more resources available that address security concerns related to implementing a standard protocol, these resources are also available to attackers. 1000 Weakness ChildOf 573 J2EE Bad Practices: Sockets Java Attackers can spoof DNS entries. Do not rely on DNS names for security. The following code sample uses a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status. IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication. Many DNS servers are susceptible to spoofing attacks, so you should assume that your software will someday run in an environment with a compromised DNS server. If attackers are allowed to make DNS updates (sometimes called DNS cache poisoning), they can route your network traffic through their machines or make it appear as if their IP addresses are part of your domain. Do not base the security of your system on DNS names. 1000 Weakness ChildOf 345 1000 Weakness PeerOf 290 Often Misused: Authentication All 89 Failing to catch an exception thrown from a dangerous function can potentially cause the program to crash. The _alloca() function allocates memory on the stack. If an allocation request is too large for the available stack space, _alloca() throws an exception. If the exception is not caught, the program will crash, potentially enabling a denial of service attack. _alloca() has been deprecated as of Microsoft Visual Studio 2005®. It has been replaced with the more secure _alloca_s(). EnterCriticalSection() can raise an exception, potentially causing the program to crash. Under operating systems prior to Windows 2000, the EnterCriticalSection() function can raise an exception in low memory situations. If the exception is not caught, the program will crash, potentially enabling a denial of service attack. 1000 Category ChildOf 389 1000 Weakness ChildOf 691 Often Misused: Exception Handling C C++ Java .NET 54 Passing an inadequately-sized output buffer to a path manipulation function can result in a buffer overflow. Memory File/Directory Always specify output buffers large enough to handle the maximum-size possible result from path manipulation functions. The C standard library function realpath() takes two arguments. The first argument specifies a filename to be converted to canonical form. The second argument specifies an output buffer. Regardless of the length of the canonicalized file name, realpath() will not write more than PATH_MAX bytes to the output buffer. Some programmers incorrectly assume that, by allocating a buffer of size PATH_MAX, there will always be enough room in the buffer to hold any file name that might be found on the system. However, PATH_MAX only bounds the longest possible relative path that can be passed to the kernel in a single call. On most Unix and Linux systems, there is no easily-determined maximum length for a path. In this example the function creates a directory named "output\<name>" in the current directory and returns a heap-allocated copy of its name. For most values of the current directory and the name parameter, this function will work properly. However, if the name parameter is particularly long, then the second call to PathAppend() could overflow the outputDirectoryName buffer, which is smaller than MAX_PATH bytes. Windows provides a large number of utility functions that manipulate buffers containing filenames. In most cases, the result is returned in a buffer that is passed in as input. (Usually the filename is modified in place.) Most functions require the buffer to be at least MAX_PATH bytes in length, but you should check the documentation for each function individually. If the buffer is not large enough to store the result of the manipulation, a buffer overflow can occur. 1000 Compound_Element ChildOf 120 631 Category ChildOf 632 631 Category ChildOf 633 Often Misused: File System C C++ A software system that accepts input in the form of a leading dot dot slash ('/../filedir') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. Note that '..' is ignored if the current working directory is the root directory. see the vulnerability category "Path Traversal" 1000 Weakness ChildOf 23 '/../filedir All Failure to adhere to the principle of least privilege amplifies the risk posed by other weaknesses. This weakness refers to cases in which an application grants greater access rights than necessary. Depending on the level of access granted, this may allow a user to access confidential information. For example, programs that run with root privileges have caused innumerable Unix security disasters. It is imperative that you carefully review privileged programs for all kinds of security problems, but it is equally important that privileged programs drop back to an unprivileged state as quickly as possible in order to limit the amount of damage that an overlooked vulnerability might be able to cause. Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another. Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges. An attacker may be able to leverage these elevated privileges to do further damage. To grant the minimum access level necessary, first identify the different permissions that an application or user of that application will need to perform their actions, such as file read and write permissions, network socket permissions, and so forth. Then explicitly allow those actions while denying all else. If an application has this design problem, then it can be easier for the developer to make implementation-related errors such as CWE-271 (Privilege Dropping / Lowering Errors). In addition, the consequences of Privilege Chaining (CWE-268) can become more severe. There is a close association with CWE-653 (Insufficient Separation of Privileges). CWE-653 is about providing separate components for each privilege; CWE-250 is about ensuring that each component has the least amount of privileges possible. Jerome H. Saltzer 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 Michael Gegick Least Privilege 2005-09-14 https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html 1000 Weakness ChildOf 657 1000 Category ChildOf 264 1000 Weakness PeerOf 271 1000 Category PeerOf 265 Often Misused: Privilege Management All Architecture and Design 69 Ignoring a method's return value can cause the program to overlook unexpected states and conditions. Low Integrity: The data which were produced as a result of a function could be in a bad state. Implementation: Check all functions which return a value. Implementation: When designing any function make sure you return a value or throw an exception in case of an error. Example 1: Consider the following code: The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy(). Example 2: The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc(). The traditional defense of this coding error is: "If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations: - Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue. - It is impossible for the program to perform a graceful exit if required. If the program is performing an atomic operation, it can leave the system in an inconsistent state. - The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know. Example 3: The following code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and handle it as though it belongs to the attacker. Example 4: The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference. The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved. Example 5: The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined. The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved. Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break. Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions. Important and common functions will return some value about the success of its actions. This will alert the program whether or not to handle any errors caused by that function. It is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. Most errors and unusual events in .NET result in an exception being thrown. (This is one of the advantages that .NET has over languages like C: Exceptions make it easier for programmers to think about what can go wrong.) But the stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested. This behavior makes it important for programmers to examine the return value from Read() and other IO methods and ensure that they receive the amount of data they expect. It is not uncommon for Java programmers to misunderstand read() and related methods that are part of many java.io classes. Most errors and unusual events in Java result in an exception being thrown. (This is one of the advantages that Java has over languages like C: Exceptions make it easier for programmers to think about what can go wrong.) But the stream and reader classes do not consider it unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested. This behavior makes it important for programmers to examine the return value from read() and other IO methods to ensure that they receive the amount of data they expect. 1000 Category ChildOf 389 1000 690 Weakness CanPrecede 476 Unchecked Return Value Ignored function return value All Implementation If a function's return value is not properly checked, the function could have failed without proper acknowledgement. Low Integrity: The data -- which were produced as a result of an improperly checked return value of a function -- could be in a bad state. Requirements specification: Use a language or compiler that uses exceptions and requires the catching of those exceptions. Implementation: Properly check all functions which return a value. Implementation: When designing any function make sure you return a value or throw an exception in case of an error. C C++ Important and common functions will return some value about the success of its actions. This will alert the program whether or not to handle any errors caused by that function. 1000 Weakness ChildOf 573 1000 Category ChildOf 389 Misinterpreted function return value All Implementation Storing a password in plaintext may result in a system compromise. Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Avoid storing passwords in easily accessible locations. Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext. The following code reads a password from a properties file and uses the password to connect to a database. This code will run successfully, but anyone who has access to config.properties can read the value of password. If a devious employee has access to this information, they can use it to break into the system. The following code reads a password from the registry and uses the password to create a new network credential. This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password. If a devious employee has access to this information, they can use it to break into the system Password management issues occur when a password is stored in plaintext in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password. Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource. Developers sometimes believe that they cannot defend the application from someone who has access to the configuration, but this attitude makes an attacker's job easier. Good password management guidelines require that a password never be stored in plaintext. J. Viega G. McGraw Building Secure Software: How to Avoid Security Problems the Right Way 2002 1000 Weakness ChildOf 522 Password Management All Architecture and Design The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. If a system administrator can recover the password directly -- or use a brute force search on the information available to him --, he can use the password on other accounts. Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Confidentiality: User's passwords may be revealed. Authentication: Revealed passwords may be reused elsewhere to impersonate the users in question. Design / Implementation: Ensure that strong, non-reversible encryption is used to protect stored passwords. C C++ Java The use of recoverable passwords significantly increases the chance that passwords will be used maliciously. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plain-text passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. 1000 Weakness ChildOf 522 1000 Weakness PeerOf 259 Storing passwords in a recoverable format All Architecture and Design 49 Using an empty string as a password is insecure. Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Passwords should be at least eight characters long -- the longer the better. Avoid passwords that are in any way similar to other passwords you have. Avoid using words that may be found in a dictionary, names book, on a map, etc. Consider incorporating numbers and/or punctuation into your password. If you do use common words, consider replacing letters in that word with numbers and punctuation. However, do not use "similar-looking" punctuation. For example, it is not a good idea to change cat to c@t, ca+, (@+, or anything similar. It is never appropriate to use an empty string as a password. It is too easy to guess. J. Viega G. McGraw Building Secure Software: How to Avoid Security Problems the Right Way 2002 1000 Category ChildOf 255 1000 Weakness ChildOf 260 1000 Weakness ChildOf 521 Password Management: Empty Password in Configuration File All Hard coded passwords may compromise system security in a way that cannot be easily remedied. It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. Once the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system will be forced to choose between security and availability. Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Authentication: If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question. Design (for default accounts): Rather than hard code a default username and password for first time logins, utilize a "first login" mode which requires the user to enter a unique strong password. Design (for front-end to back-end connections): Three solutions are possible, although none are complete. The first suggestion involves the use of generated passwords which are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals. Next, the passwords used should be limited at the back end to only performing actions valid to for the front end, as opposed to having full access. Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay style attacks. The following code uses a hardcoded password to connect to a database: This code will run successfully, but anyone who has access to it will have access to the password. Once the program has shipped, there is no going back from the database user "scott" with a password of "tiger" unless the program is patched. A devious employee with access to this information can use it to break into the system. Even worse, if attackers have access to the bytecode for application, they can use the javap -c command to access the disassembled code, which will contain the values of the passwords used. The result of this operation might look something like the following for the example above: javap -c ConnMngr.class 22: ldc #36; //String jdbc:mysql://ixne.com/rxsql 24: ldc #38; //String scott 26: ldc #17; //String tiger C C++ Java Every instance of this program can be placed into diagnostic mode with the same password. Even worse is the fact that if this program is distributed as a binary-only distribution, it is very difficult to change that password or disable this "functionality." The use of a hard-coded password has many negative implications -- the most significant of these being a failure of authentication measures under certain circumstances. On many systems, a default administration account exists which is set to a simple default password which is hard-coded into the program or device. This hard-coded password is the same for each device or system of this type and often is not changed or disabled by end users. If a malicious user comes across a device of this kind, it is a simple matter of looking up the default password (which is freely available and public on the internet) and logging in with complete access. In systems that authenticate with a back-end service, hard-coded passwords within closed source or drop-in solution systems require that the back-end service use a password which can be easily discovered. Client-side systems with hard-coded passwords pose even more of a threat, since the extraction of a password from a binary is usually very simple. 1000 Category ChildOf 255 1000 Weakness ChildOf 344 1000 Weakness ChildOf 671 1000 Weakness PeerOf 321 1000 Weakness PeerOf 257 630 View ChildOf 630 Password Management: Hard-Coded Password Use of hard-coded password All Architecture and Design A software system that accepts input in the form of a leading directory dot dot slash ('/directory/../filename') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. see the vulnerability category "Path Traversal" 1000 Weakness ChildOf 23 '/directory/../filename All Storing a password in a configuration file may result in system compromise. An attacker could gain access to this file and learn the stored password or worse yet, change the password to one of their choosing. File/Directory Avoid storing passwords in easily accessible locations. Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext. J. Viega G. McGraw Building Secure Software: How to Avoid Security Problems the Right Way 2002 1000 Weakness ChildOf 522 631 Category ChildOf 632 Password Management: Password in Configuration File All Obscuring a password with a trivial encoding does not protect the password. Passwords should be encrypted with keys that are at least 128 bits in length for adequate security. The following code reads a password from a properties file and uses the password to connect to a database. This code will run successfully, but anyone with access to config.properties can read the value of password and easily determine that the value has been base 64 encoded. If a devious employee has access to this information, they can use it to break into the system. The following code reads a password from the registry and uses the password to create a new network credential. This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password. If a devious employee has access to this information, they can use it to break into the system. Password management issues occur when a password is stored in plaintext in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password. The "crypt" family of functions uses weak cryptographic algorithms and should be avoided. It may be present in some projects for compatibility. J. Viega G. McGraw Building Secure Software: How to Avoid Security Problems the Right Way 2002 1000 Category ChildOf 255 1000 Weakness ChildOf 326 Password Management: Weak Cryptography All Architecture and Design 55 If no mechanism is in place for managing password aging, users will have no incentive to update passwords in a timely manner. Very Low Authentication: As passwords age, the probability that they are compromised grows. Design: Ensure that password aging functionality is added to the design of the system, including an alert previous to the time the password is considered obsolete, and useful information for the user concerning the importance of password renewal, and the method. A common example is not having a system to terminate old employee accounts. Not having a system for enforcing the changing of passwords every certain period. The recommendation that users change their passwords regularly and do not reuse passwords is universal among security experts. In order to enforce this, it is useful to have a mechanism that notifies users when passwords are considered old and that requests that they replace them with new, strong passwords. In order for this functionality to be useful, however, it must be accompanied with documentation which stresses how important this practice is and which makes the entire process as simple as possible for the user. 1000 Weakness ChildOf 404 1000 Weakness ChildOf 693 1000 Category ChildOf 255 1000 Weakness PeerOf 309 1000 Weakness PeerOf 263 1000 Weakness PeerOf 324 Not allowing password aging All Architecture and Design 55 49 70 16 Allowing password aging to occur unchecked can result in the possibility of diminished password integrity. Very Low Authentication: As passwords age, the probability that they are compromised grows. Design: Ensure that password aging is limited so that there is a defined maximum age for passwords and so that the user is notified several times leading up to the password expiration. A common example is not having a system to terminate old employee accounts. Not having a system for enforcing the changing of passwords every certain period. Just as neglecting to include functionality for the management of password aging is dangerous, so is allowing password aging to continue unchecked. Passwords must be given a maximum life span, after which a user is required to update with a new and different password. 1000 Weakness ChildOf 404 1000 Category ChildOf 255 1000 Weakness PeerOf 262 Allowing password aging All Architecture and Design 55 49 70 16 A product incorrectly assigns a privilege to a particular entity. Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) System Process Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Follow the principle of least privilege when assigning access rights to entities in a software system. Evidence of privilege change: C Java CVE-1999-1193 untrusted user placed in unix "wheel" group CVE-2005-2741 Product allows users to grant themselves certain rights that can be used to escalate privileges. CVE-2005-2496 Product uses group ID of a user instead of the group, causing it to run with different privileges. This is resultant from some other unknown issue. CVE-2004-0274 Product mistakenly assigns a particular status to an entity, leading to increased privileges. 1000 Category ChildOf 265 1000 Weakness CanAlsoBe 286 631 Category ChildOf 634 Incorrect Privilege Assignment All A particular privilege, role, capability, or right can be used to perform unsafe actions that were not intended, even when it is assigned to the correct entity. Note: there are 2 separate sub-categories here: - privilege incorrectly allows entities to perform certain actions - object is incorrectly accessible to entities with a given privilege This overlaps authorization and access control problems. Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Follow the principle of least privilege when assigning access rights to entities in a software system. CVE-2002-1981 Roles have access to dangerous procedures (Accessible entities). CVE-2002-1671 Untrusted object/method gets access to clipboard (Accessible entities). CVE-2004-2204 Gain privileges using functions/tags that should be restricted (Accessible entities). CVE-2000-0315 Traceroute program allows unprivileged users to modify source address of packet (Accessible entities). CVE-2004-0380 Bypass domain restrictions using a particular file that references unsafe URI schemes (Accessible entities). CVE-2002-1154 Script does not restrict access to an update command, leading to resultant disk consumption and filled error logs (Accessible entities). CVE-2002-1145 "public" database user can use stored procedure to modify data controlled by the database owner (Unsafe privileged actions). CVE-2000-0506 User with capability can prevent setuid program from dropping privileges (Unsafe privileged actions). CVE-2002-2042 Allows attachment to and modification of privileged processes (Unsafe privileged actions). CVE-2000-1212 User with privilege can edit raw underlying object using unprotected method (Unsafe privileged actions). CVE-2005-1742 Inappropriate actions allowed by a particular role(Unsafe privileged actions). CVE-2001-1480 Untrusted entity allowed to access the system clipboard (Unsafe privileged actions). CVE-2001-1551 Extra Linux capability allows bypass of system-specified restriction (Unsafe privileged actions). CVE-2001-1166 User with debugging rights can read entire process (Unsafe privileged actions). CVE-2005-1816 Non-root admins can add themselves or others to the root admin group (Unsafe privileged actions). CVE-2005-2173 Users can change certain properties of objects to perform otherwise unauthorized actions (Unsafe privileged actions). CVE-2005-2027 Certain debugging commands not restricted to just the administrator, allowing registry modification and infoleak (Unsafe privileged actions). 1000 Category ChildOf 265 Unsafe Privilege All 58 Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination. High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource. Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Follow the principle of least privilege when assigning access rights to entities in a software system. CVE-2005-1736 Chaining of user rights. CVE-2002-1772 Gain certain rights via privilege chaining in alternate channel. CVE-2005-1973 Application is allowed to assign extra permissions to itself. CVE-2003-0640 "operator" user can overwrite usernames and passwords to gain admin privileges. It is difficult to find good examples for this weakness. There is some conceptual overlap with Unsafe Privilege. 1000 Category ChildOf 265 Privilege Chaining All A product does not properly track, modify, record, or reset privileges. Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Follow the principle of least privilege when assigning access rights to entities in a software system. Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource. CVE-2001-1555 Terminal privileges are not reset when a user logs out. CVE-2001-1514 Does not properly pass security context to child processes in certain cases, allows privilege escalation. CVE-2001-0128 Does not properly compute roles. 1000 Category ChildOf 265 Privilege Management Error All 58 A software system that accepts input in the form of a directory doubled dot dot slash ('directory/../../filename') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. see the vulnerability category "Path Traversal" CVE-2002-0298 1000 Weakness ChildOf 23 'directory/../../filename All The software does not properly manage privileges while it is switching between different contexts that cross privilege boundaries. Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Follow the principle of least privilege when assigning access rights to entities in a software system. Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource. CVE-2002-1688 Web browser cross domain problem when user hits "back" button. CVE-2003-1026 Web browser cross domain problem when user hits "back" button. CVE-2002-1770 Cross-domain issue - third party product passes code to web browser, which executes it in unsafe zone. CVE-2005-2263 Run callback in different security context after it has been changed from untrusted to trusted. * note that "context switch before actions are completed" is one type of problem that happens frequently, espec. in browsers. This concept needs more study. 1000 Category ChildOf 265 Privilege Context Switching Error All 35 17 30 In some contexts, a system executing with elevated permissions will hand off a process/file/etc. to another process/user. If the privileges of an entity are not reduced, then elevated privileges are spread throughout a system and possibly to an attacker. High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Design: Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges. Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource. CVE-2000-1213 Program does not drop privileges after acquiring the raw socket. CVE-2001-0559 Setuid program does not drop privileges after a parsing error occurs, then calls another program to handle the error. CVE-2001-0787 Does not drop privileges in related groups when lowering privileges. CVE-2002-0080 Does not drop privileges in related groups when lowering privileges. CVE-2001-1029 Does not drop privileges before determining access to certain files. CVE-1999-0813 Finger daemon does not drop privileges when executing programs on behalf of the user being fingered. CVE-1999-1326 FTP server does not drop privileges if a connection is aborted during file transfer. CVE-2000-0172 Program only uses seteuid to drop privileges. CVE-2004-2504 Windows program running as SYSTEM does not drop privileges before executing other programs (many others like this, especially involving the Help facility). CVE-2004-0806 Setuid program does not drop privileges before executing program specified in an environment variable. CVE-2004-0828 Setuid program does not drop privileges before processing file specified on command line. CVE-2004-2070 Service on Windows does not drop privileges before using "view file" option, allowing code execution. 1000 Category ChildOf 265 Privilege Dropping / Lowering Errors All The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Access control: An attacker may be able to access resources with the elevated privilege that he should not have been able to access. This is particularly likely in conjunction with another flaw -- e.g., a buffer overflow. Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Follow the principle of least privilege when assigning access rights to entities in a software system. Design: Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges. C C++ Java Example 2: The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file. Constraining the process inside the application's home directory before opening any files is a valuable security measure. However, the absence of a call to setuid() with some non-zero value means the application is continuing to operate with unnecessary root privileges. Any successful exploit carried out by an attacker against the application can now result in a privilege escalation attack because any malicious operations will be performed with the privileges of the superuser. If the application drops to the privilege level of a non-root user, the potential for damage is substantially reduced. The failure to drop system privileges when it is reasonable to do so is not a vulnerability by itself. It does, however, serve to significantly increase the Severity of other vulnerabilities. According to the principle of least privilege, access should be allowed only when it is absolutely necessary to the function of a given system, and only for the minimal necessary amount of time. Any further allowance of privilege widens the window of time during which a successful exploitation of the system will provide an attacker with that same privilege. If at all possible, limit the allowance of system privilege to small, simple sections of code that may be called atomically. When a program calls a privileged function, such as chroot(), it must first acquire root privilege. As soon as the privileged operation has completed, the program should drop root privilege and return to the privilege level of the invoking user. 1000 Weakness ChildOf 271 Least Privilege Violation Failure to drop privileges when reasonable All 35 17 76 If one changes security privileges, one should ensure that the change was successful Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) System Process Authorization: If privileges are not dropped, neither are access rights of the user. Often these rights can be prevented from being dropped. Authentication: If privileges are not dropped, in some cases the system may record actions as the user which is being impersonated rather than the impersonator. Design: Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges. Implementation: In Windows make sure that the process token has the SeImpersonatePrivilege(Microsoft Server 2003). Implementation: Always check all of your return values. C C++ Since we did not check the return value of ImpersonateNamedPipeClient, we do not know if the call succeeded. In Microsoft Operating environments that have access control, impersonation is used so that access checks can be performed on a client identity by a server with higher privileges. By impersonating the client, the server is restricted to client-level security -- although in different threads it may have much higher privileges. Code which relies on this for security must ensure that the impersonation succeeded-- i.e., that a proper privilege demotion happened. 1000 Weakness ChildOf 271 631 Category ChildOf 634 Failure to check whether privileges were dropped successfully All The software does not handle when it has insufficient privileges to perform an operation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) CVE-2001-1564 System limits are not properly enforced after privileges are dropped. CVE-2005-3286 Firewall crashes when it can't read a critical memory block that was protected by a malicious process. CVE-2005-1641 Does not give admin sufficient privileges to overcome otherwise legitimate user actions. Overlaps dropped privileges, insufficient permissions. Can produce resultant weaknesses. 1000 Category ChildOf 265 1000 Weakness CanAlsoBe 271 1000 Weakness CanAlsoBe 280 Insufficient privileges All A program, upon installation, sets insecure permissions for an object. Medium Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) Very carefully manage the setting, management and handling of permissions. Explicitly manage trust zones in the software. Design: Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges. CVE-2005-1941 Executables installed world-writable. CVE-2002-1713 Home directories installed world-readable. CVE-2001-1550 World-writable log files allow information loss; world-readable file has cleartext passwords. CVE-2002-1711 World-readable directory. CVE-2002-1844 Windows product uses insecure permissions when installing on Solaris (genesis: port error). CVE-2001-0497 Insecure permissions for a shared secret key file. Overlaps cryptographic problem. CVE-1999-0426 Default permissions of a device allow IP spoofing. 1000 Category ChildOf 275 Insecure Default Permissions All 81 1 19 A product defines a set of insecure permissions that are inherited by objects that are created by the program. Very carefully manage the setting, management and handling of permissions. Explicitly manage trust zones in the software. Design: Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges. CVE-2005-1841 User's umask is used when creating temp files. CVE-2002-1786 Insecure umask for core dumps [is the umask preserved or assigned?]. 1000 Category ChildOf 275 Insecure inherited permissions All A product inherits a set of insecure permissions for an object, e.g. when copying from an archive file, without user awareness or involvement. Very carefully manage the setting, management and handling of permissions. Explicitly manage trust zones in the software. Design: Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges. CVE-2005-1724 Does not obey specified permissions when exporting. 1000 Category ChildOf 275 Insecure preserved inherited permissions All A product, while it is executing, changes the permissions of an object in an insecure way that cannot be controlled by the user. Very carefully manage the setting, management and handling of permissions. Explicitly manage trust zones in the software. Design: Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges. CVE-2002-0265 Log files opened read/write. CVE-2003-0876 Log files opened read/write. CVE-2002-1694 Log files opened read/write. 1000 Category ChildOf 275 Insecure execution-assigned permissions All 81 19 A software system that accepts input in the form of a dot dot backslash ('..\filename') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. Note that '..' is ignored if the current working directory is the root directory. see the vulnerability category "Path Traversal" CVE-2002-0661 CVE-2002-0946 CVE-2002-1042 CVE-2002-1209 CVE-2002-1178 1000 Weakness ChildOf 23 '..\filename' ('dot dot backslash') All The application does not properly handle when it has insufficient permissions or privileges to access resources or system functionality, causing it to follow unexpected code paths that may leave the application in an invalid state. Very carefully manage the setting, management and handling of permissions. Explicitly manage trust zones in the software. Design: Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges, but they should also plan for cases in which those privileges might fail. Implementation: Always check to see if you have successfully accessed a resource or system functionality, and use proper error handling if it is unsuccessful. Do this even when you are operating in a highly privileged mode, because errors or environmental conditions might still cause a failure. For example, environments with highly granular permissions/privilege models, such as Windows or Linux capabilities, can cause unexpected failures. CVE-2003-0501 Special file system allows attackers to prevent ownership/permission change of certain entries by opening the entries before calling a setuid program. CVE-2004-0148 FTP server places a user in the root directory when the user's permissions prevent access to his/her own home directory. This can be both primary and resultant. When primary, it can expose a variety of weaknesses because a resource might not have the expected state, and subsequent operations might fail. It is often resultant from Unchecked Error Condition (CWE-391). This type of issue is under-studied, since researchers often concentrate on whether an object has too many permissions, instead of not enough. These weaknesses are likely to appear in environments with fine-grained models for permissions and privileges, which can include operating systems and other large-scale software packages. However, even highly simplistic permission/privilege models are likely to contain these issues if the developer has not considered the possibility of access failure. 1000 Category ChildOf 275 1000 Weakness PeerOf 391 Fails poorly due to insufficient permissions All The software does not properly preserve permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended. SUNALERT:27807 CVE-2001-1515 Automatic modification of permissions inherited from another file system. CVE-2005-1920 Permissions on backup file are created with defaults, possibly less secure than original file. CVE-2001-0195 File is made world-readable when being cloned. Note: can be resultant. 1000 Category ChildOf 275 1000 Weakness ChildOf 668 Permission preservation failure All The software assigns the wrong ownership, or does not properly verify the ownership, of an object or resource. File/Directory Very carefully manage the setting, management and handling of privileges and permissions. Explicitly manage trust zones in the software. CVE-1999-1125 Program runs setuid root but relies on a configuration file owned by a non-root user. 1000 Category ChildOf 264 631 Category ChildOf 632 Ownership errors All 35 17 The software does not properly verify that a critical resource is owned by the proper entity. Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource. CVE-2001-0178 Program does not verify the owner of a UNIX socket that is used for sending a password. CVE-2004-2012 Owner of special device not checked, allowing root. This overlaps verification errors, permissions, and privileges. 1000 Weakness ChildOf 282 1000 Category CanAlsoBe 264 1000 Weakness CanAlsoBe 345 Unverified Ownership All Improper administration of the permissions to the users of a system can result in unintended access to sensitive files. An access control list (ACL) represents who/what has permissions to a given object. Different operating systems implement (ACLs) in different ways. In UNIX, there are three types of permissions: read, write, and execute. Users are divided into three classes for file access: owner, group owner, and all other users where each class has a separate set of rights. In Windows NT, there are four basic types of permissions for files: "No access", "Read access", "Change access", and "Full control". Windows NT extends the concept of three types of users in UNIX to include a list of users and groups along with their associated permissions. A user can create an object (file) and assign specified permissions to that object. File/Directory Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Design: Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges. This item needs more work. Possible sub-categories include: -Trusted group includes undesired entities - Group can perform undesired actions - ACL parse error does not fail closed. 1000 Category ChildOf 264 631 Category ChildOf 632 Access Control List (ACL) errors 19 The software does not perform access control checks in a consistent manner across all potential execution paths. For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any information that they are not authorized for by simply requesting direct access to that page. Ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page. For web applications, attackers can issue a request directly to a page (URL) that they may not be authorized to access. If the access control policy is not consistently enforced on every page restricted to authorized users, then an attacker could gain access to and possibly corrupt these resources. 1000 Weakness ChildOf 284 629 View ChildOf 629 Missing Access Control All 1 13 60 51 17 45 39 76 77 59 87 Improper administration of the permissions to the users of a system can result in unintended access to sensitive files. Users can be assigned to the wrong group (class) of permissions resulting in unintended access rights to sensitive objects. This item needs more work. Possible sub-categories include: - user in wrong group - user with insecure profile / "configuration" 1000 Category ChildOf 264 User management errors All The software does not properly ensure that the user has proven their identity. An alternate term is "authentification", which appears to be most commonly used by people from non-English-speaking countries. Authentication Authentication bypass This can be resultant from SQL injection vulnerabilities and other issues. 1000 Category ChildOf 254 629 View ChildOf 629 635 View ChildOf 635 Authentication Error All 57 22 94 A product requires authentication, but the product has an alternate path or channel that does not require authentication. Note: this is often seen in web applications that assume that access to a particular CGI program can only be obtained through a "front" screen. But this problem is not just in web apps. Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource. CVE-2000-1179 CVE-1999-1454 CVE-2000-0944 CVE-1999-1077 CVE-2003-1035 overlaps brute force CVE-2003-0304 CVE-2002-0870 CVE-2004-0213 non-web CVE-2002-0066 Bypass authentication via direct request to named pipe. CVE-2003-1035 User can avoid lockouts by using an API instead of the GUI to conduct brute force password guessing. overlaps Unprotected Alternate Channel 1000 Weakness ChildOf 592 1000 Weakness PeerOf 420 629 View ChildOf 629 Authentication Bypass by Alternate Path/Channel All Architecture and Design 56 The software performs authentication based on the name of the resource being accessed, but there are multiple names for the resource, and not all names are checked. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function). CVE-2003-0317 CVE-2004-0847 Overlaps equivalent encodings, canonicalization, authorization, multiple trailing slash, trailing space, mixed case, and other equivalence issues. "alternate name" itself is a rather general class of data-driven manipulation. 1000 Weakness ChildOf 592 Authentication bypass by alternate name All A software system that accepts input in the form of a leading dot dot backslash ('\..\filename') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. Note that '..' is ignored if the current working directory is the root directory. see the vulnerability category "Path Traversal" CVE-2002-1987 CVE-2005-2142 1000 Weakness ChildOf 23 '\..\filename' ('leading dot dot backslash') All Weaknesses in this attack-focused category are caused by improperly implemented authentication schemes that are subject to spoofing attacks. Resultant vuln from insufficient verification. 1000 Weakness ChildOf 592 Authentication bypass by spoofing 21 22 94 60 59 The use of self-reported DNS names as authentication is flawed and can easily be spoofed by malicious users. High Authentication: Malicious users can fake authentication information by providing false DNS information. Design: Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate. The following code uses a DNS lookup to determine whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status. h_name, tHost, sizeof(tHost))) { trusted = true; } else { trusted = false; }]]> C C++ h_name==...) n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen); }]]> Java As DNS names can be easily spoofed or misreported, they do not constitute a valid authentication mechanism. Alternate methods should be used if the significant authentication is necessary. In addition, DNS name resolution as authentication would -- even if it was a valid means of authentication -- imply a trust relationship with the DNS servers used, as well as all of the servers they refer to. IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication. 1000 Weakness ChildOf 290 1000 Compound_Element PeerOf 291 1000 Weakness PeerOf 293 Trusting self-reported DNS name All Architecture and Design 89 The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking. High Authorization: Actions, which may not be authorized otherwise, can be carried out as if they were validated by the server referred to. Accountability: Actions may be taken in the name of the server referred to. Design: Use other means of authorization that cannot be simply spoofed. Possibilities include a username/password or certificate. C C++ Java The referer field in HTML requests can be simply modified by malicious users, rendering it useless as a means of checking the validity of the request in question. In order to usefully check if a given action is authorized, some means of strong authentication and method protection must be used. Terminology Note: while the proper spelling might be regarded as "referrer," the HTTP RFCs and their implementations use "referer," so this is regarded as the correct spelling. 1000 Weakness ChildOf 290 1000 Compound_Element PeerOf 291 1000 Weakness PeerOf 293 Using referrer field for authentication All Architecture and Design A capture-replay flaw exists when the design of the software makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes). High Authorization: Messages sent with a capture-relay attack allow access to resources which are not otherwise accessible without proper authentication. Design: Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once. C C++ Java Capture-replay attacks are common and can be difficult to defeat without cryptography. They are a subset of network injection attacks that rely listening in on previously sent valid commands, then changing them slightly if necessary and resending the same commands to the server. Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content. 1000 Weakness ChildOf 592 Authentication bypass by replay Capture-replay All Architecture and Design 94 60 Failure to follow the chain of trust when validating a certificate results in the trust of a given resource which has no connection to trusted root-certificate entities. Low Authentication: Exploitation of this flaw can lead to the trust of data that may have originated with a spoofed source. Accountability: Data, requests, or actions taken by the attacking entity can be carried out as a spoofed benign entity. Design: Ensure that proper certificate checking is included in the system design. Implementation: Understand, and properly implement all checks necessary to ensure the integrity of certificate trust integrity. If a system fails to follow the chain of trust of a certificate to a root server, the certificate loses all usefulness as a metric of trust. Essentially, the trust gained from a certificate is derived from a chain of trust -- with a reputable trusted entity at the end of that list. The end user must trust that reputable source, and this reputable source must vouch for the resource in question through the medium of the certificate. In some cases, this trust traverses several entities who vouch for one another. The entity trusted by the end user is at one end of this trust chain, while the certificate wielding resource is at the other end of the chain. If the user receives a certificate at the end of one of these trust chains and then proceeds to check only that the first link in the chain, no real trust has been derived, since you must traverse the chain to a trusted source to verify the certificate. 1000 Weakness ChildOf 573 1000 Category ChildOf 295 1000 Weakness PeerOf 322 1000 Weakness PeerOf 297 1000 Weakness PeerOf 298 1000 Weakness PeerOf 299 Failure to follow chain of trust in certificate validation All The failure to validate host-specific certificate data may mean that, while the certificate read was valid, it was not for the site originally requested. High Integrity: The data read from the system vouched for by the certificate may not be from the expected system. Authentication: Trust afforded to the system in question -- based on the expired certificate -- may allow for spoofing or redirection attacks. Design: Check for expired certificates and provide the user with adequate information about the nature of the problem and how to proceed. If the host-specific data contained in a certificate is not checked, it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data, impersonating a trusted host. While the attacker in question may have a valid certificate, it may simply be a valid certificate for a different site. In order to ensure data integrity, we must check that the certificate is valid and that it pertains to the site that we wish to access. 1000 Weakness ChildOf 345 1000 Category ChildOf 295 1000 Weakness PeerOf 296 1000 Weakness PeerOf 298 1000 Weakness PeerOf 299 Failure to validate host-specific certificate data All The failure to validate certificate operation may result in trust being assigned to certificates which have been abandoned due to age. Low Integrity: The data read from the system vouched for by the expired certificate may be flawed due to malicious spoofing. Authentication: Trust afforded to the system in question -- based on the expired certificate -- may allow for spoofing attacks. Design: Check for expired certificates and provide the user with adequate information about the nature of the problem and how to proceed. When the expiration of a certificate is not taken in to account, no trust has necessarily been conveyed through it; therefore, all benefit of certificate is lost. 1000 Weakness ChildOf 672 1000 Category ChildOf 295 1000 Weakness PeerOf 296 1000 Weakness PeerOf 297 1000 Weakness PeerOf 322 1000 Weakness PeerOf 299 1000 Weakness PeerOf 324 Failure to validate certificate expiration All If a certificate is used without first checking to ensure it was not revoked, the certificate may be compromised. Medium Authentication: Trust may be assigned to an entity who is not who it claims to be. Integrity: Data from an untrusted (and possibly malicious) source may be integrated. Confidentiality: Date may be disclosed to an entity impersonating a trusted entity, resulting in information disclosure. Design: Ensure that certificates are checked for revoked status. C C++ The failure to check for certificate revocation is a far more serious flaw than related certificate failures. This is because the use of any revoked certificate is almost certainly malicious. The most common reason for certificate revocation is compromise of the system in question, with the result that no legitimate servers will be using a revoked certificate, unless they are sorely out of sync. 1000 Weakness ChildOf 404 1000 Category ChildOf 295 1000 Weakness PeerOf 296 1000 Weakness PeerOf 297 1000 Weakness PeerOf 322 1000 Weakness PeerOf 298 Failure to check for certificate revocation All A software system that accepts input in the form of a leading directory dot dot backslash ('\directory\..\filename') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. see the vulnerability category "Path Traversal" CVE-2002-1987 1000 Weakness ChildOf 23 7 - '\directory\..\filename All The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint. In order to establish secure communication between two parties, it is often important to adequately verify the identity of entities at each end of the communication channel. Failure to do so adequately or consistently may result in insufficient or incorrect identification of either communicating entity. This can have negative consequences such as misplaced trust in the entity at the other end of the channel. An attacker can leverage this by interposing between the communicating entities and masquerading as the original entity. In the absence of sufficient verification of identity, such an attacker can eavesdrop and potentially modify the communication between the original entities. Always fully authenticate both ends of any communications channel. Adhere to the principle of complete mediation. A certificate binds an identity to a cryptographic key to authenticate a communicating party. Often, the certificate takes the encrypted form of the hash of the identity of the subject, the public key, and information such as time of issue or expiration using the issuer's private key. The certificate can be validated by deciphering the certificate with the issuer's public key. See also X.509 certificate signature chains and the PGP certification structure. M. Bishop Computer Security: Art and Science Addison-Wesley 2003 1000 Weakness ChildOf 287 Man-in-the-middle (MITM) All 57 94 Simple authentication protocols are subject to reflection attacks if a malicious user can use the target machine to impersonate a trusted user. A mutual authentication protocol requires each party to respond to a random challenge by the other party by encrypting it with a pre-shared key. Often, however, such protocols employ the same pre-shared key for communication with a number of different entities. A malicious user or an attacker can easily compromise this protocol without possessing the correct key by employing a reflection attack on the protocol. Medium Authentication: The primary result of reflection attacks is successful authentication with a target machine -- as an impersonated user. Design: Use different keys for the initiator and responder or of a different type of challenge for the initiator and responder. Design: Let the initiator prove its identity before proceeding. C C++ Java Reflection attacks capitalize on mutual authentication schemes in order to trick the target into revealing the secret shared between it and another valid user. In a basic mutual-authentication scheme, a secret is known to both the valid user and the server; this allows them to authenticate. In order that they may verify this shared secret without sending it plainly over the wire, they utilize a Diffie-Hellman-style scheme in which they each pick a value, then request the hash of that value as keyed by the shared secret. In a reflection attack, the attacker claims to be a valid user and requests the hash of a random value from the server. When the server returns this value and requests its own value to be hashed, the attacker opens another connection to the server. This time, the hash requested by the attacker is the value which the server requested in the first connection. When the server returns this hashed value, it is used in the first connection, authenticating the attacker successfully as the impersonated valid user. 1000 Weakness ChildOf 287 1000 Weakness PeerOf 327 629 View ChildOf 629 Reflection attack in an auth protocol All 90 The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker, e.g. if a web application relies on a cookie "Authenticated=1" CVE-2002-0367 DebPloit CVE-2004-0261 Web auth CVE-2002-1730 Authentication bypass by setting certain cookies to "true". CVE-2002-1734 Authentication bypass by setting certain cookies to "true". CVE-2002-2064 Admin access by setting a cookie. CVE-2002-2054 Gain privileges by setting cookie. CVE-2004-1611 Product trusts authentication information in cookie. CVE-2005-1708 Authentication bypass by setting admin-testing variable to true. CVE-2005-1787 Bypass auth and gain privileges by setting a variable. 1000 Weakness ChildOf 592 Authentication Bypass via Assumed-Immutable Data All 45 10 21 39 31 13 77 Authentication techniques should follow the algorithms that define them exactly, otherwise it might be possible to bypass the authentication. A malformed or improper implementation of an algorithm may weaken the technique. CVE-2003-0750 Conditional should have been an 'or' not an 'and'. 1000 Weakness ChildOf 287 Authentication Logic Error All 90 Authentication techniques should follow the algorithms that define them exactly, otherwise authentication can be jeopardized. A missing critical step in the implementation of an algorithm may weaken the authorization technique. CVE-2004-2163 Shared secret not verified in a RADIUS response packet, allowing authentication bypass by spoofing server replies. 1000 Weakness ChildOf 287 1000 Weakness ChildOf 573 1000 Weakness CanAlsoBe 345 Missing Critical Step in Authentication All The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error. CVE-2002-1374 CVE-2000-0979 CVE-2001-0088 Most "authentication bypass" errors are resultant, not primary. 1000 Weakness ChildOf 592 Authentication Bypass by Primary Weakness All The software does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. CVE-2002-1810 MFV. Access TFTP server without authentication and obtain configuration file with sensitive plaintext information. This is separate from "bypass" issues in which authentication exists, but is faulty. 1000 Weakness ChildOf 287 No Authentication for Critical Function All 62 36 12 40 The software does not implement sufficient measures to prevent multiple failed authentication attempts within in a short time frame, making it more susceptible to brute force attacks. Common protection mechanisms include disconnecting a user, implementing a timeout, locking out a targeted account, or requiring a computational task on the user's part. CVE-1999-1152 Product does not disconnect or timeout after multiple failed logins. CVE-2001-1291 Product does not disconnect or timeout after multiple failed logins. CVE-2001-0395 Product does not disconnect or timeout after multiple failed logins. CVE-2001-1339 Product does not disconnect or timeout after multiple failed logins. CVE-2002-0628 Product does not disconnect or timeout after multiple failed logins. CVE-1999-1324 User accounts not disabled when they exceed a threshold; possibly a resultant vuln. 1000 Weakness ChildOf 287 Multiple Failed Authentication Attempts not Prevented All Architecture and Design The use of single-factor authentication can lead to unnecessary risk of compromise when compared with the benefits of a dual-factor authentication scheme. High Authentication: If the secret in a single-factor authentication scheme gets compromised, full authentication is possible. Design: Use multiple independent authentication schemes, which ensures that -- if one of the methods is compromised -- the system itself is still likely safe from compromise. C Java While the use of multiple authentication schemes is simply piling on more complexity on top of authentication, it is inestimably valuable to have such measures of redundancy. The use of weak, reused, and common passwords is rampant on the internet. Without the added protection of multiple authentication schemes, a single mistake can result in the compromise of an account. For this reason, if multiple schemes are possible and also easy to use, they should be implemented and required. 1000 Weakness ChildOf 287 1000 Weakness ChildOf 654 1000 Weakness PeerOf 309 Using single-factor authentication All Architecture and Design The use of password systems as the primary means of authentication may be subject to several flaws or shortcomings, each reducing the effectiveness of the mechanism. Very High Authentication: The failure of a password authentication mechanism will almost always result in attackers being authorized as valid users. Design: Use a zero-knowledge password protocol, such as SRP. Design: Ensure that passwords are sorted safely and are not reversible. Design: Implement password aging functionality that requires passwords be changed after a certain point. Design: Use a mechanism for determining the strength of a password and notify the user of weak password use. Design: Inform the user of why password protections are in place, how they work to protect data integrity, and why it is important to heed their warnings. C Java Password systems are the simplest and most ubiquitous authentication mechanisms. However, they are subject to such well known attacks,and such frequent compromise that their use in the most simple implementation is not practical. In order to protect password systems from compromise, the following should be noted: - Passwords should be stored safely to prevent insider attack and to ensure that -- if a system is compromised -- the passwords are not retrievable. Due to password reuse, this information may be useful in the compromise of other systems these users work with. In order to protect these passwords, they should be stored encrypted, in a non-reversible state, such that the original text password cannot be extracted from the stored value. - Password aging should be strictly enforced to ensure that passwords do not remain unchanged for long periods of time. The longer a password remains in use, the higher the probability that it has been compromised. For this reason, passwords should require refreshing periodically, and users should be informed of the risk of passwords which remain in use for too long. - Password strength should be enforced intelligently. Rather than restrict passwords to specific content, or specific length, users should be encouraged to use upper and lower case letters, numbers, and symbols in their passwords. The system should also ensure that no passwords are derived from dictionary words. 1000 Weakness ChildOf 287 1000 Weakness ChildOf 654 1000 Weakness PeerOf 308 Using password systems All Architecture and Design A software system that accepts input in the form of a leading directory doubled dot dot backslash ('directory\..\..\filename') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. see the vulnerability category "Path Traversal" CVE-2002-0160 1000 Weakness ChildOf 23 8 - 'directory\..\..\filename All The failure to encrypt data passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys. Very High Confidentiality: Properly encrypted data channels ensure data confidentiality. Integrity: Properly encrypted data channels ensure data integrity. Accountability: Properly encrypted data channels ensure accountability. Requirements specification: require that encryption be integrated into the system. Design: Ensure that encryption is properly integrated into the system design, not simply as a drop-in replacement for sockets. C h_addr,hp->h_length); if (argc < 3) port = 80; else port = (unsigned short)atoi(argv[3]); server.sin_port = htons(port); if (connect(sock, (struct sockaddr *)&server, sizeof server) < 0) error("Connecting"); ... while ((n=read(sock,buffer,BUFSIZE-1))!=-1) { write(dfd,password_buffer,n); ...]]> Java If the application does not use a secure channel, such as SSL, to exchange sensitive information, it is possible for an attacker with access to the network traffic to sniff packets from the connection and uncover the data. This attack is not technically difficult, but does require physical access to some portion of the network over which the sensitive data travels. This access is usually somewhere near where the user is connected to the network (such as a colleague on the company network) but can be anywhere along the path from the user to the end server. Omitting the use of encryption in any program which transfers data over a network of any kind should be considered on par with delivering the data sent to each user on the local networks of both the sender and receiver. Worse, this omission allows for the injection of data into a stream of communication between two parties -- with no means for the victims to separate valid data from invalid. In this day of widespread network attacks and password collection sniffers, it is an unnecessary risk to omit encryption from the design of any system which might benefit from it. 1000 Category ChildOf 310 629 View ChildOf 629 Failure to encrypt data All 65 The application stores sensitive information in plaintext within a resource that might be accessible to another control sphere, when the information should be encrypted or otherwise protected. 1000 Weakness ChildOf 311 Plaintext Storage of Sensitive Information 37 Storing sensitive data in plaintext in a file, or on disk, makes the data more easily accessible than if encrypted. This significantly lowers the difficulty of exploitation by attackers. Secret information should not be stored in plaintext in a file or disk. Even if heavy fortifications are in place, sensitive data should be encrypted to prevent the risk of losing confidentiality. CVE-2001-1481 Plaintext credentials in world-readable file. CVE-2005-1828 Password in cleartext in config file. CVE-2005-2209 Password in cleartext in config file. CVE-2002-1696 Decrypted copy of a message written to disk given a combination of options and when user replies to an encrypted message. CVE-2004-2397 Plaintext storage of private key and passphrase in log file when user imports the key. 1000 Weakness ChildOf 312 Plaintext Storage in File or on Disk All Storing sensitive data in plaintext in the registry makes the data more easily accessible than if encrypted. This significantly lowers the difficulty of exploitation by attackers. Sensitive information should not be stored in plaintext in a registry. Even if heavy fortifications are in place, sensitive data should be encrypted to prevent the risk of losing confidentiality. CVE-2005-2227 Plaintext passwords in registry key. 1000 Weakness ChildOf 312 Plaintext Storage in Registry All 37 Storing sensitive data in plaintext in a cookie makes the data more easily accessible than if encrypted. This significantly lowers the difficulty of exploitation by attackers. Sensitive information should not be stored in plaintext in a cookie. Even if heavy fortifications are in place, sensitive data should be encrypted to prevent the risk of losing confidentiality. CVE-2002-1800 Admin password in plaintext in a cookie. CVE-2001-1537 Default configuration has cleartext usernames/passwords in cookie. CVE-2001-1536 Usernames/passwords in cleartext in cookies. CVE-2005-2160 Authentication information stored in cleartext in a cookie. 1000 Weakness ChildOf 312 Plaintext Storage in Cookie All 37 74 39 31 Storing sensitive data in plaintext in memory makes the data more easily accessible than if encrypted. This significantly lowers the difficulty of exploitation by attackers. The sensitive memory might be saved to disk, stored in a core dump, or remain uncleared if the application crashes, or if the programmer does not clear the memory before freeing it. Memory Sensitive information should not be stored in plaintext in memory. Even if heavy fortifications are in place, sensitive data should be encrypted to prevent the risk of losing confidentiality. CVE-2001-1517 Sensitive authentication information in cleartext in memory. BID:10155 Sensitive authentication information in cleartext in memory. CVE-2001-0984 Password protector leaves passwords in memory when window is minimized, even when "clear password when minimized" is set. CVE-2003-0291 SSH client does not clear credentials from memory. This could be a resultant weakness, e.g. if the compiler removes code that was intended to wipe memory. It could be argued that such problems are usually only exploitable by those with administrator privileges. However, swapping could cause the memory to be written to disk and leave it accessible to physical attack afterwards. 1000 Weakness ChildOf 312 631 Category ChildOf 633 Plaintext Storage in Memory All Storing sensitive data in plaintext within the GUI makes the data more easily accessible than if encrypted. This significantly lowers the difficulty of exploitation by attackers. An attacker can often obtain data from a GUI, even if hidden, by using an API to directly access GUI objects such as windows and menus. Sensitive information should not be stored in plaintext in a GUI. Even if heavy fortifications are in place, sensitive data should be encrypted to prevent the risk of losing confidentiality. CVE-2002-1848 Unencrypted passwords stored in GUI dialog may allow local users to access the passwords. 1000 Weakness ChildOf 312 Plaintext Storage in GUI All Sensitive information should not be stored in plaintext in an executable. Attackers can reverse engineer a binary code to obtain secret data. Sensitive information should not be stored in an executable. Even if heavy fortifications are in place, sensitive data should be encrypted to prevent the risk of losing confidentiality. CVE-2005-1794 Product stores RSA private key in a DLL and uses it to sign a certificate, allowing spoofing of servers and MITM attacks. 1000 Weakness ChildOf 312 Plaintext Storage in Executable All 37 65 Transmitting sensitive data in plaintext makes the data more easily accessible than if encrypted. This significantly lowers the difficulty of exploitation by attackers. Secret information should not be transmitted in plaintext. Attackers can "sniff" communications and obtain the transmitted data. Encrypt the data with a reliable encryption scheme before transmitting. CVE-2002-1949 Passwords transmitted in cleartext. 1000 Weakness ChildOf 311 Plaintext Transmission of Sensitive Information All 65 A software system that accepts input in the form of a triple dot ('...') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. This can be used to cause problems for systems that strip out '..' from input in an attempt to remove relative path traversal. see the vulnerability category "Path Traversal" CVE-2001-0467 "\..." in web server CVE-2001-0615 "..." or "...." in chat server CVE-2001-0963 "..." in cd command in FTP server CVE-2001-1193 "..." in cd command in FTP server CVE-2001-1131 "..." in cd command in FTP server CVE-2001-0480 "..." in GET or CD command in FTP server CVE-2002-0288 "..." in web server CVE-2002-0784 HTTP server protects against ".." but allows "..." CVE-2003-0313 Directory listing of web server using "..." CVE-2005-1658 Triple dot This manipulation is effective in two different contexts: (1) it is equivalent to "..\.." on Windows, or (2) it can take advantage of insufficient filtering, e.g. if the programmer does a single-pass removal of "./" in a string (collapse of data into unsafe value) 1000 Weakness ChildOf 23 '...' (triple dot) All The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered High Authentication: If hard-coded cryptographic keys are used, it is almost certain that malicious users will gain access through the account in question. Design: Prevention schemes mirror that of hard-coded password storage. C C++ Java The main difference between the use of hard-coded passwords and the use of hard-coded cryptographic keys is the false sense of security that the former conveys. Many people believe that simply hashing a hard-coded password before storage will protect the information from malicious users. However, many hashes are reversible (or at least vulnerable to brute force attacks) -- and further, many authentication protocols simply request the hash itself, making it no better than a password. 1000 Category ChildOf 320 1000 Weakness ChildOf 344 1000 Weakness ChildOf 671 629 View ChildOf 629 Use of hard-coded cryptographic key All Performing a key exchange without verifying the identity of the entity being communicated with will preserve the integrity of the information sent between the two entities; this will not, however, guarantee the identity of the end entity. High Authentication: No authentication takes place in this process, bypassing an assumed protection of encryption Confidentiality: The encrypted communication between a user and a trusted host may be subject to a "man-in-the-middle" sniffing attack Design: Ensure that proper authentication is included in the system design. Implementation: Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications. Many systems have used Diffie-Hellman key exchange without authenticating the entities exchanging keys, leading to man-in-the-middle attacks. Many people using SSL/TLS skip the authentication (often unknowingly). Key exchange without entity authentication may lead to a set of attacks known as "man-in-the-middle" attacks. These attacks take place through the impersonation of a trusted server by a malicious server. If the user skips or ignores the failure of authentication, the server may request authentication information from the user and then use this information with the true server to either sniff the legitimate traffic between the user and host or simply to log in manually with the user's credentials. 1000 Category ChildOf 320 1000 Weakness PeerOf 296 1000 Weakness ChildOf 297 1000 Weakness ChildOf 287 1000 Weakness ChildOf 345 1000 Weakness PeerOf 298 1000 Weakness PeerOf 299 Key exchange without entity authentication All Nonces should be used for the present occasion and only once. High Authentication: Potentially a replay attack, in which an attacker could send the same data twice, could be crafted if nonces are allowed to be reused. This could allow a user to send a message which masquerades as a valid message from a valid user. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Implementation: Refuse to reuse nonce values. Implementation: Use techniques such as requiring incrementing, time based and/or challenge response to assure uniqueness of nonces. C C++ #include #include #include int main(){ char *paragraph = NULL; char *data = NULL; char *nonce = "bad"; char *password = "secret"; parsize=strlen(nonce)+strlen(password); paragraph=(char*)malloc(para_size); strncpy(paragraph,nonce,strlen(nonce)); strcpy(paragraph,password,strlen(password)); data=(unsigned char*)malloc(20); SHA1((const unsigned char*)paragraph,parsize,(unsigned char*)data); free(paragraph); free(data); //Do something with data// return 0; }]]> Nonces, are often bundled with a key in a communication exchange to produce a new session key for each exchange. 1000 Category ChildOf 320 Reusing a nonce, key pair in encryption All The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key. Low Authentication: The cryptographic key in question may be compromised, providing a malicious user with a method for authenticating as the victim. Design: Adequate consideration should be put in to the user interface in order to notify users previous to the key's expiration, to explain the importance of new key generation and to walk users through the process as painlessly as possible. Run time: Users must heed warnings and generate new keys and passwords when they expire. C C++ While the expiration of keys does not necessarily ensure that they are compromised, it is a significant concern that keys which remain in use for prolonged periods of time have a decreasing probability of integrity. For this reason, it is important to replace keys within a period of time proportional to their strength. 1000 Weakness ChildOf 672 1000 Category ChildOf 320 1000 Weakness PeerOf 298 Using a key past its expiration date All Cryptographic implementations should follow the algorithms that define them exactly otherwise encryption can be faulty. BID:2356 Overlaps incomplete/missing security check. Can be resultant. 1000 Category ChildOf 310 1000 Weakness ChildOf 573 1000 Weakness PeerOf 358 629 View ChildOf 629 Missing Required Cryptographic Step All 68 Insufficiently strong encryption schemes may not adequately secure secret data from attackers. Attackers can guess or use brute force attacks to break weakly encrypted schemes. Design: Use a cryptographic algorithm that is currently considered to be strong by experts in the field. CVE-2001-1546 Weak encryption CVE-2004-2172 Weak encryption (chosen plaintext attack) CVE-2002-1682 Weak encryption CVE-2002-1697 Weak encryption produces same ciphertext from the same plaintext blocks. CVE-2002-1739 Weak encryption CVE-2005-2281 Weak encryption scheme CVE-2002-1872 Weak encryption (XOR) CVE-2002-1910 Weak encryption (reversible algorithm). CVE-2002-1946 Weak encryption (one-to-one mapping). CVE-2002-1975 Encryption error uses fixed salt, simplifying brute force / dictionary attacks (overlaps randomness). A variety of encryption algorithms exist, with various weaknesses. This category could probably be split into smaller sub-categories. 1000 Category ChildOf 310 1000 Weakness ChildOf 693 629 View ChildOf 629 Weak Encryption All Architecture and Design 20 The use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the disclosure of sensitive information. Medium to High Confidentiality: The confidentiality of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm. Integrity: The integrity of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm. Accountability: Any accountability to message content preserved by cryptography may be subject to attack. Design: Use a cryptographic algorithm that is currently considered to be strong by experts in the field. You should choose a tested and widely used implementation. As with all cryptographic mechanisms, the source code should be available for analysis. C C++ Java Cryptographic algorithms are the methods by which data is scrambled. There are a small number of well understood and heavily studied algorithms that should be used by most applications. It is quite difficult to produce a secure algorithm, and even high profile algorithms by accomplished cryptographic experts have been broken. The use of a non-standard algorithm is dangerous because a determined attacker may be able to break the algorithm and compromise whatever data has been protected. Since the state of cryptography advances so rapidly, it is common to find algorithms, which previously were considered to be safe, currently considered unsafe. In some cases, things are discovered, or processing speed increases to the degree that the cryptographic algorithm provides little more benefit than the use of no cryptography at all. 1000 Weakness ChildOf 326 1000 Weakness PeerOf 311 Using a broken or risky cryptographic algorithm All Architecture and Design 97 The product uses a hashing algorithm that produces results that can allow an attacker to determine the original input - or an input that generates the same hash - using feasible brute force or custom attacks. Use a hash algorithm that is currently considered to be strong by experts in the field. MD-4 and MD-5 have known weaknesses. SHA-1 has also been broken. 1000 Category ChildOf 310 Reversible One-Way Hash All Architecture and Design 68 Not using a random initialization Vector (IV) with Cipher Block Chaining (CBC) Mode causes algorithms to be susceptible to dictionary attacks. Medium Confidentiality: If the CBC is not properly initialized, data that is encrypted can be compromised and therefore be read. Integrity: If the CBC is not properly initialized, encrypted data could be tampered with in transfer. Accountability: Cryptographic based authentication systems could be defeated. Integrity: It is important to properly initialize CBC operating block ciphers or their utility is lost. C C++ EVP_CIPHER_CTX ctx; char key[EVP_MAX_KEY_LENGTH]; char iv[EVP_MAX_IV_LENGTH]; RAND_bytes(key, b); memset(iv,0,EVP_MAX_IV_LENGTH); EVP_EncryptInit(&ctx,EVP_bf_cbc(), key,iv);]]> Java CBC is the most commonly used mode of operation for a block cipher. It solves electronic code book's dictionary problems by XORing the ciphertext with plaintext. If it used to encrypt multiple data streams, dictionary attacks are possible, provided that the streams have a common beginning sequence. 1000 Category ChildOf 310 1000 Weakness ChildOf 330 1000 Weakness ChildOf 573 Not using a random IV with CBC mode All Implementation A software system that accepts input in the form of a multiple dot ('....') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. This can be used to cause problems for systems that strip out '..' from input in an attempt to remove relative path traversal. see the vulnerability category "Path Traversal" CVE-2000-0240 read files via "/........../" in URL CVE-2000-0773 read files via "...." in web server CVE-1999-1082 read files via "......" in web server (doubled triple dot?) CVE-2004-2121 read files via "......" in web server (doubled triple dot?) CVE-2001-0491 multiple attacks using "..", "...", and "...." in different commands CVE-2001-0615 "..." or "...." in chat server 1000 Weakness ChildOf 23 '....' (multiple dot) All The software may use insufficiently random numbers or values in a security context that requires unpredictable numbers. Non-specific, cryptography, authentication, session management. Use well vetted pseudo-random number generating algorithms with adequate length seeds. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a "random enough" number. Implementation: Perform FIPS 140-1 tests on data to catch obvious entropy problems. Implementation: Consider a PRNG which re-seeds itself, as needed from a high quality pseudo-random output, like hardware devices. The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase. This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG. Factors: can be primary to cryptographic errors, authentication errors, symlink following, information leaks, and others. Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in security-sensitive context. Computers are deterministic machines, and as such are unable to produce true randomness. Pseudo-Random Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated. There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and forms an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between it and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts. J. Viega G. McGraw Building Secure Software: How to Avoid Security Problems the Right Way 2002 1000 Category ChildOf 254 Randomness and Predictability Insecure Randomness All 59 The software uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others. Determine the necessary entropy to adequately provide for randomness and predictability. This can be achieved by increasing the number of bits of objects such as keys and seeds. CVE-2001-0950 Insufficiently random data used to generate session tokens using C rand(). Also, for certificate/key generation, uses a source that does not block when entropy is low. J. Viega G. McGraw Building Secure Software: How to Avoid Security Problems the Right Way 2002 1000 Weakness ChildOf 330 Insufficient Entropy All 59 The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat. Medium Availability: If a pseudo-random number generator is using a limited entropy source which runs out (if the generator fails closed), the program may pause or crash. Authentication: If a PRNG is using a limited entropy source which runs out, and the generator fails open, the generator could produce predictable random numbers. Potentially a weak source of random numbers could weaken the encryption method used for authentication of users. In this case, potentially a password could be discovered. Implementation: Perform FIPS 140-1 tests on data to catch obvious entropy problems. Implementation: Consider a PRNG which re-seeds itself, as needed from a high quality pseudo-random output, like hardware devices. C C++ Java When deciding which PRNG to use, look at its sources of entropy. Depending on what your security needs are, you may need to use a random number generator which always uses strong random data -- i.e., a random number generator which attempts to be strong but will fail in a weak way or will always provide some middle ground of protection through techniques like re-seeding. Generally something which always provides a predictable amount of strength is preferable and should be used. 1000 Weakness ChildOf 331 Insufficient entropy in PRNG All True random number generators generally have a limited source of entropy and therefore can fail or block. Low to Medium Availability: A program may crash or block if it runs out of random numbers. Implementation: Rather than failing on a lack of random numbers, it is often preferable to wait for more numbers to be created. C The rate at which true random numbers can be generated is limited.It is important that one uses them only when they are needed for security. 1000 Weakness ChildOf 331 Failure of TRNG All The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks. Implementation: Perform FIPS 140-1 tests on data to catch obvious entropy problems. Implementation: Consider a PRNG which re-seeds itself, as needed from a high quality pseudo-random output, like hardware devices. CVE-2002-0583 Product uses 5 alphanumeric characters for filenames of expense claim reports, stored under web root. CVE-2002-0903 Product uses small number of random numbers for a code to approve an action, and also uses predictable new user IDs, allowing attackers to hijack new accounts. CVE-2003-1230 SYN cookies implementation only uses 32-bit keys, making it easier to brute force ISN. CVE-2004-0230 Complex predictability / randomness (reduced space). 1000 Weakness ChildOf 330 Small Space of Random Values All A Pseudo-Random Number Generator (PRNG) uses seeds incorrectly. 1000 Weakness ChildOf 330 PRNG Seed Error All A PRNG uses the same seed each time the product is initialized. If an attacker can guess (or knows) the seed, then he/she may be able to determine the "random" number produced from the PRNG. Don't reuse PRNG seeds. Implementation: Consider a PRNG which re-seeds itself, as needed from a high quality pseudo-random output, like hardware devices. Implementation: Perform FIPS 140-1 tests on data to catch obvious entropy problems. 1000 Weakness ChildOf 335 Same Seed in PRNG All A PRNG is initialized from a predictable seed, e.g. using process ID or system time. Use non-predictable inputs for seed generation. Implementation: Perform FIPS 140-1 tests on data to catch obvious entropy problems. Implementation: Consider a PRNG which re-seeds itself, as needed from a high quality pseudo-random output, like hardware devices. 1000 Weakness ChildOf 335 Predictable Seed in PRNG All The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG is not cryptographically strong. Medium Authentication: Potentially a weak source of random numbers could weaken the encryption method used for authentication of users. In this case, a password could potentially be discovered. Design through Implementation: Use functions or hardware which use a hardware-based random number generation for all crypto. This is the recommended solution. Use CyptGenRandom on Windows, or hw_rand() on Linux. C C++ Java For a given seed, these "random number" generators will produce a reliable stream of numbers. Therefore, if an attacker knows the seed or can guess it easily, he will be able to reliably guess your random numbers. Often a pseudo-random number generator (PRNG) is not designed for cryptography. Sometimes a mediocre source of randomness is sufficient or preferable for algorithms which use random numbers. Weak generators generally take less processing power and/or do not use the precious, finite, entropy sources on a system. 1000 Weakness ChildOf 330 Non-cryptographic PRNG All A PRNG uses a relatively small space of seeds. Use well vetted pseudo-random number generating algorithms with adequate length seeds. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a "random enough" number. Implementation: Perform FIPS 140-1 tests on data to catch obvious entropy problems. Implementation: Consider a PRNG which re-seeds itself, as needed from a high quality pseudo-random output, like hardware devices. CVE-2002-0872 overlaps predictable from observable state 1000 Weakness ChildOf 335 1000 Weakness PeerOf 341 Small Seed Space in PRNG All A software system that accepts input in the form of a doubled dot dot slash ('....//') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. This can be used to cause problems for systems that strip out '../' from input in an attempt to remove relative path traversal. see the vulnerability category "Path Traversal" Merak Mail Server with Icewarp, Sep. 10, 2004 This could occur due to a cleansing error that removes a single "../" from "....//" 1000 Weakness ChildOf 23 '....//' (doubled dot dot slash) All Weaknesses in this category are related to schemes that generate numbers or identifiers that are more predictable than required by the application. 1000 Weakness ChildOf 330 Predictability problems A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc. Increase the entropy used to seed a PRNG. Implementation: Perform FIPS 140-1 tests on data to catch obvious entropy problems. Implementation: Consider a PRNG which re-seeds itself, as needed from a high quality pseudo-random output, like hardware devices. CVE-2002-0389 CVE-2001-1141 CVE-2000-0335 DNS resolver library uses predictable IDs, which allows a local attacker to spoof DNS query results. CVE-2005-1636 MFV. predictable filename and insecure permissions allows file modification to execute SQL queries. 1000 Weakness ChildOf 330 1000 Weakness ChildOf 340 Predictable from Observable State All An exact value or random number can be precisely predicted by observing previous values. Increase the entropy used to seed a PRNG. Implementation: Perform FIPS 140-1 tests on data to catch obvious entropy problems. Implementation: Consider a PRNG which re-seeds itself, as needed from a high quality pseudo-random output, like hardware devices. CVE-2002-1463 CVE-1999-0074 Listening TCP ports are sequentially allocated, allowing spoofing attacks. CVE-1999-0077 Predictable TCP sequence numbers allow spoofing. CVE-2000-0335 DNS resolver uses predictable IDs, allowing a local user to spoof DNS query results. 1000 Weakness ChildOf 330 1000 Weakness ChildOf 340 Predictable Exact Value from Previous Values All A relatively small set of likely values or random numbers can be predicted, typically by observing previous values or non-random patterns within the generator. This reduces the amount of effort needed in a brute force attack. Increase the entropy used to seed a PRNG. Implementation: Perform FIPS 140-1 tests on data to catch obvious entropy problems. Implementation: Consider a PRNG which re-seeds itself, as needed from a high quality pseudo-random output, like hardware devices. Michal Zalewski Strange Attractors and TCP/IP Sequence Number Analysis 2001 http://www.bindview.com/Services/Razor/Papers/2001/tcpseq.cfm 1000 Weakness ChildOf 330 1000 Weakness ChildOf 340 Predictable Value Range from Previous Values All The product uses a constant value, name, or reference, but this value can (or should) vary across different environments. Primary (Weakness exists independent of other weaknesses) Resultant (Weakness is typically related to the presence of some other weaknesses) Mutability Increase the entropy used to seed a PRNG. Implementation: Perform FIPS 140-1 tests on data to catch obvious entropy problems. CVE-2002-0980 Component for web browser writes an error message to a known location, which can then be referenced by attackers to process HTML/script in a less restrictive context overlaps default configuration. This is often a factor in attacks on web browsers, in which known or predictable filenames become necessary to exploit browser vulnerabilities. 1000 Weakness ChildOf 340 1000 Weakness ChildOf 398 Static Value in Unpredictable Context All The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data. Terminology Note: "origin validation" could fall under this. 1000 Category ChildOf 254 Insufficient Verification of Data All 4 The software does not properly verify that the source of data or communication is valid. Primary (Weakness exists independent of other weaknesses) Resultant (Weakness is typically related to the presence of some other weaknesses) CVE-2000-1218 DNS server can accept DNS updates from hosts that it did not query, leading to cache poisoning CVE-2005-0877 DNS server can accept DNS updates from hosts that it did not query, leading to cache poisoning CVE-2001-1452 DNS server caches glue records received from non-delegated name servers CVE-2005-2188 user ID obtained from untrusted source (URL) CVE-2003-0174 LDAP service does not verify if a particular attribute was set by the LDAP server CVE-1999-1549 product does not sufficiently distinguish external HTML from internal, potentially dangerous HTML, allowing bypass using special strings in the page title. Overlaps special elements. CVE-2003-0981 product records the reverse DNS name of a visitor in the logs, allowing spoofing and resultant XSS. This is a factor in many weaknesses, both primary and resultant. The problem could be due to design or implementation. This is a fairly general class. 1000 Weakness ChildOf 345 Origin Validation Error All 89 21 75 76 60 59 The software does not verify, or improperly verifies, the cryptographic signature for data. CVE-2002-1796 Does not properly verify signatures for "trusted" entities. CVE-2005-2181 Insufficient verification allows spoofing. CVE-2005-2182 Insufficient verification allows spoofing. CVE-2002-1706 Accepts a configuration file without a Message Integrity Check (MIC) signature. 1000 Weakness ChildOf 345 Improperly Verified Signature All The software has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack. CVE-2001-0860 Product uses IP address provided by a client, instead of obtaining it from the packet headers, allowing easier spoofing. CVE-2004-1950 Web product uses the IP address in the X-Forwarded-For HTTP header instead of a server variable that uses the connecting IP address, allowing filter bypass. BID:15326 Similar to CVE-2004-1950 CVE-2001-0908 Product logs IP address specified by the client instead of obtaining it from the packet headers, allowing information hiding. CVE-2006-1126 PHP application uses IP address from X-Forwarded-For HTTP header, instead of REMOTE_ADDR. 1000 Weakness ChildOf 345 Use of Less Trusted Source All 63 18 73 85 76 86 The software, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted. CVE-2002-0018 Does not verify that trusted entity is authoritative for all entities in its response. 1000 Weakness ChildOf 345 Untrusted Data Appended with Trusted Data All 75 A software system that accepts input in the form of a doubled triple dot slash ('.../...//') without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. This can be used to cause problems for systems that strip out '..' from input in an attempt to remove relative path traversal. see the vulnerability category "Path Traversal" CVE-2005-2169 CVE-2005-0202 ".../....///" bypasses regexp's that remove "./" and "../" This is effective when a programmer uses a "../" regular expression in an attempt to remove sequences. Removing the two "../" sequences from ".../...//" yields "../". 1000 Weakness ChildOf 23 '.../...//' All The software trusts the hostname that is provided when performing a reverse DNS resolution on an IP address, without also performing forward resolution. CVE-2001-1488 Does not do double-reverse lookup to prevent DNS spoofing. CVE-2001-1500 Does not verify reverse-resolved hostnames in DNS. CVE-2000-1221 Authentication bypass using spoofed reverse-resolved DNS hostnames. CVE-2002-0804 Authentication bypass using spoofed reverse-resolved DNS hostnames. CVE-2001-1155 Filter does not properly check the result of a reverse DNS lookup, which could allow remote attackers to bypass intended access restrictions via DNS spoofing. CVE-2004-0892 Reverse DNS lookup used to spoof trusted content in intermediary. CVE-2003-0981 Product records the reverse DNS name of a visitor in the logs, allowing spoofing and resultant XSS. 1000 Weakness ChildOf 345 1000 Weakness ChildOf 654 Improperly Trusted Reverse DNS All Architecture and Design 63 18 73 The software does not properly distinguish between different types of elements in a way that leads to insecure behavior. CVE-2005-2260 Browser user interface does not distinguish between user-initiated and synthetic events. CVE-2005-2801 Product does not compare all required data in two separate elements, causing it to think they are the same, leading to loss of ACLs. Similar to Same Name error. Overlaps others, e.g. Multiple Interpretation Errors. 1000 Weakness ChildOf 345 1000 Weakness PeerOf 436 Insufficient Type Distinction All If integrity check values or "checksums" are omitted from a protocol, there is no way of determining if data has been corrupted in transmission. Medium Integrity: Data that is parsed and used may be corrupted. Non-repudiation: Without a checksum it is impossible to determine if any changes have been made to the data after it was sent. Design: Add an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used. Implementation: Ensure that the checksums present in the protocol design are properly implemented and added to each message before it is sent. C C++ h_addrtype; memcpy((char *) &rserv.sin_addr.s_addr, h->h_addr_list[0], h->h_length); rserv.sin_port= htons(1008); s = socket(AF_INET,SOCK_DGRAM,0); lserv.sin_family = AF_INET; lserv.sin_addr.s_addr = htonl(INADDR_ANY); lserv.sin_port = htons(0); r = bind(s, (struct sockaddr *) &lserv,sizeof(lserv)); sendto(s,important_data,strlen(important_data)+1,0, (struct sockaddr *) &rserv, sizeof(rserv)); while(true) { DatagramPacket rp=new DatagramPacket(rData,rData.length); outSock.receive(rp); String in = new String(p.getData(),0, rp.getLength()); InetAddress IPAddress = rp.getAddress(); int port = rp.getPort(); out = secret.getBytes(); DatagramPacket sp =new DatagramPacket(out,out.length, IPAddress, port); outSock.send(sp); }]]> The failure to include checksum functionality in a protocol removes the first application-level check of data that can be used. The end-to-end philosophy of checks states that integrity checks should be performed at the lowest level that they can be completely implemented. Excluding further sanity checks and input validation performed by applications, the protocol's checksum is the most important level of checksum, since it can be performed more completely than at any previous level and takes into account entire messages, as opposed to single packets. Failure to add this functionality to a protocol specification, or in the implementation of that protocol, needlessly ignores a simple solution for a very significant problem and should never be skipped. 1000 Weakness ChildOf 345 1000 Weakness PeerOf 354 Failure to add integrity check value All Architecture and Design 74 75 39 13 14 If integrity check values or "checksums" are not validated before messages are parsed and used, there is no way of determining if data has been corrupted in transmission. Medium Authentication: Integrity checks usually use a secret key that helps authenticate the data origin. Skipping integrity checking generally opens up the possibility that new data from an invalid source can be injected. Integrity: Data that is parsed and used may be corrupted. Non-repudiation: Without a checksum check, it is impossible to determine if any changes have been made to the data after it was sent. Implementation: Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used. C C++ Java The failure to validate checksums before use results in an unnecessary risk that can easily be mitigated with very few lines of code. Since the protocol specification describes the algorithm used for calculating the checksum, it is a simple matter of implementing the calculation and verifying that the calculated checksum and the received checksum match. If this small amount of effort is skipped, the consequences may be far greater. 1000 Weakness ChildOf 345 1000 Weakness PeerOf 353 Failure to check integrity check value All 75 Software systems should warn users that a potentially dangerous action may occur if the user proceeds. For example, if the user downloads a file from an unknown source and attempts to execute the file on their machine, then the GUI of an application can indicate that the file is unsafe. CVE-1999-1055 Product does not warn user when document contains certain dangerous functions or macros. CVE-1999-0794 Product does not warn user when document contains certain dangerous functions or macros. CVE-2000-0277 Product does not warn user when document contains certain dangerous functions or macros. CVE-2000-0517 Product does not warn user about a certificate if it has already been accepted for a different site. Possibly resultant. CVE-2005-0602 File extractor does not warn user it setuid/setgid files could be extracted. Overlaps privileges/permissions. CVE-2000-0342 E-mail client allows bypass of warning for dangerous attachments via a Windows .LNK file that refers to the attachment. Often resultant, e.g. in unhandled error conditions. Can overlap privilege errors, conceptually at least. 1000 Category ChildOf 355 Product UI does not warn user of unsafe actions All A user interface provides a warning to a user regarding dangerous or sensitive operations, but the warning is not noticeable enough to warrant attention. CVE-2007-1099 User not sufficiently warned if host key mismatch occurs 1000 Category ChildOf 355 1000 Weakness ChildOf 693 Insufficient UI warning of dangerous operations All The software does not properly implement one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique. CVE-2002-0862 Browser does not verify Basic Constraints of a certificate, even though it is required, allowing spoofing of trusted certificates. CVE-2002-0970 Browser does not verify Basic Constraints of a certificate, even though it is required, allowing spoofing of trusted certificates. CVE-2002-1407 Browser does not verify Basic Constraints of a certificate, even though it is required, allowing spoofing of trusted certificates. CVE-2005-0198 Logic error prevents some required conditions from being enforced during Challenge-Response Authentication Mechanism with MD5 (CRAM-MD5). CVE-2004-2163 Shared secret not verified in a RADIUS response packet, allowing authentication bypass by spoofing server replies. CVE-2005-2181 Insufficient verification in VoIP implementation, in violation of standard, allows spoofed messages. CVE-2005-2182 Insufficient verification in VoIP implementation, in violation of standard, allows spoofed messages. AN-2005-2298 Security check not applied to all components, allowing bypass. This is a "missing step" error on the product side, which can overlap weaknesses such as insufficient verification and spoofing. It is frequently found in cryptographic and authentication errors. It is sometimes resultant. This is an implementation error, in which the algorithm/technique requires certain security-related behaviors or conditions that are not implemented or checked properly, thus causing a vulnerability. 1000 Category ChildOf 254 1000 Weakness ChildOf 573 1000 Weakness CanAlsoBe 345 1000 Weakness CanAlsoBe 290 Improperly Implemented Security Check for Standard All Mishandling private information, such as customer passwords or social security numbers, can compromise user privacy and is often illegal. The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account. The code in the example above logs a plaintext password to the filesystem. Although many developers trust the filesystem as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern. Privacy violations occur when: 1. Private user information enters the program. 2. The data is written to an external location, such as the console, file system, or network. Private data can enter a program in a variety of ways: - Directly from the user in the form of a password or personal information - Accessed from a database or other data store by the application - Indirectly from a partner or other third party Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private. Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer e-mail addresses to a spammer marketing an offshore gambling web site [23]. In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations: - Safe Harbor Privacy Framework [24] - Gramm-Leach Bliley Act (GLBA) [11] - Health Insurance Portability and Accountability Act (HIPAA) [16] - California SB-1386 [6] J. Oates AOL man pleads guilty to selling 92m email addies The Register 2005 http://www.theregister.co.uk/2005/02/07/aol_email_theft/ U.S. Department of Commerce Safe Harbor Privacy Framework http://www.export.gov/safeharbor/ Federal Trade Commission Financial Privacy: The Gramm-Leach Bliley Act (GLBA) http://www.ftc.gov/privacy/glbact/index.html U.S. Department of Human Services Health Insurance Portability and Accountability Act (HIPAA) http://www.hhs.gov/ocr/hipaa/ Government of the State of California California SB-1386 2002 http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html 1000 Category ChildOf 254 1000 Weakness ChildOf 668 Privacy Violation All The software, when constructing file or directory names from input, does not properly sanitize absolute path sequences such as "/path/here." see "Path Traversal" (CWE-22) 1000 Weakness ChildOf 22 Absolute Path Traversal All Security based on event locations are insecure and can be spoofed. High Authorization: If one trusts the system-event information and executes commands based on it, one could potentially take actions based on a spoofed identity. Design through Implementation: Never trust or rely any of the information in an Event for security. Java Events are a messaging system which may provide control data to programs listening for events. Events often do not have any type of authentication framework to allow them to be verified from a trusted source. Any application, in Windows, on a given desktop can send a message to any window on the same desktop. There is no authentication framework for these messages. Therefore, any message can be used to manipulate any process on the desktop if the process does not check the validity and safeness of those messages. 1000 Category ChildOf 254 Trust of system event data All The code does not properly control when an unmodifiable state is required between two operations, but a timing window exists in which the state can be modified by an untrusted actor or process. 635 Weakness ChildOf 691 1000 Category ChildOf 361 635 View ChildOf 635 Race Conditions 26 29 A race condition exists when an application checks the status of a file or directory before accessing it, but that file can be replaced with a link, causing the application to act on an unexpected file. This is already covered by the weakness "Link Following". It is included here because so many people associate race conditions with link problems; however, not all link following issues involve race conditions. 1000 Weakness ChildOf 362 1000 Weakness CanAlsoBe 59 Race condition enabling link following All 26 Race conditions occur frequently in signal handlers, since they are asynchronous actions. These race conditions may have any number of root-causes and symptoms. Signals, interprocess communication Medium System Process Authorization: It may be possible to execute arbitrary code through the use of a write-what-where condition. Integrity: Signal race conditions often result in data corruption. Requirements specification: A language might be chosen, which is not subject to this flaw, through a guarantee of reentrant code. Design: Design signal handlers to only set flags rather than perform complex functionality. Implementation: Ensure that non-reentrant functions are not found in signal handlers. Also, use sanity checks to ensure that state is consistent be performing asynchronous actions which effect the state of execution. C #include #include #include void *global1, *global2; char *what; void sh(int dummy) { syslog(LOG_NOTICE,"%s\n",what); free(global2); free(global1); sleep(10); exit(0); } int main(int argc,char* argv[]) { what=argv[1]; global1=strdup(argv[2]); global2=malloc(340); signal(SIGHUP,sh); signal(SIGTERM,sh); sleep(10); exit(0); }]]> CVE-2001-1349 CVE-2004-0794 CVE-2004-2259 Signal race conditions are a common issue that have only recently been seen as exploitable. These issues occur when non-reentrant functions, or state-sensitive actions occur in the signal handler, where they may be called at any time. If these functions are called at an inopportune moment -- such as while a non-reentrant function is already running --, memory corruption occurs that may be exploitable. Another signal race condition commonly found occurs when free is called within a signal handler, resulting in a double free and therefore a write-what-where condition. This is a perfect example of a signal handler taking actions which cannot be accounted for in state. Even if a given pointer is set to NULL after it has been freed, a race condition still exists between the time the memory was freed and the pointer was set to NULL. This is especially prudent if the same signal handler has been set for more than one signal -- since it means that the signal handler itself may be reentered. Probably under-studied. 1000 Weakness ChildOf 362 1000 Weakness PeerOf 415 1000 Weakness PeerOf 416 1000 Weakness PeerOf 479 1000 Weakness PeerOf 123 631 Category ChildOf 634 Signal handler race condition Signal Handling Race Conditions Race condition in signal handler C C++ The code contains a switch statement in which the switched variable can be modified while the switch is still executing, resulting in unexpected behavior. Medium Undefined: This flaw will result in the system state going out of sync. Implementation: Variables that may be subject to race conditions should be locked for the duration of any switch statements. C C++ #include int main(argc,argv){ struct stat *sb; time_t timer; lstat("bar.sh",sb); printf("%d\n",sb->st_ctime); switch(sb->st_ctime % 2){ case 0: printf("One option\n");break; case 1: printf("another option\n");break; default: printf("huh\n");break; } return 0; }]]> This issue is particularly important in the case of switch statements that involve fall-through style case statements -- ie., those which do not end with break. If the variable which we are switching on change in the course of execution, the actions carried out may place the state of the process in a contradictory state or even result in memory corruption. For this reason, it is important to ensure that all variables involved in switch statements are locked before the statement starts and are unlocked when the statement ends. 1000 Weakness ChildOf 362 1000 Weakness PeerOf 364 1000 Weakness PeerOf 366 Race condition in switch C C++ Java .NET If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined. Medium System Process Integrity: The main problem is that -- if a lock is overcome -- data could be altered in a bad state. Design: Use locking functionality. This is the recommended solution. Implement some form of locking mechanism around code which alters or reads persistent data in a multi-threaded environment. Design: Create resource-locking sanity checks. If no inherent locking mechanisms exist, use flags and signals to enforce your own blocking scheme when resources are being used by other threads of execution. C C++ foo) foo = num; return foo; }]]> Java 1000 Weakness ChildOf 362 1000 Category ChildOf 557 631 Category ChildOf 634 Race condition within a thread C C++ Java .NET 26 29 Time-of-check, time-of-use race conditions occur when between the time in which a given resource (or its reference) is checked, and the time that resource is used, a change occurs in the resource to invalidate the results of the check. Low to Medium Access control: The attacker can gain access to otherwise unauthorized resources. Authorization: race conditions such as this kind may be employed to gain read or write access to resources which are not normally readable or writable by the user in question. Integrity: The resource in question, or other resources (through the corrupted one), may be changed in undesirable ways by a malicious user. Accountability: If a file or other resource is written in this method, as opposed to in a valid way, logging of the activity may not occur. Non-repudiation: In some cases it may be possible to delete files a malicious user might not otherwise have access to, such as log files. The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check. When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement. Do not rely on user-specified input to determine what path to format. Limit the interleaving of operations on files from multiple processes. Limit the spread of time (cycles) between the check and use of a resource. Recheck the resource after the use call to verify that the action was taken appropriately. Design: Ensure that some environmental locking mechanism can be used to protect resources effectively. Implementation: Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use. Example 1: C C++ st_mtimespec==...) { print("Now updating things\n"); updateThings(); }]]> Potentially the file could have been updated between the time of the check and the lstat, especially since the printf has latency. Example 2 : The following code is from a program installed setuid root. The program performs certain file operations on behalf of non-privileged users, and uses access checks to ensure that it does not use its root privileges to perform operations that should otherwise be unavailable the current user. The program uses the access() system call to check if the person running the program has permission to access the specified file before it opens the file and performs the necessary operations. The call to access() behaves as expected, and returns 0 if the user running the program has the necessary permissions to write to the file, and -1 otherwise. However, because both access() and fopen() operate on filenames rather than on file handles, there is no guarantee that the file variable still refers to the same file on disk when it is passed to fopen() that it did when it was passed to access(). If an attacker replaces file after the call to access() with a symbolic link to a different file, the program will use its root privileges to operate on the file even if it is a file that the attacker would otherwise be unable to modify. By tricking the program into performing an operation that would otherwise be impermissible, the attacker has gained elevated privileges. This type of vulnerability is not limited to programs with root privileges. If the application is capable of performing any operation that the attacker would not otherwise be allowed perform, then it is a possible target. CVE-2003-0813 CVE-2004-0594 A race condition is caused by the timing of events within a piece of software. Race conditions typically are associated with synchronization errors that provide a window of opportunity during which one process can interfere with another, possibly introducing a security vulnerability. A race condition typically means a pair of routine calls that happen sequentially in a program which, if not performed atomically (without interruption by another thread or process on the computer), could become a security vulnerability. A typical example is a call to determine the access rights of a file, and a subsequent call to write or read of that file based on the access. If the process is interrupted between the two calls and the file is rewritten or modified during the interruption, the second call may be reading the wrong information or writing to an inappropriate file Note that TOCTOU issues do not always involve symlinks, and not every symlink issue is a TOCTOU problem. Non-symlink TOCTOU issues are not reported frequently, but they are likely to occur in code that attempts to be secure. 1000 Weakness ChildOf 362 1000 Weakness PeerOf 373 630 View ChildOf 630 Time-of-check Time-of-use race condition File Access Race Conditions: TOCTOU Time of check, time of use race condition All 27 29 A product performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries, but a race condition allows an attacker to modify or misrepresent the product's behavior during the switch. CVE-2004-2260 Browser updates address bar as soon as user clicks on a link instead of when the page has loaded, allowing spoofing by redirecting to another page using onUnload method. ** this is one example of the role of "hooks" and context switches, and should be captured somehow - also a race condition of sorts ** CVE-2004-0191 XSS when web browser executes Javascript events in the context of a new page while it's being loaded, allowing interaction with previous page in different domain. CVE-2004-2491 Web browser fills in address bar of clicked-on link before page has been loaded, and doesn't update afterward. This is commonly seen in web browser vulnerabilities, in which the attacker can perform certain actions while the browser is transitioning from a trusted to an untrusted domain, or vice versa, and the browser performs the actions on one domain using the trust level and resources of the other domain. Can be resultant or primary. Can overlap signal handler race conditions. Under-studied as a concept. Frequency unknown; few vulnerability reports give enough detail to know when a context switching race condition is a factor. 1000 Weakness ChildOf 362 1000 Weakness CanAlsoBe 364 Context Switching Race Condition All 26 29 The product divides a value by zero. This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height. Medium Availability: A Divide by Zero results in a crash. CVE-2007-3268 Invalid size value leads to divide by zero. CVE-2007-2723 "Empty" content triggers divide by zero. CVE-2007-2237 Height value of 0 triggers divide by zero. Integer overflows can be primary to buffer overflows. 1000 Category ChildOf 189 A software system that accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation can allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Traversal" CVE-2002-1345 Multiple FTP clients write arbitrary files via absolute paths in server responses CVE-2001-1269 ZIP file extractor allows full path CVE-2002-1818 Path traversal using absolute pathname CVE-2002-1913 Path traversal using absolute pathname CVE-2005-2147 Path traversal using absolute pathname 1000 Weakness ChildOf 36 /absolute/pathname/here All If the revocation status of a certificate is not checked before each privilege requiring action, the system may be subject to a race condition, in which their certificate may be used before it is checked for revocation. Medium Authentication: Trust may be assigned to an entity who is not who it claims to be. Integrity: Data from an untrusted (and possibly malicious) source may be integrated. Confidentiality: Date may be disclosed to an entity impersonating a trusted entity, resulting in information disclosure. Design: Ensure that certificates are checked for revoked status before each use of a protected resource. C C++ If a certificate is revoked after the initial check, all subsequent actions taken with the owner of the revoked certificate will loose all benefits guaranteed by the certificate. In fact, it is almost certain that the use of a revoked certificate indicates malicious activity. If the certificate is checked before each access of a protected resource, the delay subject to a possible race condition becomes almost negligible and significantly reduces the risk associated with this issue. 1000 Weakness ChildOf 362 1000 Weakness PeerOf 296 1000 Weakness PeerOf 297 1000 Weakness PeerOf 298 1000 Weakness PeerOf 299 Race condition in checking for certificate revocation All 26 29 The software does not properly determine which state it is in, causing it to assume it is in state X when in fact it is in state Y, causing it to perform incorrect operations in a security-relevant manner. This conceptually overlaps other categories such as insufficient verification, but this refers to the product's "self-perception." Probably resultant from other weaknesses such as unhandled error conditions, inability to handle out-of-order steps, multiple interpretation errors, etc. 1000 Category ChildOf 371 Incomplete Internal State Distinction All 74 56 State synchronization refers to a set of flaws involving contradictory states of execution in a process which result in undefined behavior. Medium to High Undefined: Depending on the nature of the state of corruption, any of the listed consequences may result. Implementation: Pay attention to asynchronous actions in processes and make copious use of sanity checks in systems that may be subject to synchronization errors. C C++ Java The class of synchronization errors is large and varied, but all rely on the same essential flaw. The state of the system is not what the process expects it to be at a given time. Obviously, the range of possible symptoms is enormous, as is the range of possible solutions. The flaws presented in this section are some of the most difficult to diagnose and fix. It is more important to know how to characterize specific flaws than to gain information about them. 1000 Weakness ChildOf 662 1000 Category ChildOf 371 State synchronization error All Sending non-cloned mutable data as an argument may result in that data being altered or deleted by the called function, thereby putting the calling function into an undefined state. Medium Integrity: Potentially data could be tampered with by another function which should not have been tampered with. Implementation: Pass in data which should not be altered as constant or immutable. Implementation: Clone all mutable data before returning references to it. This is the preferred mitigation. This way -- regardless of what changes are made to the data -- a valid copy is retained for use by the class. C C++ In this example, bar and baz will be passed by reference to doOtherStuff() which may change them. In situations where unknown code is called with references to mutable data, this external code may possibly make changes to the data sent. If this data was not previously cloned, you will be left with modified data which may, or may not, be valid in the context of execution. 1000 Category ChildOf 371 1000 Weakness ChildOf 668 Mutable objects passed by reference C C++ Java .NET Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function, thereby putting the class in an undefined state. Medium Access Control / Integrity: Potentially data could be tampered with by another function which should not have been tampered with. Implementation: Pass in data which should not be altered as constant or immutable. Implementation: Clone all mutable data before returning references to it. This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class. C C++ Java In situations where functions return references to mutable data, it is possible that this external code, which called the function, may make changes to the data sent. If this data was not previously cloned, you will be left with modified data which may, or may not, be valid in the context of the class in question. 1000 Category ChildOf 371 1000 Weakness ChildOf 668 Passing mutable objects to an untrusted method C C++ Java .NET Creating and using insecure temporary files can leave application and system data vulnerable to attack. Example: The following code uses a temporary file for storing intermediate data gathered from the network before it is processed. 0)&(amt!=0)) amt = fwrite(recvbuf,1,DATA_SIZE,tmp); } ...]]> This otherwise unremarkable code is vulnerable to a number of different attacks because it relies on an insecure method for creating temporary files. The vulnerabilities introduced by this function and others are described in the following sections. The most egregious security problems related to temporary file creation have occurred on Unix-based operating systems, but Windows applications have parallel risks. This section includes a discussion of temporary file creation on both Unix and Windows systems. Methods and behaviors can vary between systems, but the fundamental risks introduced by each are reasonably constant. Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and Windows® API. Most of these functions are vulnerable to various forms of attacks. The functions designed to aid in the creation of temporary files can be broken into two groups based whether they simply provide a filename or actually open a new file. - Group 1 – "Unique" Filenames: The first group of C Library and WinAPI functions designed to help with the process of creating temporary files do so by generating a unique file name for a new temporary file, which the program is then supposed to open. This group includes C Library functions like tmpnam(), tempnam(), mktemp() and their C++ equivalents prefaced with an _ (underscore) as well as the GetTempFileName() function from the Windows API. This group of functions suffers from an underlying race condition on the filename chosen. Although the functions guarantee that the filename is unique at the time it is selected, there is no mechanism to prevent another process or an attacker from creating a file with the same name after it is selected but before the application attempts to open the file. Beyond the risk of a legitimate collision caused by another call to the same function, there is a high probability that an attacker will be able to create a malicious collision because the filenames generated by these functions are not sufficiently randomized to make them difficult to guess. If a file with the selected name is created, then depending on how the file is opened the existing contents or access permissions of the file may remain intact. If the existing contents of the file are malicious in nature, an attacker may be able to inject dangerous data into the application when it reads data back from the temporary file. If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker. On Unix based systems an even more insidious attack is possible if the attacker pre-creates the file as a link to another important file. Then, if the application truncates or writes data to the file, it may unwittingly perform damaging operations for the attacker. This is an especially serious threat if the program operates with elevated permissions. Finally, in the best case the file will be opened with the a call to open() using the O_CREAT and O_EXCL flags or to CreateFile() using the CREATE_NEW attribute, which will fail if the file already exists and therefore prevent the types of attacks described above. However, if an attacker is able to accurately predict a sequence of temporary file names, then the application may be prevented from opening necessary temporary storage causing a denial of service (DoS) attack. This type of attack would not be difficult to mount given the small amount of randomness used in the selection of the filenames generated by these functions. - Group 2 – "Unique" Files: The second group of C Library functions attempts to resolve some of the security problems related to temporary files by not only generating a unique file name, but also opening the file. This group includes C Library functions like tmpfile() and its C++ equivalents prefaced with an _ (underscore), as well as the slightly better-behaved C Library function mkstemp(). The tmpfile() style functions construct a unique filename and open it in the same way that fopen() would if passed the flags "wb+", that is, as a binary file in read/write mode. If the file already exists, tmpfile() will truncate it to size zero, possibly in an attempt to assuage the security concerns mentioned earlier regarding the race condition that exists between the selection of a supposedly unique filename and the subsequent opening of the selected file. However, this behavior clearly does not solve the function's security problems. First, an attacker can pre-create the file with relaxed access-permissions that will likely be retained by the file opened by tmpfile(). Furthermore, on Unix based systems if the attacker pre-creates the file as a link to another important file, the application may use its possibly elevated permissions to truncate that file, thereby doing damage on behalf of the attacker. Finally, if tmpfile() does create a new file, the access permissions applied to that file will vary from one operating system to another, which can leave application data vulnerable even if an attacker is unable to predict the filename to be used in advance. Finally, mkstemp() is a reasonably safe way create temporary files. It will attempt to create and open a unique file based on a filename template provided by the user combined with a series of randomly generated characters. If it is unable to create such a file, it will fail and return -1. On modern systems the file is opened using mode 0600, which means the file will be secure from tampering unless the user explicitly changes its access permissions. However, mkstemp() still suffers from the use of predictable file names and can leave an application vulnerable to denial of service attacks if an attacker causes mkstemp() to fail by predicting and pre-creating the filenames to be used. 1000 Category ChildOf 376 Insecure Temporary File All Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack. High Confidentiality: If the temporary file can be read, by the attacker, sensitive information may be in that file which could be revealed. Authorization: If that file can be written to by the attacker, the file might be moved into a place to which the attacker does not have access. This will allow the attacker to gain selective resource access-control privileges. Tempfile creation should be done in a safe way. To be safe, the temp file function should open up the temp file with appropriate access control. The temp file function should also retain this quality, while being resistant to race conditions. Requirements specification: Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible. Implementation: Ensure that you use proper file permissions. This can be achieved by using a safe temp file function. Temporary files should be writable and readable only by the process which own the file. Implementation: Randomize temporary file names. This can also be achieved by using a safe temp-file function. This will ensure that temporary files will not be created in predictable places. C C++ The temp file created in the above code is always readable and writable by all users. Java This temp file is readable by all users. Depending on the data stored in the temporary file, there is the potential for an attacker to gain an additional input vector which is trusted as non-malicious. It may be possible to make arbitrary changes to data structures, user information, or even process ownership. 1000 Category ChildOf 376 1000 Category ChildOf 275 Improper temp file opening All On some operating systems, the fact that the temp file exists may be apparent to any user. Low Confidentiality: Since the file is visible and the application which is using the temp file could be known, the attacker has gained information about what the user is doing at that time. Requirements specification: Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible. Implementation: Try to store sensitive tempfiles in a directory which is not world readable -- i.e., per-user directories. Implementation: Avoid using vulnerable temp file functions. C C++ In cygwin and some older unixes one can ls /tmp and see that this temp file exists. Java This temp file is readable by all users. Since the file is visible, the application that is using the temp file could be known. If one has access to list the processes on the system, the attacker has gained information about what the user is doing at that time. By correlating this with the applications the user is running, an attacker could potentially discover what a user's actions are. From this, higher levels of security could be breached. 1000 Category ChildOf 376 1000 Weakness ChildOf 668 Guessed or visible temporary file All A software system that accepts input in the form of a backslash absolute path ('\absolute\pathname\here') without appropriate validation can allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Traversal" CVE-1999-1263 CVE-2003-0753 CVE-2002-1344 CVE-2002-1525 CVE-2000-0614 1000 Weakness ChildOf 36 \absolute\pathname\here ('backslash absolute path') All A J2EE application uses System.exit(), which also shuts down its container. Access to a function that can shut down the application is an avenue for Denial of Service (DoS) attacks. The shutdown function should be a privileged function available only to a properly authorized administrative user. Any other possible cause of a shutdown is generally a security vulnerability. (In rare cases, the intended security policy calls for the application to halt as a damage control measure when it determines that an attack is in progress.) Web applications should not call methods that cause the virtual machine to exit, such as System.exit(). Web applications should also not throw any Throwables to the application server as this may adversely affect the container. Non-web applications may have a main() method that contains a System.exit(), but generally should not call System.exit() from other locations in the code. It is never a good idea for a web application to attempt to shut down the application container. A call to System.exit() is probably part of leftover debug code or code imported from a non-J2EE application. 1000 Weakness ChildOf 691 1000 Category ChildOf 381 J2EE Bad Practices: System.exit() Java Thread management in a Web application is forbidden in some circumstances and is always highly error prone. System Process For EJB, use framework approaches for parallel execution, instead of using threads. Thread management in a web application is forbidden by the J2EE standard in some circumstances and is always highly error prone. Managing threads is difficult and is likely to interfere in unpredictable ways with the behavior of the application container. Even without interfering with the container, thread management usually leads to bugs that are hard to detect and diagnose like deadlock, race conditions, and other synchronization errors. 1000 Category ChildOf 381 631 Category ChildOf 634 J2EE Bad Practices: Threads Java Covert channels are frequently classified as either storage or timing channels. Timing channels convey information by modulating some aspect of system behavior over time, so that the program receiving the information can observe system behavior (e.g., the system's paging rate, the time a certain transaction requires to execute, the time it takes to gain access to a shared bus) and infer protected information. Medium Confidentiality: Information leakage. Design: Whenever possible, specify implementation strategies that do not introduce time variances in operations. Implementation: Often one can artificially manipulate the time which operations take or -- when operations occur -- can remove information from the attacker. Python len(typed_pw): return 0 for i in len(actual_pw): if actual_pw[i] <> typed_pw[i]: return 0 return 1 ]]> In this example, the attacker can observe how long an authentication takes when the user types in the correct password. When the attacker tries his own values, he can first try strings of various length. When he finds a string of the right length, the computation will take a bit longer because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when he guesses the first character right, the computation will take longer than when he guesses wrong. Such an attack can break even the most sophisticated password with a few hundred guesses. Note that, in this example, the actual password must be handled in constant time, as far as the attacker is concerned, even if the actual password is of an unusual length. This is one reason why it is good to use an algorithm that, among other things, stores a seeded cryptographic one-way hash of the password, then compare the hashes, which will always be of the same length. Sometimes simply knowing when data is sent between parties can provide a malicious user with information that should be unauthorized. Other times, externally monitoring the timing of operations can reveal sensitive data. For example, some cryptographic operations can leak their internal state if the time it takes to perform the operation changes, based on the state. In such cases, it is good to switch algorithms or implementation techniques. It is also reasonable to add artificial stalls to make the operation take the same amount of raw CPU time in all cases. 1000 Category ChildOf 361 1000 Weakness ChildOf 514 Timing Covert Timing Channel All A constant symbolic reference to an object is used, even though the reference can resolve to a different object over time. Access control: The attacker can gain access to otherwise unauthorized resources. Authorization: Race conditions such as this kind may be employed to gain read or write access to resources not normally readable or writable by the user in question. Integrity: The resource in question, or other resources (through the corrupted one) may be changed in undesirable ways by a malicious user. Accountability: If a file or other resource is written in this method, as opposed to a valid way, logging of the activity may not occur. Non-repudiation: In some cases it may be possible to delete files that a malicious user might not otherwise have access to -- such as log files. 1000 Category ChildOf 361 1000 Weakness PeerOf 367 1000 Weakness PeerOf 610 1000 Weakness PeerOf 486 Symbolic name not mapping to correct object All The software does not properly handle or manage a signal. System Process CVE-2002-2039 unhandled SIGSERV signal allows core dump CVE-1999-1224 SIGABRT (abort) signal not properly handled, causing core dump. CVE-2002-2039 SIGSERV (invalid memory reference) signal causes core dump. CVE-2004-1014 Remote attackers cause a crash using early connection termination, which generates SIGPIPE signal. CVE-2005-2377 Library does not handle a SIGPIPE signal when a server becomes available during a search query. Overlaps unchecked error condition? CVE-2002-0839 SIGUSR1 can be sent as root from non-root process. CVE-1999-1441 Kernel does not prevent users from sending SIGIO signal, which causes crash in applications that do not handle it. Overlaps privileges. CVE-2000-0747 Script sends wrong signal to a process and kills it. CVE-1999-1326 Interruption of operation causes signal to be handled incorrectly, leading to crash. CVE-2001-1180 Shared signal handlers not cleared when executing a process. Overlaps initialization error. CVE-2004-2069 Privileged process does not properly signal unprivileged process after session termination, leading to connection consumption. CVE-2004-2259 SIGCHLD signal to FTP server can cause crash under heavy load while executing non-re-entrant functions like malloc/free. Possibly signal handler race condition? CVE-2005-0893 Certain signals implemented with unsafe library calls. Several sub-categories could exist, but this needs more study. Some sub-categories are: - unhandled signals - untrusted signals - sending wrong signals Signal Handler Race Conditions are covered elsewhere. 1000 Category ChildOf 361 631 Category ChildOf 634 Signal Errors C C++ An attacker can inject a drive letter or Windows volume letter ('C:dirname') into a software system to potentially redirect access to an unintended location or arbitrary file. see the vulnerability category "Path Traversal" CVE-2001-0038 CVE-2001-0255 CVE-2001-0687 CVE-2001-0933 CVE-2002-0466 CVE-2002-1483 CVE-2004-2488 FTP server read/access arbitrary files using "C:\" filenames 1000 Weakness ChildOf 36 'C:dirname' or C: (Windows volume or 'drive letter') All Sometimes an error is detected, and bad or no action is taken. Medium Implementation: Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment. Subject the software to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing. C C++ Java If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program. 1000 Category ChildOf 389 1000 Weakness CanPrecede 401 Improper error handling All 83 66 7 Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed. Medium Requirements Specification: The choice between a language which has named or unnamed exceptions needs to be done. While unnamed exceptions exacerbate the chance of not properly dealing with an exception, named exceptions suffer from the up call version of the weak base class problem. Requirements Specification: A language can be used which requires, at compile time, to catch all serious exceptions. However, one must make sure to use the most current version of the API as new exceptions could be added. Implementation: Catch all relevant exceptions. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment. The following code excerpt ignores a rarely-thrown exception from doExchange(). If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior. Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break. Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions. 1000 Category ChildOf 389 630 View ChildOf 630 Unchecked Return Value Empty Catch Block Uncaught exception All The software encounters an error but does not return a status code or return value to indicate that an error has occurred. CVE-2004-0063 Function returns "OK" even if another function returns a different status code than expected, leading to accepting an invalid PIN number. CVE-2002-1446 Error checking routine in PKCS#11 library returns "OK" status even when invalid signature is detected, allowing spoofed messages. CVE-2002-0499 Kernel function truncates long pathnames without generating an error, leading to operation on wrong directory. CVE-2005-2459 Function returns non-error value when a particular erroneous condition is encountered, leading to resultant NULL dereference. May be primary or resultant. 1000 Category ChildOf 389 Missing Error Status Code All A function or operation returns an incorrect return value or status code that does not indicate an error, but causes the product to modify its behavior based on the incorrect result, in a way that leads to unpredictable behavior. CVE-2003-1132 DNS server returns wrong response code for non-existent AAAA record, which effectively says that the domain is inaccessible. CVE-2001-1509 Hardware-specific implementation of system call causes incorrect results from geteuid. CVE-2001-1559 System call returns wrong value, leading to a resultant NULL dereference. This can produce resultant vulnerabilities, and it might overlap other categories. 1000 Category ChildOf 389 Wrong Status Code All The software does not properly check when a function or operation returns a value that is legitimate for the function, but is not expected by the software. CVE-2004-1395 Certain packets (zero byte and other lengths) cause a recvfrom call to produce an unexpected return code that causes a server's listening loop to exit. CVE-2002-2124 Unchecked return code from recv() leads to infinite loop. CVE-2005-2553 Kernel function does not properly handle when a null is returned by a function call, causing it to call another function that it shouldn't. CVE-2005-1858 Memory not properly cleared when read() function call returns fewer bytes than expected. CVE-2000-0536 Bypass access restrictions when connecting from IP whose DNS reverse lookup does not return a hostname. CVE-2001-0910 Bypass access restrictions when connecting from IP whose DNS reverse lookup does not return a hostname. CVE-2004-2371 Game server doesn't check return values for functions that handle text strings and associated size values. CVE-2005-1267 Resultant infinite loop when function call returns -1 value. Usually primary, but can be resultant from issues such as behavioral change or API abuse. This can produce resultant vulnerabilities. 1000 Category ChildOf 389 Unexpected Status Code or Return Value All Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer. Do not extensively rely on catching exceptions (especially for validating user input) to handle errors. Handling exceptions can decrease the performance of an application. The following code mistakenly catches a NullPointerException. Programmers typically catch NullPointerException under three circumstances: 1. The program contains a null pointer dereference. Catching the resulting exception was easier than fixing the underlying problem. 2. The program explicitly throws a NullPointerException to signal an error condition. 3. The code is part of a test harness that supplies unexpected input to the classes under test. Of these three circumstances, only the last is acceptable. 1000 Category ChildOf 389 1000 Weakness ChildOf 691 Catching NullPointerException Java Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. The following code excerpt handles three types of exceptions in an identical fashion. At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows: try { doExchange(); } catch (Exception e) { logger.error("doExchange failed", e); } However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent. Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention. 1000 Category ChildOf 389 Overly-Broad Catch Block C C++ Java .NET Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. The following method throws three types of exceptions. While it might seem tidier to write public void doExchange() throws Exception { ... } doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement. Declaring a method to throw Exception or Throwable makes it difficult for callers to do good error handling and error recovery. Java's exception mechanism is set up to make it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system. 1000 Category ChildOf 389 Overly-Broad Throws Declaration C C++ Java .NET The code has features that do not directly introduce a weakness or vulnerability, but indicate that the product has not been carefully developed or maintained. Programs are more likely to be secure when good development practices are followed. If a program is complex, difficult to maintain, not portable, or shows evidence of neglect, then there is a higher likelihood that weaknesses are buried in the code. 1000 Category ChildOf 18 Code Quality An attacker can inject a Windows UNC share ('\\UNC\share\name') into a software system to potentially redirect access to an unintended location or arbitrary file. see the vulnerability category "Path Traversal" CVE-2001-0687 1000 Weakness ChildOf 36 '\\UNC\share\name\' (Windows UNC share) All The application is susceptible to generating and/or accepting an excessive amount of requests that could potentially exhaust limited resources, such as memory, file system storage, database connection pool entries, or CPU. This can ultimately lead to a denial of service that could prevent valid users from accessing the application. Very high Availability: The most common result of resource exhaustion is denial of service. Access control: In some cases it may be possible to force a system to "fail open" in the event of resource exhaustion. Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold. Design: Ensure that protocols have specific limits of scale placed on them. Implementation: Ensure that all failures in resource allocation place the system into a safe posture. Implementation: Fail safely when a resource exhaustion occurs. Java C C++ There are no limits to runnables/forks. Potentially an attacker could cause resource problems very quickly. Resource exhaustion issues are generally understood but are far more difficult to successfully prevent. Taking advantage of various entry points, an attacker could craft a wide variety of requests that would cause the site to consume resources. Database queries that take a long time to process are good DoS targets. An attacker would have to write a few lines of Perl code to generate enough traffic to exceed the site's ability to keep up. This would effectively prevent authorized users from using the site at all. Resources can be exploited simply by ensuring that the target machine must do much more work and consume more resources in order to service a request than the attacker must do to initiate a request. Prevention of these attacks requires either that the target system: - either recognizes the attack and denies that user further access for a given amount of time; - or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, he may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. The final concern that must be discussed about issues of resource exhaustion is that of systems which "fail open." This means that in the event of resource consumption, the system fails in such a way that the state of the system -- and possibly the security functionality of the system -- is compromised. A prime example of this can be found in old switches that were vulnerable to "macof" attacks (so named for a tool developed by Dugsong). These attacks flooded a switch with random IP and MAC address combinations, therefore exhausting the switch's cache, which held the information of which port corresponded to which MAC addresses. Once this cache was exhausted, the switch would fail in an insecure way and would begin to act simply as a hub, broadcasting all traffic on all ports and allowing for basic sniffing attacks. 1000 Category ChildOf 399 Resource exhaustion (file descriptor, disk space, sockets, ...) All 82 2 The software does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory. This is often triggered by improper handling of malformed data or unexpectedly interrupted sessions. Memory management Medium Memory Availability: If an attacker can determine the cause of the memory leak, then the attacker may be able to cause the application to leak quickly and therefore cause the application to crash. Pre-design: Use a language or compiler that performs automatic bounds checking. Design: Use an abstraction library to abstract away risky APIs. Not a complete solution. Pre-design through Build: The Boehm-Demers-Weiser Garbage Collector or valgrind can be used to detect leaks in code. This is not a complete solution as it is not 100% effective. Example 1: The following C function leaks a block of allocated memory if the call to read() fails to return the expected number of bytes: C Example 2: In C: C Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory. CVE-2005-3119 Memory leak because function does not free() an element of a data structure. CVE-2004-0427 Memory leak when counter variable is not decremented. CVE-2002-0574 Memory leak when counter variable is not decremented. CVE-2005-3181 Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code. CVE-2004-0222 Memory leak via unknown manipulations as part of protocol test suite. CVE-2001-0136 Memory leak via a series of the same command. This is often a resultant weakness due to improper handling of malformed data or early termination of sessions. Terminology Note: "memory leak" has sometimes been used to describe other kinds of issues, e.g. for information leaks in which the contents of memory are inadvertently leaked (CVE-2003-0400 is one such example of this terminology conflict). Memory leaks have two common and sometimes overlapping causes: - Error conditions and other exceptional circumstances. - Confusion over which part of the program is responsible for freeing the memory Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing the program) or take advantage of other unexpected program behavior resulting from a low memory condition [30]. J. Whittaker H. Thompson How to Break Software Security Addison Wesley 2003 1000 Weakness ChildOf 404 1000 Category ChildOf 399 630 View ChildOf 630 631 Category ChildOf 633 Memory leak Memory Leak Failure to deallocate data C C++ A weakness where the code path has: 1. start statement that allocates dynamically allocated memory resource 2. end statement that loses identity of the dynamically allocated memory resource creating situation where dynamically allocated memory resource is never relinquished Where “loses” is defined through the following scenarios: 1. identity of the dynamic allocated memory resource never obtained 2. identity of the dynamic allocated memory resource obtained but got re-written (missing beyond recovery) 3. identity of the dynamic allocated memory resource obtained but never passed on to function for memory resource release 4. the statement assigns another value to the last data element that stored the identity of the dynamically allocated memory resource (no more aliases remain) 5. the last data element that stored the identity of the dynamically allocated resource has reached the end of its scope at the statement The software makes resources available to untrusted parties when those resources are only intended to be accessed by the software. 1000 Category ChildOf 399 1000 Weakness ChildOf 668 Resource leaks A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors. System Process CVE-2002-0677 File descriptor argument is used as an array index. CVE-2004-1033 File descriptor leak allows read of restricted files. CVE-2000-0094 Access to restricted resource using modified file descriptor for stderr. CVE-2002-0638 Open file descriptor used as alternate channel in complex race condition. CVE-2002-0766 MFV. attacker fills file descriptor table then closes a descriptor e.g. for stderr, which leads to unhandled error condition when privileged program can't assign an alternate descriptor. CVE-2000-1108 Does not verify that file descriptor is a TTY, allowing file corruption via symlink. CVE-2001-1047 Race condition allows one thread to set a file descriptor to NULL, creating stale handle in the other thread. CVE-2003-0489 Program does not fully drop privileges after creating a file descriptor, which allows access to the descriptor via a separate vulnerability. CVE-2003-0937 User bypasses restrictions by obtaining a file descriptor then calling setuid program, which does not close the descriptor. CVE-2002-1866 File descriptors not closed for HTTP 404 messages, leading to resource consumption. CVE-2005-1922 File descriptor consumption after input triggers errors. CVE-2004-2215 Terminal manager does not properly close file descriptors, allowing attackers to access terminals of other users. 1000 Weakness ChildOf 402 631 Category ChildOf 634 UNIX file descriptor leak All The program fails to release - or incorrectly releases - a system resource before it is made available for re-use. When a resource is created or allocated, the developer is responsible for properly releasing the resource as well as accounting for all potential paths of expiration or invalidation, such as a set period of time or revocation. Non-specific It is good practice to be responsible for freeing all resources you allocate. Memory should be allocated/freed using matching functions such as malloc/free, new/delete, and new[]/delete[]. The following method never closes the file handle it opens. The Finalize() method for StreamReader eventually calls Close(), but there is no guarantee as to how long it will take before the Finalize() method is invoked. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, this can result in the VM using up all of its available file handles. If an exception occurs after establishing the database connection and before the same connection closes, the pool of database connections may become exhausted. If the number of available connections is exceeded, other users cannot access this resource, effectively denying access to the application. Using the following database connection pattern will ensure that all opened connections are closed. The con.close() call should be the first executable statement in the finally block. Under normal conditions the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. But if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries. C# The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles. C In this example, the program fails to use matching functions such as malloc/free, new/delete, and new[]/delete[] to allocate/deallocate the resource. C++ In this example, the program calls the delete[] function on non-heap memory. C++ CVE-1999-1127 Does not shut down named pipe connections if malformed data is sent. CVE-2001-0830 Sockets not properly closed when attacker repeatedly connects and disconnects from server. CVE-2002-1372 Return values of file/socket operations not checked, allowing resultant consumption of file descriptors. It is important to be consistent with how and where you free memory in a function. If you allocate memory that you intend to free upon completion of the function, you must be sure to free the memory at all exit points for that function including error conditions. Before freeing a pointer, the programmer should make sure that the pointer was previously allocated and that the memory belongs to the programmer. Freeing an unallocated pointer will cause undefined behavior in the program. Can be resultant from improper error handling or insufficient resource tracking. Overlaps memory leaks, asymmetric resource consumption, malformed input errors. Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, the attacker might be able to launch a denial of service attack by depleting the resource pool. Resource leaks have at least two common causes: - Error conditions and other exceptional circumstances. - Confusion over which part of the program is responsible for releasing the resource. 1000 Weakness ChildOf 664 1000 Category ChildOf 399 1000 Weakness PeerOf 405 Improper resource shutdown or release Unreleased Resource All Software that fails to appropriately monitor or control resource consumption can lead to adverse system performance. This situation is amplified if the software allows malicious users or attackers to consume more resources than their access level permits. Exploiting such a weakness can lead to asymmetric resource consumption, aiding in amplification attacks against the system or the network. Non-specific An application must make resources available to a client commensurate with the client's access level. An application must, at all times, keep track of allocated resources and meter their usage appropriately. There are probably several sub-types besides these. Sometimes this is a factor in "flood" attacks, but other types of amplification exist. 1000 Category ChildOf 399 Asymmetric resource consumption (amplification) All The software fails to appropriately monitor or control transmitted network traffic volume such that the volume of traffic transmitted by each entity is commensurate with the entity's permissions. In the absence of a policy to restrict asymmetric resource consumption, the application or system cannot distinguish between legitimate transmissions and traffic intended to serve as an amplifying attack on target systems. Systems can often be configured to restrict the amount of traffic sent out on behalf of a client, based on the client's origin or access level. This is usually defined in a resource allocation policy. In the absence of a mechanism to keep track of transmissions, the system or application can be easily abused to transmit asymmetrically greater traffic than the request or client should be permitted to. An application must make network resources available to a client commensurate with the client's access level. Define a clear policy for network resource allocation and consumption. An application must, at all times, keep track of network resources and meter their usage appropriately. CVE-1999-0513 Smurf attack, spoofed ICMP packets to broadcast addresses. CVE-1999-1379 DNS query with spoofed source address causes more traffic to be returned to spoofed address than was sent by the attacker. CVE-2000-0041 Large datagrams are sent in response to malformed datagrams. CVE-1999-1066 Game server sends a large amount. Spoofing is often a factor. Applications that use UDP are typically targeted, although this problem can exist in other protocols or contexts. Network amplification, when performed with spoofing, is normally a multi-channel attack from attacker (acting as user) to amplifier, and amplifier to user. 1000 Weakness ChildOf 405 Network Amplification All An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached. The typical consequence is CPU consumption, but memory consumption and consumption of other resources can also occur. CVE-2003-0244 CPU consumption via inputs that cause many hash table collisions. CVE-2003-0364 CPU consumption via inputs that cause many hash table collisions. CVE-2002-1203 Product performs unnecessary processing before dropping an invalid packet. CVE-2001-1501 CPU and memory consumption using many wildcards. CVE-2004-2527 Product allows attackers to cause multiple copies of a program to be loaded more quickly than the program can detect that other copies are running, then exit. This type of error should probably have its own category, where teardown takes more time than initialization. CVE-2006-6931 CVE-2006-3380 CVE-2006-3379 CVE-2005-2506 CVE-2005-1792 Memory leak by performing actions faster than the software can clear them. Similar issues can occur in cryptography. Crosby Wallach Algorithmic Complexity Attacks http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/index.html 1000 Weakness ChildOf 405 Algorithmic Complexity All The software allows an entity to perform a legitimate but expensive operation before sufficient authentication or authorization has taken place. CVE-2004-2458 Tool creates directories before authenticating user. general class of issue? step problem on product's side. Overlaps authentication errors. 1000 Weakness ChildOf 405 Early Amplification All The software does not properly handle a compressed input with a very high compression ratio that produces a large output. An example of data amplification is a "decompression bomb," a small ZIP file that can produce a large amount of data when it is decompressed. 1000 Weakness ChildOf 405 Data Amplification All The system or application is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object. Path equivalence is usually employed in order to circumvent access controls expressed using an incomplete set of file name or file path representations. This is different from path traversal, wherein the manipulations are performed to generate a name for a different object. File/Directory Assume all input is malicious. Attackers can insert special characters into resources (e.g. filenames) to disguise their input. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Warning: if you attempt to cleanse your data, then do so that the end result is not in the form that can be dangerous. A sanitizing mechanism can remove characters such as ‘.' and ‘;' which may be required for some exploits. An attacker can try to fool the sanitizing mechanism into "cleaning" data into a dangerous form. Suppose the attacker injects a ‘.' inside a filename (e.g. "sensi.tiveFile") and the sanitizing mechanism removes the character resulting in the valid filename, "sensitiveFile". If the input data are now assumed to be safe, then the file may be compromised. Some of these manipulations could be effective in path traversal issues, too. 1000 Weakness ChildOf 21 631 Category ChildOf 632 Path Equivalence All 3 4 The software's resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources. Frequently the consequence is a "flood" of connection or sessions. Non-specific floods often cause a crash or other problem besides denial of the resource itself; these are likely examples of *other* vulnerabilities, not an insufficient resource pool. CVE-1999-1363 Large number of locks on file exhausts the pool and causes crash. CVE-2001-1340 Product supports only one connection and does not disconnect a user who does not provide credentials. CVE-2002-0406 Large number of connections without providing credentials allows connection exhaustion. "large" is relative to the size of the resource pool, which could be very small. See examples. 1000 Category ChildOf 399 Insufficient Resource Pool All A critical resource can be locked or controlled by an attacker, indefinitely, in a way that prevents access to that resource by others, e.g. by obtaining an exclusive lock or mutex, or modifying the permissions of a shared resource. Inconsistent locking discipline can lead to deadlock. CVE-2001-0682 Program can not execute when attacker obtains a lock or mutex. CVE-2002-1914 Program can not execute when attacker obtains a lock or mutex. CVE-2002-1915 Program can not execute when attacker obtains a lock or mutex. CVE-2000-0338 Predictable file names used for locking, allowing attacker to create the lock beforehand. Resultant from permissions and randomness. CVE-2000-1198 Lock files with predictable names. Resultant from randomness. CVE-2002-0051 Overlaps permissions, large-window race condition. Critical file can be opened with exclusive read access by user. CVE-2002-1914 Users prevent execution of a dump program by locking a file. CVE-2002-1869 Product does not check if it can write to a log file, allowing attackers to avoid logging by accessing the file using an exclusive lock. Overlaps unchecked error condition. This overlaps Insufficient Resource Pool when the "pool" is of size 1. It can also be resultant from race conditions, although the timing window could be quite large in some cases. 1000 Weakness ChildOf 667 1000 Category ChildOf 411 1000 Category ChildOf 361 1000 Weakness CanAlsoBe 410 630 View ChildOf 630 Unrestricted Critical Resource Lock Deadlock All 25 A product does not sufficiently lock resources, in a way that either (1) allows an attacker to simultaneously access those resources, or (2) causes other errors that lead to a resultant weakness. 1000 Weakness ChildOf 667 1000 Category ChildOf 411 Insufficient Resource Locking All A product does not check to see if a lock is present before performing sensitive operations on a resource. CVE-2004-1056 Product does not properly check if a lock is present, allowing other attackers to access functionality. 1000 Weakness ChildOf 667 1000 Category ChildOf 411 Missing Lock Check All The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations. Double-free Low to Medium Memory Access control: Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code. Implementation: Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once. Example 1: The following code shows a simple example of a double free vulnerability. Double free vulnerabilities have two common (and sometimes overlapping) causes: - Error conditions and other exceptional circumstances - Confusion over which part of the program is responsible for freeing the memory Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once. Example 2: While contrived, this code should be exploitable on Linux distributions which do not ship with heap-chunk check summing turned on. #include #define BUFSIZE1 512 #define BUFSIZE2 ((BUFSIZE1/2) - 8) int main(int argc, char **argv) { char *buf1R1; char *buf2R1; char *buf1R2; buf1R1 = (char *) malloc(BUFSIZE2); buf2R1 = (char *) malloc(BUFSIZE2); free(buf1R1); free(buf2R1); buf1R2 = (char *) malloc(BUFSIZE1); strncpy(buf1R2, argv[1], BUFSIZE1-1); free(buf2R1); free(buf1R2); }]]> CVE-2004-0642 Double free resultant from certain error conditions. CVE-2004-0772 Double free resultant from certain error conditions. CVE-2005-1689 Double free resultant from certain error conditions. CVE-2003-0545 Double free from invalid ASN.1 encoding. CVE-2003-1048 Double free from malformed GIF. CVE-2005-0891 Double free from malformed GIF. CVE-2002-0059 Double free from malformed compressed data. This is usually resultant from another weakness, such as an unhandled error or race condition between threads. It could also be primary to weaknesses such as buffer overflows. Also a Consequence. When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack. It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but we're considering "Use" and "Release" to be distinct operations, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet. 1000 Weakness ChildOf 666 1000 Weakness ChildOf 675 1000 Category ChildOf 399 1000 Weakness ChildOf 416 1000 Weakness PeerOf 123 630 View ChildOf 630 631 Category ChildOf 633 DFREE - Double-Free Vulnerability Double Free Doubly freeing memory C C++ Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. Use-After-Free High Memory Integrity: The use of previously freed memory may corrupt valid data, if the memory area in question has been allocated and used properly elsewhere. Availability: If chunk consolidation occur after the use of previously freed data, the process may crash when invalid data is used as chunk information. Access Control (instruction processing): If malicious data is entered before chunk consolidation can take place, it may be possible to take advantage of a write-what-where primitive to execute arbitrary code. Implementation: Ensuring that all pointers are set to NULL once they memory they point to has been freed can be effective strategy. The utilization of multiple or complex data structures may lower the usefulness of this strategy. #include #define BUFSIZER1 512 #define BUFSIZER2 ((BUFSIZER1/2) - 8) int main(int argc, char **argv) { char *buf1R1; char *buf2R1; char *buf2R2; char *buf3R2; buf1R1 = (char *) malloc(BUFSIZER1); buf2R1 = (char *) malloc(BUFSIZER1); free(buf2R1); buf2R2 = (char *) malloc(BUFSIZER2); buf3R2 = (char *) malloc(BUFSIZER2); strncpy(buf2R1, argv[1], BUFSIZER1-1); free(buf1R1); free(buf2R2); free(buf3R2); }]]> Example 2: The following code illustrates a use after free error: CVE-2006-4997 - freed pointer dereference The use of previously freed memory can have any number of adverse consequences -- ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system's reuse of the freed memory. Like double free errors and memory leaks, use after free errors have two common and sometimes overlapping causes: - Error conditions and other exceptional circumstances. - Confusion over which part of the program is responsible for freeing the memory. In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data chances to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved. 1000 Weakness ChildOf 672 1000 Category ChildOf 399 1000 Compound_Element CanPrecede 120 1000 Weakness CanPrecede 123 630 View ChildOf 630 631 Category ChildOf 633 Use After Free Using freed memory C C++ The software uses a primary channel for administration or restricted functionality, but it does not properly protect the channel. 1000 Category ChildOf 418 1000 Weakness ChildOf 668 Unprotected Primary Channel All A software system that accepts path input in the form of trailing dot ('filedir.') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" CVE-2000-1114 Source code disclosure using trailing dot CVE-2002-1986, Source code disclosure using trailing dot CVE-2004-2213 Source code disclosure using trailing dot CVE-2005-3293 Source code disclosure using trailing dot CVE-2004-0061 Bypass directory access restrictions using trailing dot in URL CVE-2000-1133 Bypass directory access restrictions using trailing dot in URL CVE-2001-1386 Bypass check for ".lnk" extension using ".lnk." 1000 Weakness ChildOf 41 Trailing Dot - 'filedir.' All The software protects a primary channel, but it does not use the same level of protection for an alternate channel. CVE-2002-0567 DB server assumes that local clients have performed authentication, allowing attacker to directly connect to a process to load libraries and execute commands; a socket interface also exists (another alternate channel), so attack can be remote. CVE-2002-1578 Product does not restrict access to underlying database, so attacker can bypass restrictions by directly querying the database. CVE-2003-1035 User can avoid lockouts by using an API instead of the GUI to conduct brute force password guessing. CVE-2002-1863 FTP service can not be disabled even when other access controls would require it. CVE-2002-0066 Windows named pipe created without authentication/access control, allowing configuration modification. CVE-2004-1461 Router management interface spawns a separate TCP connection after authentication, allowing hijacking by attacker coming from the same IP address. Factors: this can be primary to authentication errors, and resultant from unhandled error conditions. 1000 Category ChildOf 418 1000 Weakness ChildOf 668 Unprotected Alternate Channel All The product opens an alternate channel intended for communication with an authorized user, but the channel is unprotected and a race condition allows an attacker to access the channel before the authorized user does. System Process authenticate or validate the incoming connection, possibly using cookies, shared secrets, or certificates. CVE-1999-0351 FTP "Pizza Thief" vulnerability. Attacker can connect to a port that was intended for use by another client. CVE-2003-0230 Hijack alternate named pipe while another user is authenticating. CVE-2003-0230 Product creates Windows named pipe during authentication that another attacker can hijack by connecting to it. Predictability can be a factor in some issues. 1000 Weakness ChildOf 420 1000 Weakness ChildOf 362 631 Category ChildOf 634 Alternate Channel Race Condition All The software does not properly verify the source of a message in the Windows Messaging System while running at elevated privileges, creating an alternate channel through which an attacker can directly send a message to the product. System Process CVE-2002-0971 Bypass GUI and access restricted dialog box. CVE-2002-1230 Gain privileges via Windows message. CVE-2003-0350 A control allows a change to a pointer for a callback function using Windows message. CVE-2003-0908 Product launches Help functionality while running with raised privileges, allowing command execution using Windows message to access "open file" dialog. CVE-2004-0213 Attacker uses Shatter attack to bypass GUI-enforced protection for CVE-2003-0908. CVE-2004-0207 User can call certain API functions to modify certain properties of privileged programs. Alternate channel attacks likely exist in other operating systems and messaging models, e.g. in privileged X Windows applications, but examples are not readily available. Overlaps privilege errors and UI errors. Possibly under-reported, probably under-studied. It is suspected that a number of publicized vulnerabilities that involve local privilege escalation on Windows systems may be related to Shatter attacks, but they are not labeled as such. Paget Exploiting design flaws in the Win32 API for privilege escalation. Or... Shatter Attacks - How to break Windows August, 2002 http://web.archive.org/web/20060115174629/http://security.tombom.co.uk/shatter.html 1000 Weakness ChildOf 420 1000 Weakness ChildOf 360 631 Category ChildOf 634 Unprotected Windows Messaging Channel ('Shatter') All The software controls and trusts both endpoints of a channel, but one endpoint can be accessed by an attacker and used as a proxy to interact with the product. This can overlap some other categories, such as those exploited by "bounce" attacks, but the idea here is that both endpoints are under control of the product. 1000 Category ChildOf 418 Proxied Trusted Channel All The product does not sufficiently protect all possible paths that a user can take to access restricted functionality or resources. This is partially covered by other categories. 1000 Category ChildOf 417 1000 Weakness ChildOf 693 Alternate Path Errors All The web application fails to adequately enforce appropriate authorization on all restricted URLs, scripts or files. Such web applications often make the false assumption that such resources can only be reached through a given navigation path and so only apply authorization at certain points in the path. Apply appropriate access control authorizations for each access to all restricted URLs, scripts or files. CVE-2004-2144 Bypass authentication via direct request. CVE-2005-1892 Infinite loop or infoleak triggered by direct requests. CVE-2004-2257 Bypass auth/auth via direct request. CVE-2005-1688 Direct request leads to infoleak by error. CVE-2005-1697 Direct request leads to infoleak by error. CVE-2005-1698 Direct request leads to infoleak by error. CVE-2005-1685 Authentication bypass via direct request. CVE-2005-1827 Authentication bypass via direct request. CVE-2005-1654 Authorization bypass using direct request. CVE-2005-1668 Access privileged functionality using direct request. CVE-2002-1798 Upload arbitrary files via direct request. Terminology Note: the "forced browsing" term could be misinterpreted to include weaknesses such as CSRF or XSS, so its use is discouraged. "Forced browsing" is a step-based manipulation involving the omission of one or more steps, whose order is assumed to be immutable; the application does not verify that the first step was performed. The consequence is typically "authentication bypass" or "path disclosure," although it can expose all kinds of weaknesses, especially in languages such as PHP, which allow external modification of assumed-immutable variables. overlaps Modification of Assumed-Immutable Data (MAID), authorization errors, container errors; often primary to other weaknesses such as XSS and SQL injection. 1000 Weakness ChildOf 288 1000 Weakness ChildOf 424 1000 Weakness CanAlsoBe 471 629 View ChildOf 629 Direct Request aka 'Forced Browsing All 87 One or more locations in a static search path is under control of the attacker. CVE-2002-1576 CVE-2000-1128 CVE-1999-1461 CVE-1999-1318 CVE-2003-0579 CVE-2001-0507 CVE-2000-0854 CVE-2001-0943 CVE-2001-0942 CVE-2001-0507 CVE-2002-2017 CVE-1999-0690 CVE-2001-0912 Error during packaging causes product to include a hard-coded, non-standard directory in search path. CVE-2001-0289 Product searches current working directory for configuration file. CVE-2005-1705 Product searches current working directory for configuration file. CVE-2005-1307 Product executable other program from current working directory. CVE-2002-2040 Untrusted path. CVE-2005-2072 Modification of trusted environment variable leads to untrusted path vuln. CVE-2005-1632 Product searches /tmp for modules before other paths. PHP file inclusion is an instance of this (see PHP-specific issues); trusted environment variables is another. 1000 Category ChildOf 417 Uncontrolled Search Path Element All 38 The product uses a search path that contains an unquoted element, in which the element contains whitespace or other separators. This can cause the product to access resources in a parent path. Program invocation Software should quote the input data that can be potentially executed on a system. C C++ CVE-2005-1185 Small handful of others. Program doesn't quote the "C:\Program Files\" path when calling a program to be executed - or any other path with a directory or file whose name contains a space - so attacker can put a malicious program.exe into C:. CVE-2005-2938 CreateProcess() and CreateProcessAsUser() can be misused by applications to allow "program.exe" style attacks in C: CVE-2000-1128 Applies to "Common Files" folder, with a malicious common.exe, instead of "Program Files"/program.exe. Fault: missing quoting Design Limitation: whitespace allowed in identifiers. If a malicious individual has access to the file system, it is possible to elevate privileges by inserting such a file as "C:\Program.exe" to be run by a privileged program making use of WinExec. This theoretically could apply to other OSes besides Windows, especially those that make it easy for spaces to be in files or folders. Under-studied, probably under-reported. 1000 Category ChildOf 417 Unquoted Search Path or Element All 38 A software system that accepts path input in the form of multiple trailing dot ('filedir....') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Pathname Traversal and Equivalence Errors" BUGTRAQ:20040205 Apache + Resin Reveals JSP Source Code ... CVE-2004-0281 Multiple trailing dot allows directory listing 1000 Weakness ChildOf 42 Multiple Trailing Dot - 'filedir....' All The wrong "handler" is assigned to process an object, e.g. calling a servlet to reveal source code of a .JSP file, or automatically "determines" type even if contradictory to an explicitly specified type. CVE-2001-0004 Source code disclosure via manipulated file extension that causes parsing by wrong DLL. CVE-2002-0025 Web browser does not properly handle the Content-Type header field, causing a different application to process the document. CVE-2000-1052 Source code disclosure by directly invoking a servlet. CVE-2002-1742 Arbitrary Perl functions can be loaded by calling a non-existent function that activates a handler. Factors: usually resultant. 1000 Category ChildOf 429 1000 Compound_Element PeerOf 434 Improper Handler Deployment All A handler is not available or implemented. If a Servlet fails to catch all exceptions, it may reveal debugging information that will help an adversary form a plan of attack. In the following method a DNS lookup failure will cause the Servlet to throw an exception. When a Servlet throws an exception, the default error response the Servlet container sends back to the user typically includes debugging information. This information is of great value to an attacker. When an exception is thrown and not caught, the process has given up an opportunity to decide if a given failure or event is worth a change in execution. 1000 Category ChildOf 429 Missing Handler All The application does not properly clear or disable dangerous handlers during sensitive operations, which might allow an attacker to invoke the handler at unexpected times. This can cause the software to enter an invalid state. 1000 Category ChildOf 429 Dangerous handler not cleared/disabled during sensitive operations All Raw content or supporting code is stored under the web root with an extension that is not specially handled by the server such as ".inc" or ".pl", causing the content or code to be delivered to the user without the pre-processing that was expected, typically resulting in an information leak. CVE-2002-1886 ".inc" file stored under web document root and returned unparsed by the server CVE-2002-2065 ".inc" file stored under web document root and returned unparsed by the server CVE-2005-2029 ".inc" file stored under web document root and returned unparsed by the server SECUNIA:11394 ".inc" file stored under web document root and returned unparsed by the server CVE-2001-0330 direct request to .pl file leaves it unparsed CVE-2002-0614 .inc file CVE-2004-2353 unparsed config.conf file CVE-2007-3365 Chain: uppercase file extensions causes web server to return script source code instead of executing the script. This can overlap containment errors, but it is not necessarily the same thing. Also overlaps direct requests, alternate path, permissions, sensitive file under web root 1000 Weakness ChildOf 430 1000 Weakness ChildOf 431 Unparsed Raw Web Content Delivery All An interaction error occurs when two entities work correctly when running independently, but they interact in unexpected ways when they are run together. This could apply to products, systems, components, etc. Terminology Note: some use "Interaction Error" to describe products that behave according to specification. However, the PLOVER definition includes products that do not necessarily comply with standard specifications. 1000 Weakness ChildOf 398 Interaction Errors All Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state. Note: this is generally found in proxies, firewalls, anti-virus software, and other intermediary devices that allow, deny, or modify traffic based on how the client or server is expected to behave. CVE-2005-1215 Bypass filters or poison web cache using requests with multiple Content-Length headers, a non-standard behavior. CVE-2002-0485 Anti-virus product allows bypass via Content-Type and Content-Disposition headers that are mixed case, which are still processed by some clients. CVE-2002-1978 FTP clients sending a command with "PASV" in the argument can cause firewalls to misinterpret the server's error as a valid response, allowing filter bypass. CVE-2002-1979 FTP clients sending a command with "PASV" in the argument can cause firewalls to misinterpret the server's error as a valid response, allowing filter bypass. CVE-2002-0637 Virus product bypass with spaces between MIME header fields and the ":" separator, a non-standard message that is accepted by some clients. CVE-2002-1777 AV product detection bypass using inconsistency manipulation (file extension in MIME Content-Type vs. Content-Disposition field). CVE-2005-3310 CMS system allows uploads of files with GIF/JPG extensions, but if they contain HTML, Internet Explorer renders them as HTML instead of images. CVE-2005-4260 Interpretation conflict allows XSS via invalid "<" when a ">" is expected, which is treated as ">" by many web browsers. CVE-2005-4080 Interpretation conflict (non-standard behavior) enables XSS because browser ignores invalid characters in the middle of tags. The classic multiple interpretation flaws were reported in a paper that described the limitations of intrusion detection systems. Ptacek and Newsham (see references below) showed that OSes varied widely in their behavior with respect to unusual network traffic, which made it difficult or impossible for intrusion detection systems to properly detect certain attacker manipulations that took advantage of the OS differences. Another classic multiple interpretation error is the "poison null byte" described by Rain Forest Puppy (see reference below), in which null characters have different interpretations in Perl and C, which have security consequences when Perl invokes C functions. Similar problems have been reported in ASP (see ASP reference below) and PHP. Some of the more complex web-based attacks, such as HTTP request smuggling, also involve multiple interpretation errors. A comment on a way to manage these problems is in David Skoll in the reference below. Manipulations are major factors in multiple interpretation errors, such as doubling, inconsistencies between related fields, and whitespace. Steve Christey On Interpretation Conflict Vulnerabilities Bugtraq 2005-11-03 Thomas H. Ptacek Timothy N. Newsham Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection January 1998 http://www.insecure.org/stf/secnet_ids/secnet_ids.pdf Brett Moore 0x00 vs ASP file upload scripts 2004-07-13 http://www.security-assessment.com/Whitepapers/0x00_vs_ASP_File_Uploads.pdf Rain Forest Puppy Poison NULL byte Phrack David F. Skoll Re: Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding Bugtraq 2004-09-15 http://marc.theaimsgroup.com/?l=bugtraq&m=109525864717484&w=2 1000 Weakness ChildOf 435 Multiple Interpretation Error (MIE) All 33 A product acts as an intermediary or monitor between two or more endpoints, but it does not have a complete model of an endpoint's features, behaviors, or state. This causes the product to perform incorrect actions based on this incomplete model. HTTP request smuggling is an attack against an intermediary such as a proxy. This attack works because the proxy expects the client to parse HTTP headers one way, but the client parses them differently. Anti-virus products that reside on mail servers can suffer from this issue if they do not know how a mail client will handle a particular attachment. The product might treat an attachment type as safe, not knowing that the client's configuration treats it as executable. This can be related to interaction errors, although in some cases, one of the endpoints is not performing correctly according to specification. 1000 Weakness ChildOf 436 Extra Unhandled Features All A's behavior or functionality changes with a new version of A, or a new environment, which is not known (or manageable) by B. Functional change CVE-2002-1976 Linux kernel 2.2 and above allow promiscuous mode using a different method than previous versions, and ifconfig is not aware of the new method (alternate path property). CVE-2005-1711 Anti-virus product uses a defunct method in another product that does not return an error code, allowing viruses to avoid detection. CVE-2005-1711 Product uses defunct method from another product that does not return an error code and allows detection avoidance. 1000 Category ChildOf 438 CHANGE Behavioral Change All A software system that accepts path input in the form of internal dot ('file.ordir') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" This variant does not have any easily findable, publicly reported vulnerabilities, but it can be an effective manipulation in weaknesses such as validate-before-cleanse, which might remove a dot from a string to produce an unexpected string. 1000 Weakness ChildOf 41 Internal Dot - 'file.ordir' All A feature, API, or function being used by a product behaves differently than the product expects. CVE-2003-0187 Inconsistency in support of linked lists causes program to use large timeouts on "undeserving" connections. CVE-2003-0465 "strncpy" in Linux kernel acts different than libc on x86, leading to expected behavior difference - sort of a multiple interpretation error? CVE-2005-3265 Buffer overflow in product stems to the use of a third party library function that is expected to have internal protection against overflows, but doesn't. Property: consistency 1000 Weakness ChildOf 684 1000 Category ChildOf 438 Expected behavior violation All A product can be used as an intermediary or proxy between an attacker and the ultimate target, so that the attacker can either bypass access controls or hide activities. CVE-1999-0168 Portmapper could redirect service requests from an attacker to another entity, which thinks the requests came from the portmapper. CVE-2005-0315 FTP server does not ensure that the IP address in a PORT command is the same as the FTP user's session, allowing port scanning by proxy. CVE-2002-1484 Web server allows attackers to request a URL from another server, including other ports, which allows proxied scanning. CVE-2004-2061 CGI script accepts and retrieves incoming URLs. CVE-2002-1484 Server in debug mode allows remote attackers to use it as an intermediary for port scanning via a request for a URL that specifies the target IP address and port, then monitoring the resulting error message. CVE-2001-1484 MFV - bounce attack allows access to TFTP from trusted side. CVE-1999-0017 FTP bounce attack. Protocol allows attacker to modify the PORT command to cause the FTP server to connect to other machines besides the attacker's. Similar to proxied trusted channel. Property: Alternate Channel 1000 Weakness ChildOf 435 1000 Weakness ChildOf 610 Unintended proxy/intermediary All This weakness can be found at CWE-113. 604 View ChildOf 604 When malformed or abnormal HTTP requests are interpreted by one or more entities in the data flow between the user and the web server, such as a proxy or firewall, they can be interpreted inconsistently, allowing the attacker to "smuggle" a request to one device without the other device being aware of it. Use a web server that employs a strict HTTP parsing procedure. Use only SSL communication. Terminate the client session after each request. Turn all pages to non-cacheable. CVE-2005-2088 Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers. CVE-2005-2089 Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers. CVE-2005-2090 Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers. CVE-2005-2091 Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers. CVE-2005-2092 Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers. CVE-2005-2093 Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers. CVE-2005-2094 Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers. Request smuggling can be performed due to a multiple interpretation error, where the target is an intermediary or monitor, via a consistency manipulation (Transfer-Encoding and Content-Length headers). Resultant from CRLF injection. Chaim Linhart Amit Klein Ronen Heled Steve Orrin HTTP Request Smuggling http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf 1000 Weakness ChildOf 436 1000 Category ChildOf 442 HTTP Request Smuggling All 33 A user interface - whether a GUI or not - does not correctly interact with the security features in an application, however the interface provides feedback consistent with the user's expectations, leading to a discrepancy between actual configurations and user expectations. CVE-1999-1446 UI inconsistency; visited URLs list not cleared when "Clear History" option is selected. This is often resultant. An example of this might be checking a box for a security option which does not affect anything or telling the user interface to "restrict ALL'" when the implementation will only "restrict SOME". 1000 Weakness ChildOf 684 1000 Category ChildOf 445 User interface inconsistency All A UI function for a security feature appears to be supported and gives feedback to the user that suggests that it is supported, but the underlying functionality is not implemented. CVE-2000-0127 GUI configuration tool does not enable a security option when a checkbox is selected, although that option is honored when manually set in the configuration file. CVE-2001-0863 Router does not implement a specific keyword when it is used in an ACL, allowing filter bypass. CVE-2001-0865 Router does not implement a specific keyword when it is used in an ACL, allowing filter bypass. CVE-2004-0979 Web browser does not properly modify security setting when the user sets it. This issue needs more study, as there are not many examples. It is not clear whether it is primary or resultant. 1000 Weakness ChildOf 446 1000 Weakness ChildOf 671 Unimplemented or unsupported feature in UI All A UI function is obsolete and the product does not warn the user. 1000 Weakness ChildOf 446 Obsolete feature in UI All The UI performs the wrong action with respect to the user's request. CVE-2001-1387 Network firewall accidentally implements one command line option as if it were another, possibly leading to behavioral infoleak. CVE-2001-0081 Command line option correctly suppresses a user prompt but does not properly disable a feature, although when the product prompts the user, the feature is properly disabled. CVE-2002-1977 Product does not "time out" according to user specification, leaving sensitive data available after it has expired. 1000 Weakness ChildOf 446 The UI performs the wrong action All A software system that accepts path input in the form of multiple internal dot ('file...dir') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" This variant does not have any easily findable, publicly reported vulnerabilities, but it can be an effective manipulation in weaknesses such as validate-before-cleanse, which might use a regular expression that removes ".." sequences from a string to produce an unexpected string. 1000 Weakness ChildOf 44 Multiple Internal Dot - 'file...dir' All The UI has multiple interpretations of user input but does not prompt the user when it selects the less secure interpretation. 1000 Weakness ChildOf 357 1000 Category ChildOf 445 Multiple Interpretations of UI Input All The UI does not properly represent critical information to the user, allowing the information - or its source - to be obscured or spoofed. This is often a component in phishing attacks. CVE-2001-0398 Attachment with many spaces in filename bypasses "dangerous content" warning and uses different icon. Likely resultant. CVE-2001-0643 Misrepresentation and equivalence issue. CVE-2005-0593 Lock spoofing from several different Weaknesses. CVE-2005-0143 Wrong status / state notifier -- Lock icon displayed when an insecure page loads a binary file loaded from a trusted site. CVE-2005-0144 Wrong status / state notifier -- Secure "lock" icon is presented for one channel, while an insecure page is being simultaneously loaded in another channel. CVE-2004-0761 Wrong status / state notifier -- Certain redirect sequences cause security lock icon to appear in web browser, even when page is not encrypted. CVE-2004-2219 Wrong status / state notifier -- Spoofing via multi-step attack that causes incorrect information to be displayed in browser address bar. CVE-2004-0537 Overlay -- Wide "favorites" icon can overlay and obscure address bar OSVDB:5703 Overlay -- GUI overlay vulnerability (misrepresentation) CVE-2005-2271 Visual distinction -- Web browsers do not clearly associate a Javascript dialog box with the web page that generated it, allowing spoof of the source of the dialog. "origin validation error" of a sort? CVE-2005-2272 Visual distinction -- Web browsers do not clearly associate a Javascript dialog box with the web page that generated it, allowing spoof of the source of the dialog. "origin validation error" of a sort? CVE-2005-2273 Visual distinction -- Web browsers do not clearly associate a Javascript dialog box with the web page that generated it, allowing spoof of the source of the dialog. "origin validation error" of a sort? CVE-2005-2274 Visual distinction -- Web browsers do not clearly associate a Javascript dialog box with the web page that generated it, allowing spoof of the source of the dialog. "origin validation error" of a sort? CVE-2001-1410 Visual distinction -- Browser allows attackers to create chromeless windows and spoof victim's display using unprotected Javascript method. CVE-2002-0197 Visual distinction -- Chat client allows remote attackers to spoof encrypted, trusted messages with lines that begin with a special sequence, which makes the message appear legitimate. CVE-2005-0831 Visual distinction -- Product allows spoofing names of other users by registering with a username containing hex-encoded characters. CVE-2003-1025 Visual truncation -- Special character in URL causes web browser to truncate the user portion of the "user@domain" URL, hiding real domain in the address bar. CVE-2005-0243 Visual truncation -- Chat client does not display long filenames in file dialog boxes, allowing dangerous extensions via manipulations including (1) many spaces and (2) multiple file extensions. CVE-2005-1575 Visual truncation -- Web browser file download type hiding using whitespace. CVE-2004-2530 Visual truncation -- Visual truncation in chat client using whitespace to hide dangerous file extension. CVE-2005-0590 Visual truncation -- Dialog box in web browser allows user to spoof the hostname via a long "user:pass" sequence in the URL, which appears before the real hostname. OSVDB:6009 Visual truncation -- GUI obfuscation (visual truncation) in web browser - obscure URLs using a large amount of whitespace. Note - "visual truncation" covers a couple variants. CVE-2004-145 Visual truncation -- Null character in URL prevents entire URL from being displayed in web browser. CVE-2004-2258 Miscellaneous -- [step-based attack, GUI] -- Password-protected tab can be bypassed by switching to another tab, then back to original tab. CVE-2005-1678 Miscellaneous -- Dangerous file extensions not displayed. CVE-2002-0722 Miscellaneous -- Web browser allows remote attackers to misrepresent the source of a file in the File Download dialogue box. This category needs refinement. Overlaps Wheeler's "Semantic Attacks" Here are some examples of misrepresentation: [*] icon manipulation (making a .EXE look like a .GIF) [*] homographs: letters from different character sets/languages that look similar. The use of homographs is effectively a manipulation of a visual equivalence property. [*] a race condition can cause the UI to present the user with "safe" or "trusted" feedback before the product has fully switched context. The race window could be extended indefinitely if the attacker can trigger an error. [*] "Window injection" vulnerabilities (though these are usually resultant from privilege problems) [*] status line modification (e.g. CVE-2004-1104) [*] various other web browser issues. [*] GUI truncation (e.g. filename with dangerous extension not displayed to GUI because of truncation) - CVE-2004-2227 - GUI truncation enables information hiding [*] injected internal spaces (e.g. "filename.txt .exe" - though this overlaps truncation [*] Also consider DNS spoofing problems - can be used for misrepresentation. Misrepresentation problems are frequently studied in web browsers, but there are no known efforts for categorizing these problems in terms of the shortcomings of the interface. In addition, many misrepresentation issues are resultant. 1000 Weakness ChildOf 221 1000 Category ChildOf 445 1000 Weakness PeerOf 346 UI Misrepresentation of Critical Information All The software, by default, initializes an internal variable with an insecure or less secure value than is possible. This overlaps other categories, probably should be split into separate items. 1000 Weakness ChildOf 665 1000 Category ChildOf 452 Insecure default variable initialization All The software initializes critical internal variables using inputs that can come from externally controlled sources. A software system should be reluctant to trust variables that have been initialized outside of its trust boundary, especially if they are initialized by users. They may have been initialized incorrectly. If an attacker can initialize the variable, then he/she can influence what the vulnerable system will do. A software system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking is performed when relying on input from outside a trust boundary. CVE-2000-0959 Does not clear dangerous environment variables, enabling symlink attack. CVE-2001-0033 Specify alternate configuration directory in environment variable, enabling untrusted path. CVE-2001-0872 Dangerous environment variable not cleansed. CVE-2001-0084 Specify arbitrary modules using environment variable. Overlaps Missing variable initialization, especially in PHP. This is a significant factor in a number of resultant weaknesses. Frequently found in PHP due to register_globals and the common practice of storing library/include files under the web document root so that they are available using a direct request. 1000 Weakness ChildOf 665 1000 Category ChildOf 452 1000 Weakness CanAlsoBe 456 External initialization of trusted variables or values All The software does not exit or otherwise modify its operation when security-relevant errors occur during initialization, such as when a configuration file has a format error, which can cause the software to execute in a less secure fashion than intended by the administrator. Follow the principle of failing securely when an error occurs. The system should enter a state where it is not vulnerable and will not display sensitive error messages to a potential attacker. CVE-2005-1345 Product does not trigger a fatal error if missing or invalid ACLs are in a configuration file. Under-studied. These issues are not frequently reported, and it is difficult to find published examples. 1000 Weakness ChildOf 665 1000 Category ChildOf 452 1000 Weakness ChildOf 691 1000 Weakness ChildOf 636 Non-exit on Failed Initialization All The software does not initialize critical variables, which causes the execution environment to use unexpected values. CVE-2005-2978 Product uses uninitialized variables for size and index, leading to resultant buffer overflow. CVE-2005-2109 Internal variable in PHP application is not initialized, allowing external modification. CVE-2005-2193 Array variable not initialized in PHP application, leading to resultant SQL injection. This weakness is a major factor in a number of resultant weaknesses, especially in web applications that allow global variable initialization (such as PHP) with libraries that can be directly requested. It is highly likely that a large number of resultant weaknesses have missing initialization as a primary factor, but researcher reports generally do not provide this level of detail. 1000 Weakness ChildOf 665 1000 Category ChildOf 452 1000 Weakness CanPrecede 89 1000 Compound_Element CanPrecede 120 Missing Initialization All The code uses a variable that has not been initialized, leading to unpredictable results. In some languages, such as C, an uninitialized variable contains contents of previously-used memory. An attacker can sometimes control these contents. High Integrity: Initial variables usually contain junk, which can not be trusted for consistency. This can cause a race condition if a lock variable check passes when it should not. Authorization: Strings which do are not initialized are especially dangerous, since many functions expect a null at the end -- and only at the end -- of a string. Implementation: Assign all variables to an initial variable. Pre-design through Build: Most compilers will complain about the use of uninitialized variables if warnings are turned on. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Design: Mitigating technologies such as safe string libraries and container abstractions could be introduced. Example: The following switch statement is intended to set the values of the variables aN and bN, but in the default case, the programmer has accidentally set the value of aN twice. Most uninitialized variable issues result in general software reliability problems, but if attackers can intentionally trigger the use of an uninitialized variable, they might be able to launch a denial of service attack by crashing the program. Under the right circumstances, an attacker may be able to control the value of an uninitialized variable by affecting the values on the stack prior to the invocation of the function. C++ Java Before variables are initialized, they generally contain junk data of what was left in the memory that the variable takes up. This data is very rarely useful, and it is generally advised to pre-initialize variables or set them to their first values early. If one forget -- in the C language -- to initialize, for example a char *, many of the simple string libraries may often return incorrect results as they expecting the null termination to be at the end of a string. Stack variables in C and C++ are not initialized by default. Their initial values are determined by whatever happens to be in their location on the stack at the time the function is invoked. Programs should never use the value of an uninitialized variable. It is not uncommon for programmers to use an uninitialized variable in code that handles errors or other rare and exceptional circumstances. Uninitialized variable warnings can sometimes indicate the presence of a typographic error in the code. mercy Exploiting Uninitialized Data Jan 2006 http://www.felinemenace.org/~mercy/papers/UBehavior/UBehavior.zip 1000 Weakness ChildOf 456 630 View ChildOf 630 Uninitialized variable Uninitialized Variable All A weakness where the code path has: 1. start statement that defines variable 2. end statement that accesses the variable 3. the code path does not contain a statement that assigns value to the variable This weakness has been deprecated because its name and description did not match. The description duplicated CWE-454, while the name suggested a more abstract initialization problem. Please refer to CWE-665 for the more abstract problem. 1000 View ChildOf 604 The software does not properly "clean up" and remove temporary or supporting resources after they have been used. Insufficient Cleanup File processing Temporary files and other supporting resources should be deleted/released immediately after they are no longer needed. CVE-2000-0552 World-readable temporary file not deleted after use. CVE-2005-2293 Temporary file not deleted after use, leaking database usernames and passwords. CVE-2002-0788 Interaction error creates a temporary file that can not be deleted due to strong permissions. CVE-2002-2066 Alternate data streams for NTFS files are not cleared when files are wiped (alternate channel / infoleak). CVE-2002-2067 Alternate data streams for NTFS files are not cleared when files are wiped (alternate channel / infoleak). CVE-2002-2068 Alternate data streams for NTFS files are not cleared when files are wiped (alternate channel / infoleak). CVE-2002-2069 Alternate data streams for NTFS files are not cleared when files are wiped (alternate channel / infoleak). CVE-2002-2070 Alternate data streams for NTFS files are not cleared when files are wiped (alternate channel / infoleak). CVE-2005-1744 Users not logged out when application is restarted after security-relevant changes were made. Temporary files should be deleted as soon as possible. If a file contains sensitive information, the longer it exists the better the chance an attacker has to gain access to its contents. Also it is possible to overflow the number of temporary files because directories typically have limits on the number of files allowed, which could create a denial of service problem. Overlaps other categories. Concept needs further development. This could be primary (e.g. leading to infoleak) or resultant (e.g. resulting from unhandled error condition or early termination). Overlaps other categories such as permissions and containment. 1000 Weakness ChildOf 404 1000 Category ChildOf 452 Incomplete Cleanup All A software system that accepts path input in the form of trailing space ('filedir ') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" CVE-2001-0693 Source disclosure via trailing encoded space "%20" CVE-2001-0778 Source disclosure via trailing encoded space "%20" CVE-2001-1248 Source disclosure via trailing encoded space "%20" CVE-2004-0280 Source disclosure via trailing encoded space "%20" CVE-2004-2213 Source disclosure via trailing encoded space "%20" CVE-2005-0622 Source disclosure via trailing encoded space "%20" CVE-2005-1656 Source disclosure via trailing encoded space "%20" CVE-2002-1603 Source disclosure via trailing encoded space "%20" CVE-2001-0054 Multi-Factor Vulnerability (MVF). directory traversal and other issues in FTP server using Web encodings such as "%20"; certain manipulations have unusual side effects. CVE-2002-1451 Trailing space ("+" in query string) leads to source code disclosure. 1000 Weakness ChildOf 41 1000 Weakness CanPrecede 289 Trailing Space - 'filedir ' All The product does not sufficiently clean up its state when an exception is thrown, leading to unexpected state or control flow. Medium Implementation: The code could be left in a bad state. Implementation: If one breaks from a loop or function by throwing an exception, make sure that cleanup happens or that you should exit the program. Use throwing exceptions sparsely. C++ Java In this case, you may leave a thread locked accidentally. Often, when functions or loops become complicated, some level of cleanup in the beginning to the end is needed. Often, since exceptions can disturb the flow of the code, one can leave a code block in a bad state. 1000 Weakness ChildOf 459 1000 Category ChildOf 452 Improper cleanup on thrown exception C C++ Java .NET Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error. Low Design: Use a hash table instead of an alist. Design: Use an alist which checks the uniqueness of hash keys with each entry before inserting the entry. A duplicate key entry -- if the alist is designed properly -- could be used as a constant time replace function. However, duplicate key entries could be inserted by mistake. Because of this ambiguity, duplicate key entries in an association list are not recommended and should not be allowed. In Python: alist = [] while (foo()): #now assume there is a string data with a key basename queue.append(basename,data) queue.sort() Since basename is not necessarily unique, this may not sort how one would like it to be. 1000 Category ChildOf 461 Duplicate key in associative list (alist) C C++ Java .NET The accidental deletion of a data-structure sentinel can cause serious programming logic problems. Availability: Generally this error will cause the data structure to not work properly. Authorization: If a control character, such as NULL is removed, one may cause resource access control problems. Pre-design: Use a language or compiler that performs automatic bounds checking. Design: Use an abstraction library to abstract away risky APIs. Not a complete solution. Pre-design through Build: Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution. Operational: Use OS-level preventative functionality. Not a complete solution. C C++ Often times data-structure sentinels are used to mark structure of the data structure. A common example of this is the null character at the end of strings. Another common example is linked lists which may contain a sentinel to mark the end of the list. It is, of course dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the deletion or modification outside of some wrapper interface which provides safety. 1000 Category ChildOf 461 Deletion of data-structure sentinel C C++ The accidental addition of a data-structure sentinel can cause serious programming logic problems. High to Very High Availability: Generally this error will cause the data structure to not work properly by truncating the data. Pre-design: Use a language or compiler that performs automatic bounds checking. Design: Use an abstraction library to abstract away risky APIs. Not a complete solution. Pre-design through Build: Compiler-based canary mechanisms such as StackGuard, ProPolice, and Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution. Operational: Use OS-level preventative functionality. Not a complete solution. C C++ Data-structure sentinels are often used to mark structure of the data structure. A common example of this is the null character at the end of strings. Another common example is linked lists which may contain a sentinel to mark the end of the list. It is, of course dangerous, to allow this type of control data to be easily accessible. Therefore, it is important to protect from the addition or modification outside of some wrapper interface which provides safety. By adding a sentinel, one potentially could cause data to be truncated early. 1000 Weakness ChildOf 138 1000 Category ChildOf 461 Addition of data-structure sentinel C C++ A function can return a pointer to memory that is outside of the buffer that the pointer is expected to reference. 1000 Weakness ChildOf 119 1000 Category ChildOf 465 Illegal Pointer Value C C++ The code calls sizeof() on a malloced pointer type, which always returns the wordsize/8. This can produce an unexpected result if the programmer intended to determine how much memory has been allocated. High Primary (Weakness exists independent of other weaknesses) Integrity: This error can often cause one to allocate a buffer that is much smaller than what is needed, leading to resultant weaknesses such as buffer overflows. Implementation: use expressions such as "sizeof(*pointer)" instead of "sizeof(pointer)", unless you intend to run sizeof() on a pointer type to gain some platform independence or if you are allocating a variable on the stack. C C++ int main() { void *foo; printf("%d\n",sizeof(foo)); //this will return wordsize/8 return 0; }]]> The use of sizeof() on a pointer can sometimes generate useful information. An obvious case is to find out the wordsize on a platform. More often than not, the appearance of sizeof(pointer) indicates a bug. Robert Seacord EXP01-A. Do not take the sizeof a pointer to determine the size of a type https://www.securecoding.cert.org/confluence/display/seccode/EXP01-A.+Do+not+take+the+sizeof+a+pointer+to+determine+the+size+of+a+type 1000 Weakness ChildOf 682 1000 Category ChildOf 465 Use of sizeof() on a pointer type C C++ In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled. Medium Often results in buffer overflow conditions. Design: Use a platform with high-level memory abstractions. Implementation: Always use array indexing instead of direct pointer manipulation. Other: Use technologies for preventing buffer overflows. In this example, second_char is intended to point to the second byte of p. But, adding 1 to p actually adds sizeof(int) to p, giving a result that is incorrect (3 bytes off on 32-bit platforms). If the resulting memory address is read, this could potentially be an information leak. If it is a write, it could be a security-critical write to unauthorized memory-- whether or not it is a buffer overflow. Note that the above code may also be wrong in other ways, particularly in a little endian environment. Programmers will often try to index from a pointer by adding a number of bytes, even though this is wrong, since C and C++ implicitly scale the operand by the size of the data type. 1000 Weakness ChildOf 682 1000 Category ChildOf 465 630 View ChildOf 630 Unintentional pointer scaling C C++ The application subtracts one pointer from another in order to determine size, but this calculation can be incorrect if the pointers do not exist in the same memory chunk. Medium Authorization: There is the potential for arbitrary code execution with privileges of the vulnerable program. Pre-design through Build: Most static analysis programs should be able to catch these errors. Implementation: Save an index variable. This is the recommended solution. Rather than subtract pointers from one another, use an index variable of the same size as the pointers in question. Use this variable to "walk" from one pointer to the other and calculate the difference. Always sanity check this number. These types of bugs generally are the result of a typo. Although most of them can easily be found when testing of the program, it is important that one correct these problems, since they almost certainly will break the code. 1000 Weakness ChildOf 682 1000 Category ChildOf 465 Improper pointer subtraction C C++ A software system that accepts path input in the form of leading space (' filedir') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" 1000 Weakness ChildOf 41 Leading Space - ' filedir' All The application uses reflection capabilities to manage classes or code, but does not sufficiently control which classes or code can be selected based on external input. By leveraging reflection capabilities, an attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks. Example: A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection: The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher. However, the refactoring allows an attacker to instantiate any object that implements the Worker interface. If the command dispatcher is still responsible for access control, then whenever programmers create a new class that implements the Worker interface, they must remember to modify the dispatcher's access control code. If they fail to modify the access control code, then some Worker classes will not have any access control. One way to address this access control problem is to make the Worker object responsible for performing the access control check. An example of the re-refactored code follows: String ctl = request.getParameter("ctl"); Class cmdClass = Class.forName(ctl + "Command"); Worker ao = (Worker) cmdClass.newInstance(); ao.checkAccessControl(request); ao.doAction(request); Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes. This code also highlights another security problem with using reflection to build a command dispatcher. An attacker can invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the Worker interface; the default constructor for any object in the system can be invoked. If the object does not implement the Worker interface, a ClassCastException will be thrown before the assignment to ao, but if the constructor performs operations that work in the attacker's favor, the damage will already have been done. Although this scenario is relatively benign in simple applications, in larger applications where complexity grows exponentially it is not unreasonable that an attacker could find a constructor to leverage as part of an attack. If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner. This situation becomes a doomsday scenario if the attacker can upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker can use reflection to introduce new, presumably malicious, behavior into the application. 1000 Weakness ChildOf 398 1000 Weakness ChildOf 610 Unsafe Reflection Java The software does not properly protect an assumed-immutable element from being modified by an attacker. CVE-2002-1757 Relies on $PHP_SELF variable for authentication. CVE-2005-1905 Gain privileges by modifying assumed-immutable code addresses that are accessed by a driver. Factors: MAID issues can be primary to many other weaknesses, and they are a major factor in languages such as PHP. This happens when a particular input is critical enough to the functioning of the application that it should not be modifiable at all, but it is. A common programmer assumption is that certain variables are immutable; especially consider hidden form fields in web applications. So there are many examples where the MUTABILITY property is a major factor in a vuln. Common data types that are attacked are environment variables, web application parameters, and HTTP headers. 1000 Weakness ChildOf 398 Modification of Assumed-Immutable Data All The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields. If a web product does not properly protect assumed-immutable values from modification in hidden form fields, parameters, cookies, or URLs, this can lead to modification of critical data. Web applications often mistakenly make the assumption that data passed to the client in hidden fields or cookies is not susceptible to tampering. Failure to validate portions of data that are user-controllable can lead to the application processing incorrect, and often malicious, input. Assumed-Immutable Parameter Tampering It is recommended not to pass hidden fields or cookies (apart from a session cookie) to the server. Furthermore, do not use parameters that are not from immediate user input. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. CVE-2002-0108 Forum product allows spoofed messages of other users via hidden form fields for name and e-mail address. CVE-2000-0253 Shopping cart allows price modification via hidden form field. CVE-2000-0254 Shopping cart allows price modification via hidden form field. CVE-2000-0926 Shopping cart allows price modification via hidden form field. CVE-2000-0101 Shopping cart allows price modification via hidden form field. CVE-2000-0102 Shopping cart allows price modification via hidden form field. CVE-2000-0758 Allows admin access by modifying value of form field. CVE-2002-1880 Read messages by modifying message ID parameter. CVE-2000-1234 Send email to arbitrary users by modifying email parameter. CVE-2005-1652 Authentication bypass by setting a parameter. CVE-2005-1784 Product does not check authorization for configuration change admin script, leading to password theft via modified e-mail address field. CVE-2005-2314 Logic error leads to password disclosure. CVE-2005-1682 Modification of message number parameter allows attackers to read other people's messages. This is a primary weakness for many other weaknesses and functional consequences, including XSS, SQL injection, path disclosure, and file inclusion. For example, custom cookies commonly store session data or persistent data across sessions. This kind of session data is normally involved in security related decisions on the server side, such as user authentication and access control. Thus, the cookies might contain sensitive data such as user credentials and privileges. This is a dangerous practice, as it can often lead to improper reliance on the value of the client-provided cookie by the server side application. Without appropriate protection mechanisms, the client can easily tamper with cookies. Reliance on the cookies without detailed validation can lead to problems such as SQL injection. If you use cookie values for security related decisions on the server side, manipulating the cookies might lead to violations of security policies such as authentication bypassing, user impersonation and privilege escalation. In addition, storing sensitive data in the cookie without appropriate protection can also lead to disclosure of sensitive user data, especially data stored in persistent cookies. Hidden fields should not be trusted as secure parameters. An attacker can intercept and alter hidden fields in a post to the server as easily as user input fields. An attacker can simply parse the HTML for the substring < input type "hidden" or even just "hidden". Hidden field values displayed later in the session, such as on the following page, can open a site up to cross-site scripting attacks. This is a technology-specific MAID problem. 1000 Weakness ChildOf 471 629 View ChildOf 629 Web Parameter Tampering All 39 31 A PHP application does not properly protect against the modification of variables from external sources, such as query parameters or cookies. This can expose the application to numerous weaknesses that would not exist otherwise. Carefully identify which variables can be controlled or influenced by an external user, and consider adopting a naming convention to emphasize when externally modifiable variables are being used. An application should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking is performed when relying on input from outside a trust boundary. Do not allow your application to run with register_globals enabled. If you implement a register_globals emulator, be extremely careful of variable extraction, dynamic evaluation, and similar issues, since weaknesses in your emulation could allow external variable modification to take place even without register_globals. CVE-2000-0860 File upload allows arbitrary file read by setting hidden form variables to match internal variable names. CVE-2001-0854 Mistakenly trusts $PHP_SELF variable to determine if include script was called by its parent. CVE-2002-0764 PHP remote file inclusion by modified assumed-immutable variable. CVE-2001-1025 Modify key variable when calling scripts that don't load a library that initializes it. CVE-2003-0754 Authentication bypass by modifying array used for authentication. This is a language-specific instance of Modification of Assumed-Immutable Data (MAID). This can be resultant from direct request (alternate path) issues. It can be primary to weaknesses such as PHP file inclusion, SQL injection, XSS, authentication bypass, and others. 1000 Weakness ChildOf 471 1000 Compound_Element CanPrecede 98 PHP External Variable Modification PHP 77 The code uses a function that has inconsistent implementations across operating systems and versions, which might cause security-relevant portability problems. The behavior of functions in this category varies by operating system, and at times, even by operating system version. Implementation differences can include: - Slight differences in the way parameters are interpreted leading to inconsistent results. - Some implementations of the function carry significant security risks. - The function might not be defined on all platforms. 1000 Weakness ChildOf 398 Inconsistent Implementations All The behavior of this function is undefined unless its control parameter is set to a specific value. The Linux Standard Base Specification 2.0.1 for libc places constraints on the arguments to some internal functions [21]. If the constraints are not met, the behavior of the functions is not defined. It is unusual for this function to be called directly. It is almost always invoked through a macro defined in a system header file, and the macro ensures that the following constraints are met: The value 1 must be passed to the third parameter (the version number) of the following file system function: __xmknod The value 2 must be passed to the third parameter (the group argument) of the following wide character string functions: __wcstod_internal __wcstof_internal __wcstol_internal __wcstold_internal __wcstoul_internal The value 3 must be passed as the first parameter (the version number) of the following file system functions: __xstat __lxstat __fxstat __xstat64 __lxstat64 __fxstat64 1000 Weakness ChildOf 573 Undefined Behavior All A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. Medium Resultant (Weakness is typically related to the presence of some other weaknesses) Availability: NULL pointer dereferences usually result in the failure of the process. In very rare circumstances and environments, code execution is possible. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Implementation: If all pointers that could have been modified are sanity-checked previous to use, nearly all NULL pointer dereferences can be prevented. Example 1: NULL pointer dereference issue can occur through a number of flaws, including race conditions, and simple programming omissions. While there are no complete fixes aside from conscientious programming, the following steps will go a long way to ensure that NULL pointer dereferences do not occur. Before using a pointer, ensure that it is not equal to NULL: When freeing pointers, ensure they are not set to NULL, and be sure to set them to NULL once they are freed: If you are working with a multi-threaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the if statement; and unlock when it has finished. Example 2: In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a NULL pointer exception when it attempts to call the trim() method. Java CVE-2005-3274 race condition causes a table to be corrupted if a timer activates while it is being modified, leading to resultant NULL dereference; also involves locking. CVE-2002-1912 large number of packets leads to NULL dereference CVE-2005-0772 packet with invalid error status value triggers NULL dereference CVE-2004-0079 CVE-2004-0365 CVE-2003-1013 CVE-2003-1000 CVE-2004-0389 CVE-2004-0119 CVE-2004-0458 CVE-2002-0401 NULL pointer dereferences, while common, can generally be found and corrected in a simply way. They will always result in the crash of the process unless exception handling (on some platforms) is invoked, and even then, little can be done to salvage the process. NULL pointer dereferences are frequently resultant from rarely encountered error conditions, since these are most likely to escape detection during the testing phases. 1000 Weakness ChildOf 398 1000 Weakness PeerOf 373 630 View ChildOf 630 1000 690 Compound_Element CanPrecede 690 Null Dereference Null-pointer dereference Null Dereference (Null Pointer Dereference) C C++ Java .NET A weakness where the code path has: 1. start statement that assigns a null value to the pointer 2. end statement that dereferences a pointer 3. the code path does not contain any other statement that assigns value to the pointer The code uses deprecated or obsolete functions, which suggests that the code has not been actively reviewed or maintained. The following code uses the deprecated function getpw() to verify that a plaintext password matches a user's encrypted password. If the password is valid, the function sets result to 1; otherwise it is set to 0. Although the code often behaves correctly, using the getpw() function can be problematic from a security standpoint, because it can overflow the buffer passed to its second parameter. Because of this vulnerability, getpw() has been supplanted by getpwuid(), which performs the same lookup as getpw() but returns a pointer to a statically-allocated structure to mitigate the risk. Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby. In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a null pointer exception when it attempts to call the "Trim()" method. The following code constructs a string object from an array of bytes and a value that specifies the top 8 bits of each 16-bit Unicode character. In this example, the constructor may fail to correctly convert bytes to characters depending upon which charset is used to encode the string represented by nameBytes. Due to the evolution of the charsets used to encode strings, this constructor was deprecated and replaced by a constructor that accepts as one of its parameters the name of the charset used to encode the bytes for conversion. As programming languages evolve, functions occasionally become obsolete due to: - Advances in the language - Improved understanding of how operations should be performed effectively and securely - Changes in the conventions that govern certain operations Functions that are removed are usually replaced by newer counterparts that perform the same task in some different and hopefully improved way. Refer to the documentation for this function in order to determine why it is deprecated or obsolete and to learn about alternative ways to achieve the same functionality. The remainder of this text discusses general problems that stem from the use of deprecated or obsolete functions. 1000 Weakness ChildOf 398 Obsolete All The failure to account for the default case in switch statements may lead to complex logical errors and may aid in other, unexpected security-related conditions. Undefined: Depending on the logical circumstances involved, any consequences may result: e.g., issues of confidentiality, authentication, authorization, availability, integrity, accountability, or non-repudiation. Implementation: Ensure that there are no unaccounted for cases, when adjusting flow or values based on the value of a given variable. In switch statements, this can be accomplished through the use of the default label. In general, a safe switch statement has this form: This is because the assumption cannot be made that all possible cases are accounted for. A good practice is to reserve the default case for error handling. This flaw represents a common problem in software development, in which not all possible values for a variable are considered or handled by a given process. Because of this, further decisions are made based on poor information, and cascading failure results. This cascading failure may result in any number of security issues, and constitutes a significant failure in the system. In the case of switch style statements, the very simple act of creating a default case can mitigate this situation, if done correctly. Often however, the default cause is used simply to represent an assumed option, as opposed to working as a sanity check. This is poor practice and in some cases is as bad as omitting a default case entirely. 1000 Weakness ChildOf 398 Failure to account for default case in switch C C++ Java .NET The program has a signal handler that calls an unsafe function, leading to unpredictable results. There are several functions which -- under certain circumstances, if used in a signal handler -- may result in the corruption of memory, allowing for exploitation of the process. Low System Process Access control: It may be possible to execute arbitrary code through the use of a write-what-where condition. Integrity: Signal race conditions often result in data corruption. Requirements specification: A language might be chosen, which is not subject to this flaw, through a guarantee of reentrant code. Design: Design signal handlers to only set flags rather than perform complex functionality. Implementation: Ensure that non-reentrant functions are not found in signal handlers. Also, use sanity checks to ensure that state is consistently performing asynchronous actions which effect the state of execution. See Signal handler race condition, for an example usage of free() in a signal handler which is exploitable. This flaw is a subset of race conditions occurring in signal handler calls which is concerned primarily with memory corruption caused by calls to non-reentrant functions in signal handlers. Non-reentrant functions are functions that cannot safely be called, interrupted, and then recalled before the first call has finished without resulting in memory corruption. The function call syslog() is an example of this. In order to perform its functionality, it allocates a small amount of memory as "scratch space." If syslog() is suspended by a signal call and the signal handler calls syslog(), the memory used by both of these functions enters an undefined, and possibly, exploitable state. 1000 Weakness ChildOf 398 1000 Weakness PeerOf 364 1000 Weakness PeerOf 123 631 Category ChildOf 634 Unsafe function call from a signal handler C C++ A software system that accepts path input in the form of internal space ('file(SPACE)name') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" CVE-2000-0293 Filenames with spaces allow arbitrary file deletion when the product does not properly quote them; some overlap with path traversal. CVE-2001-1567 "+" characters in query string converted to spaces before sensitive file/extension (internal space), leading to bypass of access restrictions to the file. This is not necessarily an equivalence issue, but it can also be used to spoof icons or conduct information hiding via information truncation (see user interface errors). This weakness is likely to overlap quoting problems, e.g. the "Program Files" untrusted search path variants. It also could be an equivalence issue if filtering removes all extraneous spaces. 1000 Weakness ChildOf 41 file(SPACE)name (internal space) All The programmer accidentally uses the wrong operator, which changes the application logic in security-relevant ways. Low Pre-design through Build: Most static analysis programs should be able to catch these errors. Implementation: Save an index variable. This is the recommended solution. Rather than subtract pointers from one another, use an index variable of the same size as the pointers in question. Use this variable to "walk" from one pointer to the other and calculate the difference. Always sanity check this number. C These types of bugs generally are the result of a typo. Although most of them can easily be found when testing of the program, it is important that one correct these problems, since they almost certainly will break the code. 1000 Category ChildOf 569 Using the wrong operator All The code uses an operator for assignment when the intention was to perform a comparison. In many languages the compare statement is very close in appearance to the assignment statement and are often confused. Low Pre-design: Through Build: Many IDEs and static analysis products will detect this problem. Implementation: Place constants on the left. If one attempts to assign a constant with a variable, the compiler will of course produce an error. This bug is generally as a result of a typo and usually should cause obvious problems with program execution. If the comparison is in an if statement, the if statement will always return the value of the right-hand side variable. 1000 Weakness ChildOf 480 1000 Category ChildOf 569 Assigning instead of comparing C C++ Java .NET The code uses an operator for comparison when the intention was to perform an assignment. In many languages, the compare statement is very close in appearance to the assignment statement; they are often confused. Low Pre-design: Through Build: Many IDEs and static analysis products will detect this problem. C C++ Java This bug is mainly a typo and usually should cause obvious problems with program execution. The assignment will not always take place. 1000 Weakness ChildOf 480 1000 Category ChildOf 569 Comparing instead of assigning C C++ The code does not explicitly delimit a block that is intended to contain 2 or more statements, creating a logic error. In some languages, forgetting to explicitly delimit a block can result in a logic error that can, in turn, have security implications. Low This is a general logic error -- with all the potential consequences that this entails. Implementation: Always use explicit block delimitation and use static-analysis technologies to enforce this practice. In this example, when the condition is true, the intention may be that both x and y run. if (condition==true) x; y; In many languages, braces are optional for blocks, and -- in a case where braces are omitted -- it is possible to insert a logic error where a statement is thought to be in a block but is not. This is a common and well known reliability error. 1000 Weakness ChildOf 398 1000 Weakness ChildOf 670 Incorrect block delimitation All The program omits a break statement within a switch or other construct, causing the same code to execute in multiple conditions, when it is only expected to execute in one condition. Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should not be used. Medium Omission of a break statement might be intentional, in order to support fallthrough. Semantic understanding of expected program behavior is required to interpret whether the code is correct. Pre-design through Build: Most static analysis programs should be able to catch these errors. Implementation: The functionality of omitting a break statement could be clarified with an if statement. This method is much safer. Java C C++ Now one might think that if they just tested case12, it will display that the respective month "is a great month." However, if one tested November, one notice that it would display "November December is a great month." While most languages with similar constructs automatically run only a single branch, C and C++ are different. This has bitten many programmers, and can lead to critical code executing in situations where it should not. 1000 Weakness ChildOf 398 1000 Weakness ChildOf 670 Omitted break statement C C++ Java .NET The product does not sufficiently encapsulate critical data or functionality. Encapsulation is about drawing strong boundaries. In a web browser that might mean ensuring that your mobile code cannot be abused by other mobile code. On the server it might mean differentiation between validated data and unvalidated data, between one user's data and another's, or between data users are allowed to see and data that they are not. 1000 Category ChildOf 18 Encapsulation The program compares classes by name, which can cause it to use the wrong class if two different classes are treated as the same. High Authorization: If a program relies solely on the name of an object to determine identity, it may execute the incorrect or unintended code. Implementation: Use class equivalency to determine type. Rather than use the class name to determine if an object is of a given type, use the getClass() method, and == operator. If the decision to trust the methods and data of an object is based on the name of a class, it is possible for malicious users to send objects of the same name as trusted classes and thereby gain the trust afforded to known classes and types. 1000 Weakness ChildOf 485 Comparing Classes by Name Comparing classes by name Java Java packages are not inherently closed; therefore, relying on them for code security is not a good practice. Medium Confidentiality: Any data in a Java package can be accessed outside of the Java framework if the package is distributed. Integrity: The data in a Java class can be modified by anyone outside of the Java framework if the packages is distributed. Design through Implementation: Data should be private static and final whenever possible. This will assure that your code is protected by instantiating early, preventing access and tampering. Java The purpose of package scope is to prevent accidental access. However, this protection provides an ease-of-software-development feature but not a security feature, unless it is sealed. 1000 Weakness ChildOf 485 Relying on package-level scope Java The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session. Data can "bleed" from one session to another through member variables of singleton objects, such as Servlets, and objects from a shared pool. The following Servlet stores the value of a request parameter in a member field and then later echoes the parameter value to the response output stream. While this code will work perfectly in a single-user environment, if two users access the Servlet at approximately the same time, it is possible for the two request handler threads to interleave in the following way: Thread 1: assign "Dick" to name Thread 2: assign "Jane" to name Thread 1: print "Jane, thanks for visiting!" Thread 2: print "Jane, thanks for visiting!" Thereby showing the first user the second user's name. Many Servlet developers do not understand that, unless a Servlet implements the SingleThreadModel interface, the Servlet is a singleton; there is only one instance of the Servlet, and that single instance is used and re-used to handle multiple requests that are processed simultaneously by different threads. A common result of this misunderstanding is that developers use Servlet member fields in such a way that one user may inadvertently see another user's data. In other words, storing user data in Servlet member fields introduces a data access race condition. 1000 Weakness ChildOf 485 Data Leaking Between Users All 60 59 The application can be deployed with active debugging code that can create unintended entry points. The severity of the exposed debug application will depend on the particular instance. At the least, it will give an attacker sensitive information about the settings and mechanics of web applications on the server. At worst, as is often the case, the debug application will allow an attacker complete control over the web application and server, as well as confidential information that either of these access. Debug code can be used to bypass authentication. For example, suppose an application has a login script that receives a username and a password. Assume also that a third, optional, parameter, called "debug", is interpreted by the script as requesting a switch to debug mode, and that when this parameter is given the username and password are not checked. In such a case, it is very simple to bypass the authentication process if the special behavior of the application regarding the debug parameter is known. In a case where the form is: ]]> Then a conforming link will look like: An attacker can change this to: Which will grant the attacker access to the site, bypassing the authentication process. A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. In web-based applications, debug code is used to test and modify web application properties, configuration information, and functions. If a debug application is left on a production server, an attacker may be able to use it to perform these tasks. When this sort of debug code is left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application. While it is possible to leave debug code in an application in any language, in J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact. 1000 Weakness ChildOf 485 630 View ChildOf 630 Leftover Debug Code All A software system that accepts path input in the form of trailing slash ('filedir/') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" CVE-2002-0253 Overlaps infoleak CVE-2001-0446 CVE-2004-0334 CVE-2001-0893 CVE-2001-0892 CVE-2004-1814 BID:3518 1000 Weakness ChildOf 41 filedir/ (trailing slash, trailing /) All A class has a cloneable() method that is not declared final, which allows an object to be created without calling the constructor. This can cause the object to be in an unexpected state. 1000 Category ChildOf 490 Mobile Code: Object Hijack Java Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers. Medium Confidentiality: "Inner Classes" data confidentiality aspects can often be overcome. Implementation: Using sealed classes protects object-oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways. Implementation: Inner Classes do not provide security. Warning: Never reduce the security of the object from an outer class, going to an inner class. If your outer class is final or private, ensure that your inner class is private as well. Example: The following Java Applet code mistakenly makes use of an inner class. Java Inner classes quietly introduce several security concerns because of the way they are translated into Java bytecode. In Java source code, it appears that an inner class can be declared to be accessible only by the enclosing class, but Java bytecode has no concept of an inner class, so the compiler must transform an inner class declaration into a peer class with package level access to the original outer class. More insidiously, since an inner class can access private fields in their enclosing class, once an inner class becomes a peer class in bytecode, the compiler converts private fields accessed by the inner class into protected fields. Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running. 1000 Weakness ChildOf 668 1000 Category ChildOf 490 Mobile Code: Use of Inner Class Publicizing of private data when using inner classes Java The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values. Declare all public fields final when possible. The following Java Applet code mistakenly declares a member variable public but not final. Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running. All public member variables in an Applet and in classes used by an Applet should be declared final to prevent an attacker from manipulating or gaining unauthorized access to the internal state of the Applet. 1000 Weakness ChildOf 668 1000 Category ChildOf 490 Mobile Code: Non-Final Public Field Java The product downloads external source or binaries and executes it without sufficiently verifying the origin and integrity of the downloaded code. Medium Implementation: Avoid doing this without proper cryptographic safeguards. Java This is an unsafe practice and should not be performed unless one can use some type of cryptographic protection to assure that the mobile code has not been altered. 1000 Category ChildOf 490 1000 Weakness ChildOf 669 1000 Weakness PeerOf 79 Invoking untrusted mobile code Java The product has a method that is declared public, but returns a reference to a private array, which could then be modified in unexpected ways. Declare the method private. Clone the member data and keep an unmodified version of the data private to the object. Use public setter methods that govern how a member can be modified. 1000 Weakness ChildOf 485 Private Array-Typed Field Returned From A Public Method C C++ Java .NET Assigning public data to a private array is equivalent to giving public access to the array. Do not allow objects to modify private members of a class. 1000 Weakness ChildOf 485 Public Data Assigned to Private Array-Typed Field C C++ Java .NET Revealing system data or debugging information helps an adversary learn about the system and form an attack plan. Production applications should never use methods that generate internal details such as stack traces and error messages unless that information is directly committed to a log that is not viewable by the end user. All error message text should be HTML entity encoded before being written to the log file to protect against potential cross-site scripting attacks against the viewer of the logs Example 1: The following code prints the path environment variable to the standard error stream: Example 2: The following code prints an exception to the standard error stream: Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program. Example 3: The following code constructs a database connection string, uses it to create a new connection to the database, and prints it to the console. Depending on the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program. An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.. An attacker can cause errors to occur by submitting unusual requests to the web application. The response to these errors can reveal detailed system information, deny service, cause security mechanisms to fail, or crash the server. An attacker can use error messages that reveal technologies, operating systems, and product versions to tune the attack against known vulnerabilities in these technologies. The application uses diagnostic methods that provide significant implementation details such as stack traces as part of its error handling mechanism. 1000 Weakness ChildOf 200 System Information Leak All The code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class. Cloneable classes are effectively open classes, since data cannot be hidden in them. Medium Confidentiality: A class which can be cloned can be produced without executing the constructor. Implementation: Make classes uncloneable by defining a clone function like: public final void clone() throws java.lang.CloneNotSupportedException { throw new java.lang.CloneNotSupportedException(); } Implementation: If you do make your classes clonable, ensure that your clone method is final and throw super.clone(). Java Classes which do no explicitly deny cloning can be cloned by any other class without running the constructor. This is, of course, dangerous since numerous checks and security aspects of an object are often taken care of in the constructor. 1000 Weakness ChildOf 485 1000 Weakness ChildOf 200 Information leak through class cloning C++ Java .NET The code contains a class with sensitive data, but the class does not explicitly deny serialization. The data can be accessed by serializing the class through another class. Serializable classes are effectively open classes since data cannot be hidden in them. High Confidentiality: an attacker can write out the class to a byte stream, then extract the important data from it. Implementation: In Java, explicitly define final writeObject() to prevent serialization. This is the recommended solution. Define the writeObject() function to throw an exception explicitly denying serialization. Implementation: Make sure to prevent serialization of your objects. Classes that do not explicitly deny serialization can be serialized by any other class, which can then in turn use the data stored inside it. 1000 Weakness ChildOf 485 1000 Weakness ChildOf 200 Information leak through serialization Java Information sent over a network can be compromised while in transit. An attacker may be able to read/modify the contents if the data are sent in plaintext or are weakly encrypted. The application configuration should ensure that SSL or an encryption mechanism of equivalent strength and vetted reputation is used for all access-controlled pages. If an application uses SSL to guarantee confidential communication with client browsers, the application configuration should make it impossible to view any access controlled page without SSL. There are three common ways for SSL to be bypassed: - (1) A user manually enters URL and types "HTTP" rather than "HTTPS". - (2) Attackers intentionally send a user to an insecure URL. - (3) A programmer erroneously creates a relative link to a page in the application, failing to switch from HTTP to HTTPS. (This is particularly easy to do when the link moves between public and secured areas on a web site.) 1000 Weakness ChildOf 311 1000 Category ChildOf 4 J2EE Misconfiguration: Insecure Transport Java A software system that accepts path input in the form of multiple leading slash ('//multiple/leading/slash') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" CVE-2002-1483 CVE-1999-1456 CVE-2004-0578 CVE-2002-0275 CVE-2004-1032 CVE-2002-1238 CVE-2004-1878 CVE-2005-1365 CVE-2000-1050 Access directory using multiple leading slash. CVE-2001-1072 Bypass access restrictions via multiple leading slash, which causes a regular expression to fail. CVE-2004-0235 Archive extracts to arbitrary files using multiple leading slash in filenames in the archive. 1000 Weakness ChildOf 41 //multiple/leading/slash ('multiple leading slash') All An object contains a field that is not marked final, which might allow it to be modified in unexpected ways. High Integrity: The object could potentially be tampered with. Confidentiality: The object could potentially allow the object to be read. Design through Implementation: Make any static fields private and final. C++ Java This is a uninitiated static class which can be accessed without a get-accessor and changed without a set-accessor. Non-final fields, which are not public can be read and written to by arbitrary Java code. 1000 Weakness ChildOf 485 Overflow of static internal buffer C++ Java The product mixes trusted and untrusted data in the same data structure or structured message. By combining trusted and untrusted data in the same data structure, it becomes easier for programmers to mistakenly trust unvalidated data. The following code accepts an HTTP request and stores the usrname parameter in the HTTP session object before checking to ensure that the user has been authenticated. Java C# Without well-established and maintained trust boundaries, programmers will inevitably lose track of which pieces of data have been validated and which have not. This confusion will eventually allow some data to be used without first being validated. A trust boundary can be thought of as line drawn through a program. On one side of the line, data is untrusted. On the other side of the line, data is assumed to be trustworthy. The purpose of validation logic is to allow data to safely cross the trust boundary--to move from untrusted to trusted. A trust boundary violation occurs when a program blurs the line between what is trusted and what is untrusted. The most common way to make this mistake is to allow trusted and untrusted data to commingle in the same data structure. 1000 Weakness ChildOf 485 Trust Boundary Violation All The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid. Data that is untrusted can not be trusted to be well-formed. Medium Availability: If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate. Authorization: Code could potentially make the assumption that information in the deserialized object is valid. Functions which make this dangerous assumption could be exploited. Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data. Implementation: Use the signing features of a language to assure that deserialized data has not been tainted. Implementation: When deserializing data populate a new object rather than just deserializing, the result is that the data flows through safe input validation and that the functions are safe. Implementation: Explicitly define final readObject() to prevent deserialization. An example of this is: private final void readObject(ObjectInputStream in) throws java.io.IOException { throw new java.io.IOException("Cannot be deserialized"); } Implementation: Make fields transient to protect them from deserialization. Java It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security -- which is of course a dangerous security assumption. An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly. 1000 Weakness ChildOf 485 Deserialization of untrusted data All The application contains code that appears to be malicious in nature. A developer might insert malicious code with the intent to subvert the security of an application or its host system at some time in the future. It generally refers to a program that performs a useful service but exploits rights of the program's user in a way the user does not intend. Remove the malicious code and start an effort to ensure that no more malicious code exists. This may require a detailed review of all code, as it is possible to hide a serious attack in only one or two lines of code. These lines may be located almost anywhere in an application and may have been intentionally obfuscated by the attacker. Malicious flaws have acquired colorful names, including Trojan horse, trapdoor, timebomb, and logic-bomb. The term "Trojan horse" was introduced by Dan Edwards and recorded by James Anderson [18] to characterize a particular computer security threat; it has been redefined many times [4,18-20]. 1000 Category ChildOf 505 Malicious Since the author of malicious code needs to disguise it somehow so that it will be invoked by a nonmalicious user (unless the author means also to invoke the code, in which case he or she presumably already possesses the authorization to perform the intended sabotage), almost any malicious code can be called a Trojan horse. A Trojan horse that replicates itself by copying its code into other program files (see case MA1) is commonly referred to as a virus. One that replicates itself by creating new processes or files to contain its code, instead of modifying existing storage entities, is often called a worm. Denning provides a general discussion of these terms; differences of opinion about the term applicable to a particular flaw or its exploitations sometimes occur. Potentially malicious dynamic code compiled at runtime can conceal any number of attacks that will not appear in the baseline. The use of dynamically compiled code could also allow the injection of attacks on post-deployed applications. 1000 Weakness ChildOf 506 Trojan Horse Non-replicating malicious code only resides on the target system or software that is attacked; it does not attempt to spread to other systems. 1000 Weakness ChildOf 507 Non-Replicating Replicating malicious code, including viruses and worms, will attempt to attack other systems once it has successfully compromised the target system or software. 1000 Weakness ChildOf 507 Replicating (virus) A software system that accepts path input in the form of multiple internal slash ('/multiple//internal/slash/') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" CVE-2002-1483 Read files with full pathname using multiple internal slash. 1000 Weakness ChildOf 41 /multiple//internal/slash ('multiple internal slash') All A trapdoor is a hidden piece of code that responds to a special input, allowing its user access to resources without passing through the normal security enforcement mechanism. 1000 Weakness ChildOf 506 Trapdoor 56 A time-bomb or logic-bomb is a piece of code that remains dormant in the host system until a certain "detonation" time or event occurs. When triggered, a time-bomb may deny service by crashing the system, deleting files, or degrading system response-time. A time-bomb might be placed within either a replicating or non-replicating Trojan horse. Typical examples of triggers include system date or time mechanisms, random number generators, and counters that wait for an opportunity to launch their payload. When triggered, a time-bomb may deny service by crashing the system, deleting files, or degrading system response-time. 1000 Weakness ChildOf 506 Logic/Time Bomb All "Spyware" is a commonly used term with many definitions and interpretations, although it is generally meant to refer to software that collects information or installs functionality that human users might not allow if they were fully aware of the actions being taken by the software. 1000 Weakness ChildOf 506 A covert channel is simply a path used to transfer information in a way not intended by the system's designers. Typically the system has not given authorization for the transmission and has no knowledge of its occurrence. This can be thought of as an emergent resource, meaning that it was not an originally intended resource, however it exists due the applications behaviors. 1000 Category ChildOf 513 Covert Channel Covert channels are frequently classified as either storage or timing channels. A storage channel transfers information through the setting of bits by one program and the reading of those bits by another. What distinguishes this case from that of ordinary operation is that the bits are used to convey encoded information. Examples would include using a file intended to hold only audit information to convey user passwords--using the name of a file or perhaps status bits associated with it that can be read by all users to signal the contents of the file. Steganography, concealing information in such a manner that no one but the intended recipient knows of the existence of the message, is a good example of a covert storage channel. High Confidentiality: Covert storage channels may provide attackers with important information about the system in question. Implementation: Ensure that all reserved fields are set to zero before messages are sent and that no unnecessary information is included. An excellent example of covert storage channels in a well known application is the ICMP error message echoing functionality. Due to ambiguities in the ICMP RFC, many IP implementations use the memory within the packet for storage or calculation. For this reason, certain fields of certain packets -- such as ICMP error packets which echo back parts of received messages -- may contain flaws or extra information which betrays information about the identity of the target operating system. This information is then used to build up evidence to decide the environment of the target. This is the first crucial step in determining if a given system is vulnerable to a particular flaw and what changes must be made to malicious code to mount a successful attack. Covert storage channels occur when out-of-band data is stored in messages for the purpose of memory reuse. If these messages or packets are sent with the unnecessary data still contained within, it may tip off malicious listeners as to the process that created the message. With this information, attackers may learn any number of things, including the hardware platform, operating system, or algorithms used by the sender. This information can be of significant value to the user in launching further attacks. 1000 Weakness ChildOf 514 Storage Covert storage channel This weakness can be found at CWE-385. 604 View ChildOf 604 A software system that accepts path input in the form of multiple trailing slash ('/multiple/trailing/slash//') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" CVE-2002-1078 Directory listings in web server using multiple trailing slash 1000 Weakness ChildOf 41 1000 Weakness CanPrecede 289 /multiple/trailing/slash// ('multiple trailing slash') All Allowing a .NET application to run at potentially escalated levels of access to the underlying operating and file systems can be dangerous and result in various forms of attacks. .NET server applications can optionally execute using the identity of the user authenticated to the client. The intention of this functionality is to bypass authentication and access control checks within the .NET application code. Authentication is done by the underlying web server (Microsoft Internet Information Service IIS), which passes the authenticated token, or unauthenticated anonymous token, to the .NET application. Using the token to impersonate the client, the application then relies on the settings within the NTFS directories and files to control access. Impersonation enables the application, on the server running the .NET application, to both execute code and access resources in the context of the authenticated and authorized user. 1000 Category ChildOf 519 The product does not require that users should have strong passwords, which makes it easier for attackers to compromise user accounts. An authentication mechanism is only as strong as its credentials. For this reason, it is important to require users to have strong passwords. A password strength policy should contain the following attributes: (1) Minimum and maximum length; (2) Require mixed character sets (alpha, numeric, special, mixed case); (3) Do not contain user name; (4) Expiration; (5) No password reuse. Authentication mechanisms should always require sufficiently complex passwords and require that they be periodically changed. Lack of password complexity significantly reduces the search space when trying to guess user's passwords, making brute-force attacks easier. 1000 Category ChildOf 255 1000 Weakness ChildOf 693 55 49 70 16 This weakness occurs when the application transmits or stores authentication credentials and uses an insecure method that is susceptible to unauthorized interception and/or retrieval. Attackers are potentially able to bypass authentication mechanisms, hijack a victim's account, and obtain the role and respective access level of the accounts. 1000 Category ChildOf 255 629 View ChildOf 629 1000 Weakness ChildOf 668 50 Login pages not using adequate measures to protect the user name and password while they are in transit from the client to the server. Enforce SSL use for the login page or any page used to transmit user credentials or other sensitive information. Even if the entire site does not use SSL, it MUST use SSL for login. Additionally, to help prevent phishing attacks, make sure that SSL serves the login page. SSL allows the user to verify the identity of the server to which they are connecting. If the SSL serves login page, the user can be certain they are talking to the proper end system. A phishing attack would typically redirect a user to a site that does not have a valid trusted server certificate issued from an authorized supplier. SSL (Secure Socket Layer) provides data confidentiality and integrity to HTTP. By encrypting HTTP messages, SSL protects from attackers eavesdropping or altering message contents. Login pages should always employ SSL to protect the user name and password while they are in transit from the client to the server. Lack of SSL use exposes the user credentials as clear text during transmission to the server and thus makes the credentials susceptible to eavesdropping. 1000 Weakness ChildOf 522 The application uses a cache to maintain a pool of objects, threads, connections, pages, or passwords to minimize the time it takes to access them or the resources to which they connect. If implemented improperly, these caches can allow access to unauthorized information or cause a denial of service vulnerability. 1000 Weakness ChildOf 200 For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. You should use a restrictive caching policy for forms and web pages that potentially contain sensitive information. The risk is that this information could be stored in a client-side cache (with most browsers) and left behind for other users to find. The most severe risk is for applications where the intended access is from public terminals, such as those in libraries and Internet cafes. 1000 Weakness ChildOf 524 37 Environmental variables may contain sensitive information about a remote server. 1000 Weakness ChildOf 200 A common mistake by administrators or developers is to leave the CVS directory as a subdirectory on many of the folders in the web server. Information contained within that directory (such as usernames, filenames, path root and IP addresses) could be recovered by an attacker and used for malicious purposes. Recommendations include removing any CVS directories and repositories from the production server, disabling the use of remote CVS repositories, and ensuring that the latest CVS patches and version updates have been performed. 1000 Weakness ChildOf 538 1000 Weakness ChildOf 552 The application generates a core dump file in a directory that is accessible to parties outside of the intended control sphere. 1000 Weakness ChildOf 538 1000 Weakness ChildOf 552 These files allow the attacker to know the setup of the security Access Control Lists. This will give the attacker information that may allow the attacker to bypass the security of the site. 1000 Weakness ChildOf 538 1000 Weakness ChildOf 552 A software system that accepts path input in the form of multiple internal backslash ('\multiple\trailing\\slash') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" 1000 Weakness ChildOf 41 \multiple\\internal\backslash All Often, old files are renamed with an extension such as .~bk to distinguish them from production files. The source code for old files that have been renamed in this manner and left in the webroot can often be retrieved. At a minimum, an attacker who retrieves this file would have all the information contained in it, whether that be database calls, the format of parameters accepted by the application, or simply information regarding the architectural structure of your site. Recommendations include implementing a security policy within your organization that prohibits backing up web application source code in the webroot. 1000 Weakness ChildOf 538 1000 Weakness ChildOf 552 Accessible test applications can pose a variety of security risks. Since developers or administrators rarely consider that someone besides themselves would even know about the existence of these applications, it is common for them to contain sensitive information or functions. Examples of common issues with test applications include administrative functions, listings of usernames, passwords or session identifiers and information about the system, server or application configuration. 1000 Weakness ChildOf 540 1000 Weakness ChildOf 552 Information written to log files can be of a sensitive nature and give valuable guidance to an attacker. 1000 Weakness ChildOf 538 1000 Weakness ChildOf 552 A server.log file was found. This can give information on whatever application left the file. Usually this can give full path names and system information, and sometimes usernames and passwords. File/Directory 1000 Weakness ChildOf 532 1000 Weakness ChildOf 552 631 Category ChildOf 632 The application does not sufficiently restrict access to a log file that is used for debugging. 1000 Weakness ChildOf 532 1000 Weakness ChildOf 552 A command shell error message indicates that there exists an unhandled exception in the web application code. In many cases, an attacker can leverage the conditions that cause these errors in order to gain unauthorized access to the system. 1000 Weakness ChildOf 210 A servlet error message indicates that there exists an unhandled exception in your web application code and may provide useful information to an attacker. In many cases, an attacker can leverage the conditions that cause these errors in order to gain unauthorized access to the system. The error message may contain the location of the file in which the offending function is located. This may disclose the web root's absolute path as well as give the attacker the location of application include files or configuration information. It may even disclose the portion of code that failed. 1000 Weakness ChildOf 210 In many cases, an attacker can leverage the conditions that cause unhandled exception errors in order to gain unauthorized access to the system. 1000 Weakness ChildOf 210 Java Weaknesses in this category are related to information leaks in files and directories. 1000 Weakness ChildOf 200 All 95 Persistent cookies are cookies that are stored on the browser's hard drive. This can cause security and privacy issues depending on the information stored in the cookie and how it is accessed. Cookies are small bits of data that are sent by the web application but stored locally in the browser. This lets the application use the cookie to pass information between pages and store variable information. The web application controls what information is stored in a cookie and how it is used. Typical types of information stored in cookies are session Identifiers, personalization and customization information, and in rare cases even usernames to enable automated logins. There are two different types of cookies: session cookies and persistent cookies. Session cookies just live In the browser's memory, and are not stored anywhere, but persistent cookies are stored on the browser's hard drive. 1000 Weakness ChildOf 538 21 39 31 60 59 A software system that accepts path input in the form of trailing backslash ('filedir\') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" CVE-2004-0847 1000 Weakness ChildOf 41 filedir\ (trailing backslash) All There are situations where it is critical to remove source code from an area or server. For example, obtaining Perl source code on a system allows an attacker to view the logic of the script and extract extremely useful information such as code bugs or logins and passwords. Recommendations include removing this script from the web server and moving it to a location not accessible from the Internet. 1000 Weakness ChildOf 538 1000 Weakness ChildOf 552 If an include file source is accessible, the file can contain usernames and passwords, as well as sensitive information pertaining to the application and system. 1000 Weakness ChildOf 540 1000 Weakness ChildOf 552 The application fails to protect or delete a log file related to cleanup. 1000 Weakness ChildOf 532 1000 Weakness ChildOf 552 The use of a singleton pattern may not be thread-safe. Use Thread-Specific Storage Pattern This method is part of a singleton pattern, yet the following singleton() pattern is not thread-safe. It fails to ensure the creation of only one object. Java Consider the following course of events: Thread A enters the method, finds singleton to be null, begins the NumberConverter constructor, and then is swapped out of execution. Thread B enters the method and finds that singleton remains null. This will happen if A was swapped out during the middle of the constructor, for the object reference is not set to point at the new object on the heap until the object is fully initialized. Thread B continues and constructs another NumberConverter object and returns it while exiting the method. Thread A continues, finishes constructing its NumberConverter object, and returns its version. It created and returned two different objects. Many programmers turned to the double-check pattern to avoid the overhead of a synchronized call, which is an extension of the one employed, until it too was shown to be not thread-safe. 1000 Weakness ChildOf 662 1000 Weakness ChildOf 383 Java The application does not contain a standard error handling mechanism, which might introduce inconsistent error handling and resultant weaknesses. If the application handles error messages individually, on a one-by-one basis, this is likely to result in inconsistent error handling. The causes of errors may be lost. Also, detailed information about the causes of an error may be unintentionally returned to the user. 1000 Category ChildOf 388 Dynamically loaded code has the potential to be malicious. Avoid the use of class loading as it greatly complicates code analysis. If the application requires dynamic class loading, it should be well understood and documented. All classes that may be loaded should be predefined and avoid the use of dynamically created classes from byte arrays. The class loader executes the static initializers when the class is loaded. A malicious attack may be hidden in the static initializer and therefore does not require the execution of a specific method. An attack may also be hidden in any other method in the dynamically loaded code. The use of dynamic code could also enable an attacker to insert an attack into an application after it has been deployed. The attack code would not be in the baseline, but loaded dynamically while the application is running. 1000 Weakness ChildOf 485 Java The code contains comments that suggest the presence of bugs, incomplete functionality, or weaknesses. Many suspicious comments, such as BUG, HACK, FIXME, LATER, LATER2, TODO, in the code indicate missing security functionality and checking. Others indicate code problems that programmers should fix, such as hard-coded variables, error handling, not using stored procedures, and performance issues. 1000 Weakness ChildOf 398 The program uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change. If the developer does not find all occurrences of the hard coded constants, an incorrect policy decision may be made if one of the constants is not changed. Making changes to these values will require code changes that may be difficult or impossible once the system is released to the field. In addition, these hard-coded values may become available to attackers if the code is ever disclosed. 1000 Weakness ChildOf 398 A directory listing is inappropriately exposed, yielding potentially sensitive information to attackers. Recommendations include restricting access to important directories or files by adopting a need to know requirement for both the document and server root, and turning off features such as Automatic Directory Listings that could expose private files and provide information that could be utilized by an attacker when formulating or conducting an attack. Risks associated with an attacker discovering a Directory Listing, which is a complete index of all of the resources located in that directory, result from the fact that files that should remain hidden, such as data files, backed-up source code, or applications in development, may then be visible. The specific risks depend upon the specific files that are listed and accessible. 1000 Weakness ChildOf 538 1000 Weakness ChildOf 552 The software fails to mask passwords during entry, increasing the potential for attackers to observe and capture passwords. Recommendations include requiring all password fields in your web application be masked to prevent other users from seeing this information. Basic web application security measures include masking all passwords entered by a user when logging in to a web application. Normally, each character in a password entered by a user is instead represented with an asterisk. 1000 Category ChildOf 255 1000 Weakness ChildOf 522 1000 Weakness ChildOf 668 A software system that accepts path input in the form of single dot directory exploit ('/./') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" CVE-2000-0004 CVE-2002-0304 BID:6042 CVE-1999-1083 Possibly (could be a cleansing error) CVE-2004-0815 "/./////etc" cleansed to ".///etc" then "/etc" CVE-2002-0112 1000 Weakness ChildOf 41 /./ (single dot directory) All Certain conditions, such as network failure, will cause a server error message to be displayed. While error messages in and of themselves are not dangerous, per se, it is what an attacker can glean from them that might cause eventual problems. Recommendations include designing and adding consistent error handling mechanisms which are capable of handling any user input to your web application, providing meaningful detail to end-users, and preventing error messages that might provide information useful to an attacker from being displayed. 1000 Weakness ChildOf 210 1000 Weakness CanAlsoBe 211 If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection. For instance, the character strings /./ and / both mean current directory. If /SomeDirectory is a protected directory and an attacker requests /./SomeDirectory, the attacker may be able to gain access to the resource if /./ is not converted to / before the authorization check is performed. 1000 Weakness ChildOf 287 Files or directories are accessible in the environment that should not be. File/Directory 1000 Category ChildOf 2 631 Category ChildOf 632 1000 Weakness ChildOf 668 A possible shell file exists in /cgi-bin/ or other accessible directories. This is extremely dangerous and can be used by an attacker to execute commands on the web server. 1000 Weakness ChildOf 552 The ASP.NET application does not use an input validation framework. Unchecked input is the leading cause of vulnerabilities in ASP.NET applications. Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others. Use the ASP.NET validation framework to check all program input before it is processed by the application. Example uses of the validation framework include checking to ensure that: - Phone number fields contain only valid characters in phone numbers - Boolean values are only "T" or "F" - Free-form strings are of a reasonable length and composition In certain versions of ASP.Net, there is an input validation error that allows a malicious user to input some ASCII characters in a special Unicode encoding in the range ff00 to ff60. When the response encoding is not Unicode, these characters are decoded to their ASCII values, and this way can be used to launch cross site scripting attacks. The relevant Unicode strings are %uff1c, which is decoded to <, and %uff1e, which is decoded to >. 1000 Category ChildOf 10 1000 Weakness ChildOf 20 .NET The J2EE application stores a plaintext password in a configuration file. Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers Do not hardwire passwords into your software. Good password management guidelines require that a password never be stored in plaintext. 1000 Category ChildOf 4 1000 Weakness ChildOf 522 Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges. The use of impersonated credentials allows an ASP.NET application to run with either the privileges of the client on whose behalf it is executing or with arbitrary privileges granted in its configuration. 1000 Category ChildOf 10 The application uses the getlogin() function in a multithreaded context, potentially causing it to return incorrect values. The getlogin() function returns a pointer to a string that contains the name of the user associated with the calling process. The function is not reentrant, meaning that if it is called from another process, the contents are not locked out and the value of the string can be changed by another process. This makes it very risky to use because the username can be changed by other processes, so the results of the function cannot be trusted. Using names for security purposes is not advised. Names are easy to forge and can have overlapping user IDs, potentially causing confusion or impersonation. Use getlogin_r() instead, which is reentrant, meaning that other processes are locked out from changing the username. The following code relies on getlogin() to determine whether or not a user is trusted. It is easily subverted. pw_gid)) { allow(); } else { deny(); }]]> 1000 Weakness ChildOf 663 1000 Category ChildOf 557 C C++ A software system that accepts path input in the form of asterisk wildcard ('filedir*') without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. see the vulnerability category "Path Equivalence" CVE-2004-0696 List directories using desired path and "*" CVE-2002-0433 List files in web server using "*.ext" 1000 Weakness ChildOf 41 filedir* (asterisk / wildcard) All The product calls umask() with an incorrect argument that is specified as if it is an argument to chmod(). The umask() man page begins with the false statement: "umask sets the umask to mask & 0777" Although this behavior would better align with the usage of chmod(), where the user provided argument specifies the bits to enable on the specified file, the behavior of umask() is in fact opposite: umask() sets the umask to ~mask & 0777. The umask() man page goes on to describe the correct usage of umask(): "The umask is used by open() to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument to open(2) (so, for example, the common umask default value of 022 results in new files being created with permissions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666)." 1000 Weakness ChildOf 687 C Implementation The software contains dead code, which can never be executed. Dead code is source code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed. The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null, while on the only path where s can be assigned a non-null value there is a return statement. In the following class, two private methods call each other, but since neither one is ever invoked from anywhere else, they are both dead code. (In this case it is a good thing that the methods are dead: invoking either one would cause an infinite loop.) The field named glue is not used in the following class. The author of the class has accidentally put quotes around the field name, transforming it into a string constant. Dead code can lead to confusion during code maintenance and result in unrepaired vulnerabilities. 1000 Weakness ChildOf 398 A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash. The following function returns a stack address. Because local variables are allocated on the stack, when a program returns a pointer to a local variable, it is returning a stack address. A subsequent function call is likely to re-use this same stack address, thereby overwriting the value of the pointer, which no longer corresponds to the same variable since a function's stack frame is invalidated when it returns. At best this will cause the value of the pointer to change unexpectedly. In many cases it causes the program to crash the next time the pointer is dereferenced. The problem can be hard to debug because the cause of the problem is often far removed from the symptom. 1000 Weakness ChildOf 398 1000 Weakness ChildOf 672 C C++ The variable's value is assigned but never used, making it a dead store. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug. The following code excerpt assigns to the variable r and then overwrites the value without using it. This variable's value is not used. After the assignment, the variable is either assigned another value or goes out of scope. 1000 Weakness ChildOf 398 Using Hibernate to execute a dynamic SQL statement built with user-controlled input can allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands. Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen. Design: Follow the principle of least privilege when creating user accounts to a SQL database. Users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data. Design: Duplicate any filtering done on the client-side on the server side. Implementation: Implement SQL strings using prepared statements that bind variables. Prepared statements that do not bind variables can be vulnerable to attack. Implementation: Use vigorous white-list style checking on any user input that may be used in a SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that have been entered in the database may neglect to escape meta-characters before use. Narrowly define the set of safe characters based on the expected value of the parameter in the request. 1000 Weakness ChildOf 89 Attackers can easily modify cookies, and reliance without detailed validation can lead to problems like SQL injection and other errors. It is dangerous to use cookies to set a user's privileges. The cookie can be manipulated to escalate an attacker's privileges to an administrative level. 1000 Category ChildOf 254 1000 Weakness ChildOf 668 39 31 Without proper access control, executing a SQL statement that contains a user-controlled primary key can allow an attacker to view unauthorized records. The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. The identifier is selected from a list of all invoices associated with the current authenticated user. The problem is that the developer has failed to consider all of the possible values of id. Although the interface generates a list of invoice identifiers that belong to the current user, an attacker can bypass this interface to request any desired invoice. Because the code in this example does not check to ensure that the user has permission to access the requested invoice, it will display any invoice, even if it does not belong to the current user. Database access control errors occur when: 1. Data enters a program from an untrusted source. 2. The data is used to specify the value of a primary key in a SQL query. 1000 Weakness ChildOf 639 The product does not properly synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes. A shared variable vulnerability can be prevented by removing the use of static variables used between servlets or to provide protection when shared access is absolutely needed. In this case, access should be synchronized. Java The vulnerability can exist in servlets because a servlet is multi-threaded, and shared static variables are not protected from concurrent access. This is a typical programming mistake in J2EE applications, since the multi-threading is handled by the framework. The use of shared variables can be exploited by attackers to gain information or to cause denial of service conditions. If this shared data contains sensitive information, it may be manipulated or displayed in another user session. If this data is used to control the application, its value can be manipulated to cause the application to crash or perform poorly. 1000 Weakness ChildOf 662 1000 Category ChildOf 557 1000 Weakness PeerOf 488 All 25 The software contains a finalize() method that does not call super.finalize(). The following method omits the call to super.finalize(). Java The Java Language Specification states that it is a good practice for a finalize() method to call super.finalize() 1000 Category ChildOf 399 1000 Weakness ChildOf 573 1000 Weakness ChildOf 404 Java A software system that accepts path input in the form of 'dirname/fakechild/../realchild/filename' without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files. See example at 'http://www.securityfocus.com/bid/1025/discuss' for more detail. see the vulnerability category "Path Equivalence" CVE-2001-1152 CVE-2000-0191 CVE-2005-1366 CGI source disclosure using "dirname/../cgi-bin" This is a manipulation that uses an injection for one consequence (containment violation using relative path) to achieve a different consequence (equivalence by alternate name). 1000 Weakness ChildOf 41 dirname/fakechild/../realchild/filename All The software contains an expression that will always evaluate to false. The following method never sets the variable secondCall after initializing it to false. (The variable firstCall is mistakenly used twice.) The result is that the expression firstCall & secondCall will always evaluate to false, so setUpDualCall() will never be invoked. 0) { setUpFCall(); firstCall = true; } if (sCall > 0) { setUpSCall(); firstCall = true; } if (firstCall && secondCall) { setUpDualCall(); } }]]> This expression will always evaluate to false meaning the program could be rewritten in a simpler form. The nearby code may be present for debugging purposes, or it may not have been maintained along with the rest of the program. The expression may also be indicative of a bug earlier in the method. 1000 Category ChildOf 569 1000 Weakness ChildOf 561 All The software contains an expression that will always evaluate to true. The following method never sets the variable secondCall after initializing it to true. (The variable firstCall is mistakenly used twice.) The result is that the expression firstCall || secondCall will always evaluate to true, so setUpDualCall() will always be invoked. 0) { setUpFCall(); firstCall = true; } if (sCall > 0) { setUpSCall(); firstCall = true; } if (firstCall || secondCall) { setUpForCall(); } }]]> This expression will always evaluate to true meaning the program could be rewritten in a simpler form. The nearby code may be present for debugging purposes, or it may not have been maintained along with the rest of the program. The expression may also be indicative of a bug earlier in the method. 1000 Category ChildOf 569 1000 Weakness ChildOf 561 All The program calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee. System Process The following excerpt from a Java program mistakenly calls run() instead of start(). In most cases a direct call to a Thread object's run() method is a bug. The programmer intended to begin a new thread of control, but accidentally called run() instead of start(), so the run() method will execute in the caller's thread of control. 1000 Category ChildOf 557 1000 Weakness ChildOf 366 631 Category ChildOf 634 Java The software fails to follow the specifications for the implementation language, environment, framework, protocol, or platform. When leveraging external functionality, such as an API, it is important that the caller does so in accordance with the requirements of the external functionality or else unintended behaviors may result, possibly leaving the system vulnerable to any number of exploits. 1000 Weakness ChildOf 227 The program violates the Enterprise JavaBeans (EJB) specification by using thread synchronization primitives. The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the program violates the following EJB guideline: "An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances." A requirement that the specification justifies in the following way: "This rule is required to ensure consistent runtime semantics because while some EJB containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs." 1000 Weakness ChildOf 573 Java The program violates the Enterprise JavaBeans (EJB) specification by using AWT/Swing. The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the program violates the following EJB guideline: "An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard." A requirement that the specification justifies in the following way: "Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server system." 1000 Weakness ChildOf 573 Java The program violates the Enterprise JavaBeans (EJB) specification by using the java.io package. The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the program violates the following EJB guideline: "An enterprise bean must not use the java.io package to attempt to access files and directories in the file system." The specification justifies this requirement in the following way: "The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data." 1000 Weakness ChildOf 573 Java The program violates the Enterprise JavaBeans (EJB) specification by using sockets. The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the program violates the following EJB guideline: "An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast." A requirement that the specification justifies in the following way: "The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean-- to serve the EJB clients." 1000 Weakness ChildOf 573 Java The program violates the Enterprise JavaBeans (EJB) specification by using the class loader. The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the program violates the following EJB guideline: "The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams." A requirement that the specification justifies in the following way: "These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container's ability to properly manage the runtime environment." 1000 Weakness ChildOf 573 Java The application stores a non-serializable object as an HttpSession attribute, which can hurt reliability. In order for session replication to work, the values the application stores as attributes in the session must implement the Serializable interface. The following class adds itself to the session, but because it is not serializable, the session can no longer be replicated. A J2EE application can make use of multiple JVMs in order to improve application reliability and performance. In order to make the multiple JVMs appear as a single application to the end user, the J2EE container can replicate an HttpSession object across multiple JVMs so that if one JVM becomes unavailable another can step in and take its place without disrupting the flow of the application. 1000 Weakness ChildOf 573 Java On later Windows operating systems, a file can have a "long name" and a short name that is compatible with older Windows file systems, with up to 8 characters in the filename and 3 characters for the extension. These "8.3" filenames, therefore, have the "alternate name" property for files with long names, so are useful pathname equivalence manipulations. File processing Disable Windows from supporting 8.3 filenames by editing the Windows registry. Preventing 8.3 filenames will not remove previously generated 8.3 filenames. CVE-1999-0012 Multiple web servers allow restriction bypass using 8.3 names instead of long names CVE-2001-0795 Source code disclosure using 8.3 file name. CVE-2005-0471 Multi-Factor Vulnerability. Product generates temporary filenames using long filenames, which become predictable in 8.3 format. Probably under-studied M. Howard D. LeBlanc Writing Secure Code 2nd Edition Microsoft 2003 1000 Weakness ChildOf 41 Windows 8.3 Filename All The software contains a clone() method that fails to call super.clone() to obtain the new object. The following two classes demonstrate a bug introduced by failing to call super.clone(). Because of the way Kibitzer implements clone(), FancyKibitzer's clone method will return an object of type Kibitzer instead of FancyKibitzer. Java All implementations of clone() should obtain the new object by calling super.clone(). If a class fails to follow this convention, a subclass's clone() method will return an object of the wrong type. It is also a good idea to declare your clone method as final. You may not want users inheriting your class to tamper with the clone method. In some cases, you can eliminate the clone method altogether in some cases and use copy constructors. 1000 Weakness ChildOf 485 1000 Weakness ChildOf 398 Java The software fails to maintain equal hashcodes for equal objects. Failure to uphold this invariant is likely to cause trouble if objects of this class are stored in a collection. If the objects of the class in question are used as a key in a Hashtable or if they are inserted into a Map or Set, it is critical that equal objects have equal hashcodes. Java objects are expected to obey a number of invariants related to equality. One of these invariants is that equal objects must have equal hashcodes. In other words, if a.equals(b) == true then a.hashCode() == b.hashCode(). 1000 Weakness ChildOf 573 Java The program declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified. Because arrays are mutable objects, the final constraint requires that the array object itself be assigned only once, but makes no guarantees about the values of the array elements. Since the array is public, a malicious program can change the values stored in the array. Primary (Weakness exists independent of other weaknesses) In most situations the array should be made private. The following Java Applet code mistakenly declares an array public, final and static. Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running. In most cases an array declared public, final and static is a bug. 1000 Category ChildOf 490 Java The program violates secure coding principles for mobile code by declaring a finalize() method public. If you are using finalize() as it was designed, there is no reason to declare finalize() with anything other than protected access. The following Java Applet code mistakenly declares a public finalize() method. Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running. A program should never call finalize explicitly, except to call super.finalize() inside an implementation of finalize(). In mobile code situations, the otherwise error prone practice of manual garbage collection can become a security threat if an attacker can maliciously invoke one of your finalize() methods because it is declared with public access. 1000 Category ChildOf 490 1000 Weakness ChildOf 668 Java The code has a return statement inside a finally block, which will cause any thrown exception in the try block to be discarded. In the following code excerpt, the IllegalArgumentException will never be delivered to the caller. The finally block will cause the exception to be discarded. 1000 Category ChildOf 389 1000 Weakness ChildOf 691 The software contains an empty synchronized block. Synchronization in Java can be tricky. An empty synchronized block is often a sign that a programmer is wrestling with synchronization but has not yet achieved the result they intend. 1000 Category ChildOf 371 1000 Weakness ChildOf 398 Java The software makes an explicit call to the finalize() method from outside the finalizer. The following code fragment calls finalize() explicitly: While the Java Language Specification allows an object's finalize() method to be called from outside the finalizer, doing so is usually a bad idea. For example, calling finalize() explicitly means that finalize() will be called more than once: the first time will be the explicit call and the last time will be the call that is made after the object is garbage collected. 1000 Category ChildOf 399 1000 Weakness ChildOf 227 Java The software sets a pointer to a specific address other than NULL or 0. If the pointer is set to a specific address, that address will probably not be valid in all environments or platforms. Primary (Weakness exists independent of other weaknesses) Implementation: Never set a pointer to a fixed address. C Consequence: Integrity: If one executes code at a known location, one might be able to inject code there beforehand. Consequence: Confidentiality: The data at a known pointer location can be easily read. Most often, this issue will only result in a crash, but in circumstances where a user can influence the data at which the pointer points to, it may result in code execution. At best, using fixed addresses is not portable. 1000 Category ChildOf 465 1000 Weakness ChildOf 344 C C++ C# Assembly Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Implementation: Review of type casting operations can identify locations where incompatible types are cast. C i = 2; return foo->i; }]]> Consequence: Data Corruption: Adjacent variables in memory may be corrupted by assignments performed on fields after the cast. Consequence: Availability: Execution may end due to a memory access error. 1000 Category ChildOf 465 An API function that does not exist on all versions of the target platform was identified. Some functions that offer security features supported by the OS are not available on all versions of the OS in common use. Likewise, functions are often deprecated or made obsolete for security reasons and should not be used. Implementation: Always test your code on any platform on which it is targeted to run on. Pre-design through build: Test your code on the newest and oldest platform on which it is targeted to run on. Consequence: Pre-design through build: It is important to develop a system to test for this set of functions. 1000 Weakness ChildOf 474 96 Link following weaknesses involve insufficient protection against links or shortcuts that can resolve to a file other than the one that was intended. Some people use the phrase "insecure temporary file" when referring to a link following weakness, but other weaknesses can produce insecure temporary files without any symlink involvement at all. File processing, temporary files Low to Medium Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) File/Directory Follow the principle of least privilege when assigning access rights to files. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted. Link following vulnerabilities are Multi-factor Vulnerabilities (MFV). They are the combination of multiple elements: file or directory permissions, filename predictability, race conditions, and in some cases, a design limitation in which there is no mechanism for performing atomic file creation operations. Some potentials factors are race conditions, permissions, predictability. This is not OS specific. Windows soft links can be exploited remotely since a ".LNK" file can be uploaded like a normal file. UNIX hard links, and Windows hard/soft links are under-studied and under-reported. 1000 Weakness ChildOf 21 631 Category ChildOf 632 635 View ChildOf 635 Link Following All 35 17 76 If free is incorrectly used by a user, it may be possible to gain control or process execution through the use of a "write, what, where" primitive. Memory Implementation: Only free pointers that you have called malloc on previously. This is the recommended solution. Keep track of which pointers point at the beginning of valid chunks and free them only once. Design: The use of a language which provides abstractions for memory allocation and deallocation could be used. C = &argv[10]) break; /.../ free(ap[4]);]]> Consequence: Authorization: There is the potential for arbitrary code execution with privileges of the vulnerable program via a "write, what where" primitive. If pointers to memory which hold user information are freed, a malicious user will be able to write 4 bytes anywhere in memory. 1000 Category ChildOf 399 631 Category ChildOf 633 The application stores sensitive data in memory that is not locked, or that has been improperly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. Memory Confidentiality: Sensitive data that is written to a swap file may be exposed. Design: Identify data that needs to be protected from swapping and choose platform-appropriate protection mechanisms. Implementation: Check return values to ensure locking operations are successful. On Windows systems the VirtualLock function can lock a page of memory to ensure that it will remain present in memory and not be swapped to disk. However, on older versions of Windows, such as 95, 98, or Me, the VirtualLock() function is only a stub and provides no protection. On POSIX systems the mlock() call ensures that a page will stay resident in memory but does not guarantee that the page will not appear in the swap. Therefore, it is unsuitable for use as a protection mechanism for sensitive data. Some platforms, in particular Linux, do make the guarantee that the page will not be swapped, but this is non-standard and is not portable. Calls to mlock() also require supervisor privilege. Return values for both of these calls must be checked to ensure that the lock operation was actually successful. 1000 Weakness ChildOf 413 631 Category ChildOf 633 The software does not properly perform authentication, allowing it to be bypassed through various methods. 1000 Weakness ChildOf 287 The software modifies the SSL context after connection creation has begun. Authentication: no authentication takes place in this process, bypassing an assumed protection of encryption Confidentiality: the encrypted communication between a user and a trusted host may be subject to a "man in the middle" sniffing attack Design: Use a language which provides a cryptography framework at a higher level of abstraction. Implementation: Most SSL_CTX functions have SSL counterparts that act on SSL-type objects. C Applications should set up an SSL_CTX completely, before creating SSL objects from it.If one did modify the SSL_CTX object after creating objects from it, there is the possibility that older SSL objects created from that context could all be affected by that change. 1000 Weakness ChildOf 666 1000 Weakness ChildOf 592 94 When the J2EE container attempts to write unserializable objects to disk there is no guarantee that the process will complete successfully. Data Corruption: Data represented by unserializable objects can be corrupted. Availability: Non-serializability of objects can lead to system crash. Design through Implementation: All objects that become part of session and application scope must implement the java.io.Serializable interface to ensure serializability of containing objects. In heavy load conditions, most J2EE application frameworks flush objects to disk to manage memory requirements of incoming requests. For example, session scoped objects, and even application scoped objects, are written to disk when required. While these application frameworks do the real work of writing objects to disk, they do not enforce that those objects be serializable, thus leaving your web application vulnerable to serialization failure induced crashes. An attacker may be able to mount a denial of service attack by sending enough requests to the server to force the web application to save objects to disk. 1000 Weakness ChildOf 485 Java Object references are compared rather than objects themselves Use the equals() method to compare objects instead of the == operator. If using ==, it is important for performance reasons that your objects are created by a static factory, not by a constructor. This problem can cause unexpected application behavior. Comparing objects using == usually produces deceptive results, since the == operator compares object references rather than values. To use == on a string, the programmer has to make sure that these objects are unique in the program, that is, that they don't have the equals method defined or have a static factory that produces unique objects. 1000 Category ChildOf 569 1000 Weakness ChildOf 398 Failure to sufficiently distinguish or equate two objects based on their conceptual content. For example, let's say you have two truck objects that you want to compare for equality. Truck objects are defined to be the same if they have the same make, the same model, and were manufactured in the same year. A Semantic Incorrect Object Comparison would occur if only two of the three factors were checked for equality. So if only make and model are compared and the year is ignored, then you have an incorrect object comparison. 1000 Category ChildOf 569 1000 Weakness ChildOf 398 The product uses the wrong operator when comparing a string, such as using "==" when the equals() method should be used instead. The following branch will never be taken. Using == or != to compare two strings for equality actually compares two objects for equality, not their values. Chances are good that the two references will never be equal. 1000 Weakness ChildOf 595 1000 Category ChildOf 133 The web application uses the GET method to process requests that contain sensitive information, which can expose that information through the browser's history, Referers, web logs, and other sources. Recommendations include performing server-side input validation to ensure data received from the client matches expectations. At a minimum, attackers can garner information from query strings that can be utilized in escalating their method of attack, such as information about the internal workings of the application or database column names. Successful exploitation of query string parameter vulnerabilities could lead to an attacker impersonating a legitimate user, obtaining proprietary data, or simply executing actions not intended by the application developers. 1000 Weakness ChildOf 200 The failure to validate certificate data may mean that an attacker may be claiming to be a host which it is not. Integrity: the data read may not be properly secured, it might be viewed by an attacker. Authentication: trust afforded to the system in question may allow for spoofing or redirection attacks. Design: ensure that proper authentication is included in the system design. Implementation: understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications. C If the certificate is not checked, it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data under the guise of a trusted host. While the attacker in question may have a valid certificate, it may simply be a valid certificate for a different site. In order to ensure data integrity, we must check that the certificate is valid, and that it pertains to the site we wish to access. 1000 Weakness ChildOf 297 Session ID's can be used to identify communicating parties in a web environment. If an attacker can guess or steal a session ID, then he/she may be able to take over the user's session (called session hijacking). Session identifiers should be at least 128 bits long to prevent brute-force session guessing. A shorter session identifier leaves the application open to brute-force session guessing attacks. If an attacker can guess an authenticated user's session identifier, he can take over the user's session. The remainder of this explanation will detail a back-of-the-envelope justification for a 128 bit session identifier. The expected number of seconds required to guess a valid session identifier is given by the equation: <b>(2^B+1)/(2*A*S)</b> Where: - B is the number of bits of entropy in the session identifier. - A is the number of guesses an attacker can try each second. - S is the number of valid session identifiers that are valid and available to be guessed at any given time. The number of bits of entropy in the session identifier is always less than the total number of bits in the session identifier. For example, if session identifiers were provided in ascending order, there would be close to zero bits of entropy in the session identifier no matter the identifier's length. Assuming that the session identifiers are being generated using a good source of random numbers, we will estimate the number of bits of entropy in a session identifier to be half the total number of bits in the session identifier. For realistic identifier lengths this is possible, though perhaps optimistic. If attackers use a botnet with hundreds or thousands of drone computers, it is reasonable to assume that they could attempt tens of thousands of guesses per second. If the web site in question is large and popular, a high volume of guessing might go unnoticed for some time. A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short inactive session timeout.) With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes. Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years. 1000 Category ChildOf 4 1000 Weakness ChildOf 334 J2EE Misconfiguration: Insufficient Session-ID Length Java 21 59 A Servlet fails to catch all exceptions, which may reveal sensitive debugging information. In the following method a DNS lookup failure will cause the Servlet to throw an exception. When a Servlet throws an exception, the default error response the Servlet container sends back to the user typically includes debugging information. This information is of great value to an attacker. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components. 1000 Category ChildOf 388 1000 Weakness ChildOf 691 1000 Weakness CanPrecede 209 1000 Weakness PeerOf 390 A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks. An http parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. Open Redirect CVE-2005-4206 - Blackboard Learning and Community Portal System in Academic Suite 6.3.1.424, 6.2.3.23, and other versions before 6 allows remote attackers to redirect users to other URLs and conduct phishing attacks via a modified url parameter to frameset.jsp, which loads the URL into a frame and causes it to appear to be part of a valid page. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4206 Phishing is a general term for deceptive attempts to coerce private information from users that will be used for identity theft. 1000 Weakness ChildOf 610 The client can be modified by an attacker in a way that bypasses protection mechanisms that are not common to both the client and server. Primary (Weakness exists independent of other weaknesses) Consider a product that consists of two or more processes or nodes that must interact closely, such as a client/server model. If the product uses protection schemes in the client in order to defend from attacks against the server, and the server does not use the same schemes, then an attacker could modify the client in a way that bypasses those schemes. This is a fundamental design flaw that is primary to many weaknesses. Protection schemes must be implemented on the server side; no interactions or inputs from the client can be assumed to be safe. Some protection schemes can still be duplicated in the client such as input validation, because they are frequently useful for general error-checking. If some degree of trust is required between the two entities, then use integrity checking and strong authentication to ensure that the inputs are coming from a trusted source. Design the product so that this trust is managed in a centralized fashion, especially if there are complex or numerous communication channels, in order to reduce the risks that the implementor will mistakenly omit a check in a single code path. SERVER-SIDE (server.pl): The server accepts 2 commands, "AUTH" which authenticates the user, and "CHANGE-ADDRESS" which updates the address field for the username. The client performs the authentication and only sends a CHANGE-ADDRESS for that user if the authentication succeeds. Because the client has already performed the authentication, the server assumes that the username in the CHANGE-ADDRESS is the same as the authenticated user. An attacker could modify the client by commenting out the code that sends the "AUTH" command and simply executing the CHANGE-ADDRESS. CVE-2006-6994 ASP program allows upload of .asp files by bypassing client-side checks. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6994 CVE-2007-0163, CVE-2007-0164 steganography products embed password information in the carrier file, which can be extracted from a modified client. CVE-2007-0100 client allows server to modify client's configuration and overwrite arbitrary files. "server-side enforcement of client-side security" is conceptually likely to occur, but some architectures might have these strong dependencies as part of legitimate behavior, such as thin clients. This is a design error, not implementation. 1000 Category ChildOf 254 1000 Weakness ChildOf 669 1000 Weakness CanPrecede 471 1000 Weakness PeerOf 290 1000 Weakness PeerOf 300 All A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check. Client-side authentication is extremely weak and may be breached easily. Any attacker may read the source code and reverse-engineer the authentication mechanism to access parts of the application which would otherwise be protected. CVE-2006-0230 Symantec Scan Engine 5.0.0.24, and possibly other versions before 5.1.0.7, uses a client-side check to verify a password, which allows remote attackers to gain administrator privileges via a modified client that sends certain XML requests. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0230 1000 Weakness ChildOf 602 1000 Weakness PeerOf 592 1000 Weakness ChildOf 287 1000 Weakness PeerOf 300 When multiple sockets are allowed to bind to the same port, other services on that port may be stolen or spoofed. Packets from a variety of network services may be stolen or the services spoofed. Restrict server socket address to known local addresses. #include #include #include #include #include void bind_socket(void) { int server_sockfd; int server_len; struct sockaddr_in server_address; unlink("server_socket"); server_sockfd = socket(AF_INET, SOCK_STREAM, 0); server_address.sin_family = AF_INET; server_address.sin_port = 21; server_address.sin_addr.s_addr = htonl(INADDR_ANY); server_len = sizeof(struct sockaddr_in); bind(server_sockfd, (struct sockaddr *) &s1, server_len);]]> On most systems, a combination of setting the SO_REUSEADDR socket option, and a call to bind() allows any process to bind to a port to which a previous process has bound width INADDR_ANY. This allows a user to bind to the specific address of a server bound to INADDR_ANY on an unprivileged port, and steal its udp packets/tcp connection. 1000 Weakness ChildOf 675 1000 Weakness ChildOf 666 All The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service because of excessive looping. 1000 Weakness ChildOf 20 1000 Weakness ChildOf 398 A public or protected static final field references a mutable object, which allows the object to be changed by malicious code, or accidentally from another package 1000 Weakness ChildOf 471 Java An ActionForm class contains a field that has not been declared private, which can be accessed without using a setter or getter. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Make all fields private. Use getter to get the value of the field. Setter should be used only by the framework; setting an action form field from other actions is bad practice and should be avoided. 1000 Weakness ChildOf 101 Java The program uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient. Double-checked locking refers to the situation where a programmer checks to see if a resource has been initialized, grabs a lock, checks again to see if the resource has been initialized, and then performs the initialization if it has not occurred yet. This should not be done, as is not guaranteed to work in all languages and on all architectures. In summary, other threads may not be operating inside the synchronous block and are not guaranteed to see the operations execute in the same order as they would appear inside the synchronous block. While double-checked locking can be achieved in some languages, it is inherently flawed in Java before 1.5, and cannot be achieved without compromising platform independence. Before Java 1.5, only use of the synchronized keyword is known to work. Beginning in Java 1.5, use of the "volatile" keyword allows double-checked locking to work successfully, although there is some debate as to whether it achieves sufficient performance gains. See references. It may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization... Java The programmer wants to guarantee that only one <code>Helper()</code> object is ever allocated, but does not want to pay the cost of synchronization every time this code is called. Let's say helper is not initialized. Then, thread A comes along, sees that helper==null, and enters the synchronized block and begins to execute: If a second thread, thread B, takes over in the middle of this call and helper has not finished running the constructor, then thread B may make calls on helper while its fields hold incorrect values. David Bacon et al. The "Double-Checked Locking is Broken" Declaration http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html Jeremy Manson and Brian Goetz JSR 133 (Java Memory Model) FAQ http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl 1000 Weakness ChildOf 662 1000 Weakness ChildOf 362 Java Implementation The product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere. This is a general class of weakness, but most research is focused on more specialized cases, such as path traversal (CWE-22) and symlink following (CWE-61). A symbolic link has a name; in general, it appears like any other file in the file system. However, the link includes a reference to another file, often in another directory - perhaps in another sphere of control. Many common library functions that accept filenames will "follow" a symbolic link and use the link's target instead. Cross-zone scripting is an attack on web browsers for which this issue is resultant. CVE-2007-0800 is one example. 1000 Category ChildOf 265 Architecture and Design The product processes an XML document that can contain XML entities with URLs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output. XML documents optionally contain a Document Type Definition (DTD), which, among other features, enables the definition of "XML entities". It is possible to define an entity locally by providing a substitution string in the form of a URL whose content is substituted for the XML entity when the DTD is processed. The attack can be launched by defining an XML entity whose content is a file URL (which, when processed by the receiving end, is mapped into a file on the server), that is embedded in the XML document, and thus, is fed to the processing application. This application may echo back the data (e.g. in an error message), thereby exposing the file contents. Accessibility CVE-2005-1306 -A browser control can allow remote attackers to determine the existence of files via Javascript containing XML script, aka the "XML External Entity vulnerability." It's important to note that a URL can have non-HTTP schemes, especially, that a URL such as "file:///c:/winnt/win.ini" designates (in Windows) the file C:\Winnt\win.ini. Similarly, a URL can be used to designate any file on any drive. 1000 Weakness ChildOf 538 1000 Weakness ChildOf 673 1000 Weakness ChildOf 610 The product performs an indexing routine against private documents, but does not sufficiently verify that the actors who can access the index also have the privileges to access the private documents. When an indexing routine is applied against a group of private documents, and that index's results are available to outsiders who do not have access to those documents, then outsiders might be able to obtain sensitive information by conducting targeted searches. The risk is especially dangerous if search results include surrounding text that was not part of the search query. This issue can appear in search engines that are not configured (or implemented) to ignore critical files that should remain hidden; even without permissions to download these files directly, the remote user could read them. Under-studied and under-reported 1000 Weakness ChildOf 200 1000 Weakness ChildOf 668 All According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization." The lack of proper session expiration may improve the likely success of certain attacks. For example, an attacker may intercept a session ID, possibly via a network sniffer or Cross-site Scripting attack. Although short session expiration times do not help if a stolen token is immediately used, they will protect against ongoing replaying of the session ID. In another scenario, a user might access a web site from a shared computer (such as at a library, Internet cafe, or open work environment). Insufficient Session Expiration could allow an attacker to use the browser's back button to access web pages previously accessed by the victim. 1000 Weakness ChildOf 672 1000 Weakness ChildOf 287 The Secure attribute for sensitive cookies in HTTPS sessions is not set, which could cause the user agent to send those cookies in plaintext over an HTTP session. CVE-2004-0462 A product does not set the Secure attribute for sensitive cookies in HTTPS sessions, which could cause the user agent to send those cookies in plaintext over an HTTP session with the product. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0462 1000 Weakness ChildOf 311 While adding general comments is very useful, some programmers tend to leave important data, such as: filenames related to the web application, old links or links which were not meant to be browsed by users, old code fragments, etc. An attacker who finds these comments can map the application's structure and files, expose hidden parts of the site, and study the fragments of code to reverse engineer the application, which may help develop further attacks against the site. 1000 Weakness ChildOf 540 The PHP application uses an old method for processing uploaded files by referencing the four global variables that are set for each file (e.g. $varname, $varname_size, $varname_name, $varname_type). These variables could be overwritten by POST requests, cookies, or other methods of populating or overwriting these global variables. This could be used to read or process arbitrary files by providing values such as "/etc/passwd". Primary (Weakness exists independent of other weaknesses) For later PHP versions, reference uploaded files using the $HTTP_POST_FILES or $_FILES variables, and use is_uploaded_file() or move_uploaded_file() to ensure that you are dealing with an uploaded file. As of 2006, the "four globals" method is probably in sharp decline, but older PHP applications could have this issue. In the "four globals" method, PHP sets the following 4 global variables (where "varname" is application-dependent): PHP "The global $_FILES exists as of PHP 4.1.0 (Use $HTTP_POST_FILES instead if using an earlier version). These arrays will contain all the uploaded file information." PHP ** note: 'userfile' is the field name from the web form; this can vary. CVE-2002-1460 - program does not distinguish between normal $_POST variables and the ones that are used for recognizing that a file has been downloaded. CVE-2002-1710, CVE-2002-1759 - product doesn't check if the variables for an upload were set by uploading the file, or other methods such as $_POST. CVE-2002-1460 - PHP web forum does not properly verify whether a file was uploaded, allowing attackers to reference other files by modifying POST variables. CVE-2002-1710 - product does not distinguish uploaded file from other files. CVE-2002-1759 - PHP script does not restrict access to uploaded files. Overlaps container error. For older PHP versions, you had to write your own version of is_uploaded_file() and run it against $HTTP_POST_FILES['userfile'])) Shaun Clowes A Study in Scarlet - section 5, "File Upload" 1000 Category ChildOf 429 1000 Weakness PeerOf 473 Incomplete Identification of Uploaded File Variables (PHP) PHP The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary. For example, if a server handles multiple simultaneous connections, and an assert() occurs in one single connection that causes all other connections to be dropped, this is a reachable assertion that leads to a denial of service. Resultant (Weakness is typically related to the presence of some other weaknesses) CVE-2006-6767 CVE-2006-6811 CVE-2006-5779 CVE-2006-4574 CVE-2006-4095 CVE-2006-4574 Chain: security monitoring product has an off-by-one error that leads to unexpected length values, triggering an assertion. While assertion is good for catching logic errors and reducing the chances of reaching more serious vulnerability conditions, it can still lead to a denial of service if the relevant code can be triggered by an attacker, and if the scope of the assert() extends beyond the attacker's own session. 1000 Weakness ChildOf 670 An ActiveX control is intended for use in a web browser, but it exposes dangerous methods that perform actions that are outside of the browser's security model (e.g. the zone or domain). If there is no integrity checking or origin validation, this method could be invoked by attackers. Primary (Weakness exists independent of other weaknesses) If you must expose a method, make sure to perform input validation on all arguments, and protect against all possible vulnerabilities. Use code signing, although this does not protect against any weaknesses that are already in the control. Where possible, avoid marking the control as safe for scripting. CVE-2007-1120 - download a file to arbitrary folders. CVE-2006-6838 - control downloads and executes a url in a parameter CVE-2007-0321 - resultant buffer overflow ActiveX controls can exercise far greater control over the operating system than typical Java or javascript. Exposed methods can be subject to various vulnerabilities, depending on the implemented behaviors of those methods, and whether input validation is performed on the provided arguments. Alternate keywords: OLE Object, Component Object Model (COM) http://msdn.microsoft.com/workshop/components/activex/safety.asp http://msdn.microsoft.com/workshop/components/activex/security.asp 1000 Weakness ChildOf 267 1000 Weakness ChildOf 691 1000 Weakness PeerOf 100 A cursor is a feature in Oracle PL/SQL and other languages that provides a handle for executing and accessing the results of SQL queries. If a cursor is not closed properly, then it could become accessible to other users while retaining the same privileges that were originally assigned, leaving the cursor "dangling." For example, an improper dangling cursor could arise from unhandled exceptions. The impact of the issue depends on the cursor's role, but SQL injection attacks are commonly possible. Close cursors immediately after access to them is complete. Ensure that you close cursors if exceptions occur. The weakness can occur both as Primary and Resultant. This issue is currently reported for unhandled exceptions, but it is theoretically possible any time the programmer does not close the cursor at the proper time. David Litchfield The Oracle Hacker's Handbook David Litchfield Cursor Injection http://www.databasesecurity.com/dbsec/cursor-injection.pdf 1000 Weakness ChildOf 402 1000 Category PeerOf 265 1000 Category PeerOf 388 SQL Failure for a system to check for hardlinks can result in vulnerability to different types of attacks. For example, an attacker can escalate their privileges if an he/she can replace a file used by a privileged program with a hardlink to a sensitive file (e.g. etc/passwd). When the process opens the file, the attacker can assume the privileges of that process. Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Follow the principle of least privilege when assigning access rights to files. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted. CVE-2001-1494 Hard link attack, file overwrite; interesting because program checks against soft links CVE-2002-0793 CVE-2003-0578 CVE-1999-0783 CVE-2004-1603 CVE-2004-1901 CVE-2005-1111 Hard link race condition BUGTRAQ:20030203 ASA-0001 OpenBSD chpass/chfn/chsh file content leak http://www.securityfocus.com/archive/1/309962 Under-studied. It is likely that programs that check for symbolic links could be vulnerable to hard links. 1000 Category ChildOf 60 UNIX hard link All When setting a new password for a user, the product does not require knowledge of the original password, or using another form of authentication. This could be used by an attacker to change passwords for another user, thus gaining the privileges associated with that user. When prompting for a password change, force the user to provide the original password in addition to the new password. Do not use "forgotten password" functionality. But if you must, ensure that you are only providing information to the actual user, e.g. by using an email address or challenge question that the legitimate user already provided in the past; do not allow the current user to change this identity information until the correct password has been provided. CVE-2007-0681 This weakness can be both Primary or Resultant 1000 Category ChildOf 255 1000 Weakness ChildOf 522 All The product processes user-provided information and extracts this information into arbitrary variables, without verifying that the names of the specified variables are valid. For example, in PHP, calling extract() or import_request_variables() without the proper arguments could allow arbitrary global variables to be overwritten, including superglobals. Similar functionality might be possible in other interpreted languages, including custom languages. Variable overwrite Primary (Weakness exists independent of other weaknesses) Use whitelists of variable names that can be extracted. Consider refactoring your code to avoid extraction routines altogether. In PHP, call extract() with options such as EXTR_SKIP and EXTR_PREFIX_ALL; call import_request_variables() with a prefix argument. Note that these capabilities are not present in all PHP versions. CVE-2006-7135 - extract issue enables file inclusion CVE-2006-7079 - extract used for register_globals compatibility layer, enables path traversal CVE-2007-0649 - extract() buried in include files makes post-disclosure analysis confusing; original report had seemed incorrect. CVE-2006-6661 - extract() enables static code injection CVE-2006-2828 - import_request_variables() buried in include files makes post-disclosure analysis confusing In general, variable extraction can make control and data flow analysis difficult to perform. For PHP, extraction can be used to provide functionality similar to register_globals, which is frequently disabled in production systems. Many PHP versions will overwrite superglobals in extract/import_request_variables calls. Probably under-reported for PHP. Under-studied for other interpreted languages. 1000 Weakness ChildOf 94 1000 Weakness PeerOf 99 1000 Weakness PeerOf 471 1000 Weakness PeerOf 627 PHP A product adds hooks to user-accessible API functions, but does not properly validate the arguments. This could lead to resultant vulnerabilities. Such hooks can be used in defensive software that runs with privileges, such as anti-virus or firewall, which hooks kernel calls. When the arguments are not validated, they could be used to bypass the protection scheme or attack the product itself. Ensure that all arguments are verified, as defined by the API you are protecting. Drop privileges before invoking such functions, if possible. CVE-2007-0708 - DoS in firewall using standard Microsoft functions CVE-2006-7160 - DoS in firewall using standard Microsoft functions CVE-2007-1376 - function does not verify that its argument is the proper type, leading to arbitrary memory write CVE-2007-1220 - invalid syscall arguments bypass code execution limits CVE-2006-4541 - DoS in IDS via NULL argument This weakness is usually primary. 1000 Weakness ChildOf 88 All An ActiveX control is intended for restricted use, but it has been marked as safe-for-scripting. This might allow attackers to use dangerous functionality via a web page that accesses the control, which can lead to different resultant vulnerabilities, depending on the control's behavior. Primary (Weakness exists independent of other weaknesses) During development, do not mark it as safe for scripting. After distribution, you can set the kill bit for the control so that it is not accessible from Internet Explorer. CVE-2007-0617 - add emails to spam whitelist CVE-2007-0219 - web browser uses certain COM objects as ActiveX CVE-2006-6510 - kiosk allows bypass to read files It is suspected that this is under-reported. http://msdn.microsoft.com/workshop/components/activex/safety.asp http://msdn.microsoft.com/workshop/components/activex/security.asp http://support.microsoft.com/kb/240797 1000 Weakness ChildOf 267 1000 Weakness ChildOf 691 1000 Weakness ChildOf 398 1000 Weakness PeerOf 618 The product uses a regular expression that either (1) contains an executable component with user-controlled inputs, or (2) allows a user to enable execution by inserting pattern modifiers. Case (2) is possible in the PHP preg_replace() function, and possibly in other languages when a user-controlled input is inserted into a string that is later parsed as a regular expression. The regular expression feature in some languages allows inputs to be quoted or escaped before insertion, such as \Q and \E in Perl. CVE-2006-2059 - executable regexp in PHP by inserting "e" modifier into first argument to preg_replace CVE-2005-3420 - executable regexp in PHP by inserting "e" modifier into first argument to preg_replace CVE-2006-2878, CVE-2006-2908 - complex curly syntax inserted into the replacement argument to PHP preg_replace(), which uses the "/e" modifier Under-studied. The existing PHP reports are limited to highly skilled researchers, but there are few examples for other languages. It is suspected that this is under-reported for all languages. Usability factors might make it more prevalent in PHP, but this theory has not been investigated. 1000 Weakness ChildOf 77 PHP Perl The product uses a regular expression that does not sufficiently restrict the set of allowed values. This effectively causes the regexp to accept substrings that match the pattern, which produces a partial comparison to the target. In some cases, this can lead to other weaknesses. Common errors include: (1) not identifying the beginning and end of the target string; (2) using wildcards instead of acceptable character ranges; and others. Primary (Weakness exists independent of other weaknesses) When applicable, ensure that your regular expression marks beginning and ending string patterns, such as "/^string$/" for Perl. An attacker could provide an argument such as: "; ls -l ; echo 123-456" This would pass the check, since "123-456" is sufficient to match the "\d+-\d+" portion of the regular expression. CVE-2006-1895 - ".*" regexp leads to static code injection CVE-2002-2175 - insertion of username into regexp results in partial comparison, causing wrong database entry to be updated when one username is a substring of another. CVE-2006-4527 - regexp intended to verify that all characters are legal, only checks that at least one is legal, enabling file inclusion. CVE-2005-1949 - Regexp for IP address isn't anchored at the end, allowing appending of shell metacharacters. CVE-2002-2109 - Regexp isn't "anchored" to the beginning or end, which allows spoofed values that have trusted values as substrings. CVE-2006-6511 - regexp in .htaccess file allows access of files whose names contain certain substrings CVE-2006-6629 - allow load of macro files whose names contain certain substrings. VIM Mailing list, March 14, 2006 This problem is frequently found when the regular expression is used in input validation or security features such as authentication. 1000 Weakness ChildOf 185 1000 Weakness PeerOf 187 1000 Weakness PeerOf 184 1000 Weakness PeerOf 183 Perl PHP The product does not properly handle null bytes or NUL characters when passing data between different representations or components. A null byte (NUL character) can have different meanings across representations or languages. For example, it is a string terminator in standard C libraries, but Perl and PHP strings do not treat it as a terminator. When two representations are crossed - such as when Perl or PHP invokes underlying C functionality - this can produce an interaction error with unexpected results. Similar issues have been reported for ASP. Other interpreters written in C might also be affected. Primary (Weakness exists independent of other weaknesses) Remove null bytes from all incoming strings CVE-2005-4155 - NUL byte bypasses PHP regular expression check CVE-2005-3153 - inserting SQL after a NUL byte bypasses whitelist regexp, enabling SQL injection The poison null byte is frequently useful in path traversal attacks by terminating hard-coded extensions that are added to a filename. It can play a role in regular expression processing in PHP. There are not many CVE examples, because the poison NULL byte is (1) a design limitation, which typically is not included in CVE by itself; and (2) it is typically used as a facilitator manipulation to widen the scope of potential attacks against other vulnerabilities. Current (2007) usage of "poison null byte" is typically related to this C/Perl/PHP interaction error, but the original term in 1998 was applied to an off-by-one buffer overflow involving a null byte. Rain Forest Puppy Poison NULL byte Phrack 55 http://insecure.org/news/P55-07.txt Brett Moore 0x00 vs ASP file upload scripts http://www.security-assessment.com/Whitepapers/0x00_vs_ASP_File_Uploads.pdf ShAnKaR ShAnKaR: multiple PHP application poison NULL byte vulnerability http://seclists.org/fulldisclosure/2006/Sep/0185.html 1000 Weakness ChildOf 20 1000 Weakness ChildOf 436 PHP Perl ASP.NET Many interpreted languages support the use of a "$$varname" construct to set a variable whose name is specified by the $varname variable. In PHP, these are referred to as "variable variables." Functions might also be invoked using similar syntax, such as $$funcname(arg1, arg2). If the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions. The resultant vulnerabilities depend on the behavior of the application, both at the control transfer point and in any control/data flow that is reachable by the related variables or functions. Dynamic evaluation Avoid dynamic evaluation whenever possible. Use only whitelists of acceptable variable or function names. For function names, ensure that you are only calling functions that accept the proper number of arguments, to avoid unexpected null arguments. Under-studied, probably under-reported. Few researchers look for this issue; most public reports are for PHP, although other languages are affected. This issue is likely to grow in PHP as developers begin to implement functionality in place of register_globals. Steve Christey Dynamic Evaluation Vulnerabilities in PHP applications Full-Disclosure 2006-05-03 http://seclists.org/fulldisclosure/2006/May/0035.html Shaun Clowes A Study In Scarlet: Exploiting Common Vulnerabilities in PHP Applications http://www.securereality.com.au/studyinscarlet.txt 1000 Weakness ChildOf 94 1000 Weakness PeerOf 621 1000 Weakness PeerOf 183 PHP Perl The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses. There are multiple ways in which this weakness can be introduced, including: (1) the wrong variable or reference; (2) an incorrect number of arguments; (3) incorrect order of arguments; (4) wrong type of arguments; or (5) wrong value. Primary (Weakness exists independent of other weaknesses) Once found, these issues are easy to fix. Use code inspection tools and relevant compiler features to identify potential violations. Pay special attention to code that is not likely to be exercised heavily during QA. Make sure your API's are stable before you use them in production code. CVE-2006-7049 The method calls the functions with the wrong argument order, which allows remote attackers to bypass intended access restrictions. This is usually primary to other weaknesses, but it can be resultant if the function's API or function prototype changes. Since these bugs typically introduce obviously incorrect behavior, they are found quickly, unless they occur in rarely-tested code paths. Managing the correct number of arguments can be made more difficult in cases where format strings are used, or when variable numbers of arguments are supported. 1000 Category ChildOf 559 All Implementation 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. 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." Failing Open Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) Integrity: intended access restrictions can be bypassed, which is often contradictory to what the product's administrator expects. Subdivide and allocate resources and components so that a failure in one part does not affect the entire product. 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. CVE-2007-5277 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." CVE-2006-4407 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. 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). Jerome H. Saltzer 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 Michael Gegick Failing Securely 2005-12-05 https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/349.html 1000 Weakness ChildOf 657 1000 Category ChildOf 388 1000 Weakness PeerOf 280 All The product uses a more complex mechanism than necessary, which could lead to resultant weaknesses when the mechanism is not correctly understood, modeled, configured, implemented, or used. Security mechanisms should be as simple as possible. Complex security mechanisms may engender partial implementations and compatibility problems, with resulting mismatches in assumptions and implemented security. A corollary of this principle is that data specifications should be as simple as possible, because complex data specifications result in complex validation code. Complex tasks and systems may also need to be guarded by complex security checks, so simple systems should be preferred. Unnecessary Complexity Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) Avoid complex security mechanisms when simpler ones would meet requirements. Avoid complex data models, and unnecessarily complex operations. Adopt architectures that provide guarantees, simplify understanding through elegance and abstraction, and that can be implemented similarly. Modularize, isolate and do not trust complex code, and apply other secure programming principles on these modules (e.g., least privilege) to mitigate vulnerabilities. The IPSEC specification is complex, which resulted in bugs, partial implementations, and incompatibilities between vendors. HTTP Request Smuggling (CWE-444) attacks are feasible because there are not stringent requirements for how illegal or inconsistent HTTP headers should be handled. This can lead to inconsistent implementations in which a proxy or firewall interprets the same data stream as a different set of requests than the end points in that stream. CVE-2007-6067 Support for complex regular expressions leads to a resultant algorithmic complexity weakness (CWE-407). CVE-2007-1552 Either a filename extension and a Content-Type header could be used to infer the file type, but the developer only checks the Content-Type, enabling unrestricted file upload (CWE-434). CVE-2007-6479 In Apache environments, a "filename.php.gif" can be redirected to the PHP interpreter instead of being sent as an image/gif directly to the user. Not knowing this, the developer only checks the last extension of a submitted filename, enabling arbitrary code execution. CVE-2005-2148 The developer cleanses the $_REQUEST superglobal array, but PHP also populates $_GET, allowing attackers to bypass the protection mechanism and conduct SQL injection attacks against code that uses $_GET. 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). Jerome H. Saltzer 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 Michael Gegick Economy of Mechanism 2005-09-13 https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/348.html 1000 Weakness ChildOf 657 All The product does not perform access checks on a resource every time the resource is accessed by an entity, which can create resultant weaknesses if that entity's rights or privileges change over time. Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) Integrity and Confidentiality: a user might retain access to a critical resource even after privileges have been revoked, possibly allowing access to privileged functionality or sensitive information, depending on the role of the resource. Invalidate cached privileges, file handles or descriptors, or other access credentials whenever identities, processes, policies, roles, capabilities or permissions change. Perform complete authentication checks before accepting, caching and reusing data, dynamic content and code (scripts). Avoid caching access control decisions as much as possible. Identify all possible code paths that might access sensitive resources. If possible, create and use a single interface that performs the access checks, and develop code standards that require use of this interface. When executable library files are used on web servers, which is common in PHP applications, the developer might perform an access check in any user-facing executable, and omit the access check from the library file itself. By directly requesting the library file (CWE-425), an attacker can bypass this access check. When a developer begins to implement input validation for a web application, often the validation is performed in each area of the code that uses externally-controlled input. In complex applications with many inputs, the developer often misses a parameter here or a cookie there. One frequently-applied solution is to centralize all input validation, store these validated inputs in a separate data structure, and require that all access of those inputs must be through that data structure. An alternate approach would be to use an external input validation framework such as Struts, which performs the validation before the inputs are ever processed by the code. CVE-2007-0408 Server does not properly validate client certificates when reusing cached connections. CVE-2007-0408 Product supports a configuration that allows passwords to be cached, allowing attackers to login without a password. Jerome H. Saltzer 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 Michael Gegick Complete Mediation 2005-09-12 https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/346.html 1000 Weakness ChildOf 657 1000 Weakness ChildOf 285 All The system's access control functionality does not prevent one user from gaining access to another user's records by modifying the key value identifying the record. Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user related record stored in the system and would be used to lookup that record for presentation to the user. It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system. One manifestation of this weakness would be if a system used sequential or otherwise easily guessable session ids that would allow one user to easily switch to another user's session and view/modify their data. High Access control checks for specific user data or functionality can be bypassed. Horizontal escalation of privilege is possible (one user can view/modify information of another user) Vertical escalation of privilege is possible if the user controlled key is actually an admin flag allowing to gain administrative access The key used internally in the system to identify the user record can be externally controlled. For example attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value. Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected. Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.. Ensure that access control mechanisms cannot be bypassed by ensuring that the user has sufficient privilege to access the record that is being requested given his authenticated identity on each and every data access. 1000 Weakness ChildOf 284 All Architecture and Design A software system that allows Windows shortcuts (.LNK) as part of paths whether in internal code or through user input can allow an attacker to spoof the symbolic link and traverse the file system to unintended locations or access arbitrary files. The shortcut (file with the .lnk extension) can permit an attacker to read/write a file that they originally did not have permissions to access. Windows symbolic link following (symlink) Medium to High Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Follow the principle of least privilege when assigning access rights to files. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted. CVE-2000-0342 CVE-2001-1042 CVE-2001-1043 CVE-2005-0587 CVE-2001-1386 ".LNK." - .LNK with trailing dot CVE-2003-1233 Rootkits can bypass file access restrictions to Windows kernel directories using NtCreateSymbolicLinkObject function to create symbolic link Under-studied. Windows .LNK files are more "portable" than Unix symlinks and have been used in remote exploits. Some Windows API's will access LNK's as if they are regular files, so one would expect that they would be reported more frequently. 1000 Category ChildOf 63 Windows Shortcut Following (.LNK) All It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Very often the password recovery mechanism is weak which has the effect of making it more likely that it would be possible for a person other than the legitimate system user to gain access to that user's account. This weakness may be that the security question is too easy to guess or find an answer to (e.g. because it is too common). Or there might be an implementation weakness in the password recovery mechanism code that may for instance trick the system into e-mailing the new password to an e-mail account other than that of the user. There might be no throttling done on the rate of password resets so that a legitimate user can be denied service by an attacker if an attacker tries to recover their password in a rapid succession. The system may send the original password to the user rather than generating a new temporary password. In summary, password recovery functionality, if not carefully designed and implemented can often become the system's weakest link that can be misused in a way that would allow an attacker to gain unauthorized access to the system. Weak password recovery schemes completely undermine a strong password authentication scheme. High An attacker gains unauthorized access to the system by retrieving legitimate user's authentication credentials An attacker denies service to legitimate system users by launching a brute force attack on the password recovery mechanism using user ids of legitimate users The system's security functionality is turned against the system by the attacker. The system allows users to recover their passwords and gain access back into the system. Password recovery mechanism relies only on something the user knows and not something the user has. Weak security questions are used. No third party intervention is required to use the password recovery mechanism. Make sure that all input supplied by the user to the password recovery mechanism is thoroughly filtered and validated Do not use standard weak security questions and use several security questions. Make sure that there is throttling on the number of incorrect answers to a security question. Disable the password recovery functionality after a certain (small) number of incorrect guesses. Require that the user properly answers the security question prior to resetting their password and sending the new password to the e-mail address of record. Never allow the user to control what e-mail address the new password will be sent to in the password recovery mechanism. Assign a new temporary password rather than revealing the original password. A famous example of this type of weakness being exploited is the eBay attack. eBay always displays the user id of the highest bidder. In the final minutes of the auction, one of the bidders could try to log in as the highest bidder three times. After three incorrect log in attempts, eBay password throttling would kick in and lock out the highest bidder's account for some time. An attacker could then make their own bid and their victim would not have a chance to place the counter bid because they would be locked out. Thus an attacker could win the auction. 1000 Category ChildOf 255 All Architecture and Design Implementation When an application does not restrict the valid names of resources (e.g. files) supplied by the user, various problems may arise down the line when these resources are used. For instance, if the names of these resources contain scripting characters, it is possible that a script may get executed in the client's browser if the application ever displays the name of the resource on a dynamically generated webpage. Or if the resources are consumed by some application parser, a specially crafted name can exploit some vulnerability internal to the parser, potentially resulting in execution of arbitrary code on the server machine. The problems will vary based on the context of usage of such malformed resource names and whether vulnerabilities are present in or assumptions are made by the targeted technology that would make code execution possible. Low Execution of arbitrary code in the context of usage of the resources with dangerous names Crash of the consumer code of these resources resulting in information leakage or denial of service Resource names are controllable by the user. No sufficient validation of resource names at entry points or before consumption by other processes. Context where the resources are consumed makes execution of code possible based on the names of the supplied resources. Do not allow users to control names of resources used on the server side. Perform white list input validation at entry points and also before consuming the resources. Reject bad file names rather than trying to cleanse them. Make sure that technologies consuming the resources are not vulnerable (e.g. buffer overflow, format string, etc.) in a way that would allow code execution if the name of the resource is malformed. Format string vulnerability in Dia 0.94 allows user-assisted attackers to cause a denial of service (crash) and possibly execute arbitrary code by triggering errors or warnings, as demonstrated via format string specifiers in a .bmp filename. [CVE-2006-2480 available at: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2480 ] 1000 Weakness ChildOf 99 All Architecture and Design Implementation An application manages user state information in a way that it can be tampered with by the user of an application to give him or her an elevated level of access to the data handled by the application and/or its functionality. An application may store user state on the client in a way that enables tampering. For instance, state information can be stored in a cookie, in a hidden web form field or in some other settings file stored locally. State information may also be passed as a query parameter through the URL or come in a form of some identifier set by one page in the application and consumed by another to signify state information. In each of these cases, chances are that application user can tamper with the state information. Whenever an application cannot definitively and unambiguously control its own state information and state information for each of the application users, there is insufficient management of user state that may potentially be exploited by attackers. High Accessibility Elevation of Privilege Information Disclosure An application maintains its own state and/or user state (i.e. application is stateful). State information can be affected by the user of an application through some means other than the legitimate state transitions (e.g. logging into the system, purchasing an item, making a payment, etc.) An application does not have means to detect state tampering and behave in a fail safe manner. Do not keep state information on the client without using encryption properly or having a mechanism on the server side to catch state tampering. Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions. An e-commerce application with a shopping cart uses hidden form field to store information relating to the total price of the items in the cart. There are no additional checks in the server side code to ensure that the total price is correct given the items in the shopping cart. An attacker can then decide how much they want to pay for the items in the cart and modify the hidden form field in the shopping cart with that value, thus buying the items for the price of their choosing. 1000 Category ChildOf 371 1000 Weakness ChildOf 668 All Architecture and Design Implementation When an application fails to properly validate and sanitize user input and uses that input to dynamically construct an XPath expression used to retrieve data from an XML database the user will be able to control the structure of such query. The net effect is that user will have control over the information selected from the XML database and may use that ability to control application flow and bypass important checks (e.g. authentication). This weakness is similar to other weaknesses that enable injection style attacks, such as SQL injection, command injection and LDAP injection. The main difference is that the target of attack here is the XML database. High Controlling application flow (e.g. bypassing authentication) Information disclosure Escalation of privilege XPath queries are constructed dynamically using user supplied input The application does not perform sufficient validation or sanitization of user supplied input Use parameterized XPath queries (e.g. using XQuery). This will help ensure separation between data plane and control plane. Properly validate user input. Reject data where appropriate, filter where appropriate and escape where appropriate. Make sure input that will be used in XPath queries is safe in that context. Consider the following simple XML document that stores authentication information and a snippet of Java code that uses XPath query to retrieve authentication information: Java john abracadabra /home/john cbc 1mgr8 /home/cbc The Java code used to retrieve the home directory based on the provided credentials is: XPath xpath = XPathFactory.newInstance().newXPath(); XPathExpression xlogin = xpath.compile("//users/user[login/text()='" + login.getUserName() + "' and password/text() = '" + login.getPassword() + "']/home_dir/text()"); Document d = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new File("db.xml")); String homedir = xlogin.evaluate(d); Assume that user "john" wishes to leverage XPath Injection and login without a valid password. By providing a username "john" and password "' or ''='" the XPath expression now becomes //users/user[login/text()='john' or ''='' and password/text() = '' or ''='']/home_dir/text() which, of course, lets user "john" login without a valid password, thus bypassing authentication. []]> 1000 Weakness ChildOf 91 All Implementation If an application fails to filter or escape user controlled data being placed in the header of an HTTP response coming from the server, the header may contain a script that will get executed in the client's browser context, potentially resulting in a cross site scripting vulnerability. This weakness may also enable the HTTP response splitting attack. It is important to carefully control data that is being placed both in HTTP response header and in the HTTP response body to ensure that no scripting syntax is present, taking various encodings into account. High Run Arbitrary Code Information Leakage Privilege Escalation Script execution functionality is enabled in the user's browser. Perform output validation in order to filter/escape/encode unsafe data that is being passed from the server in an HTTP response header. Disable script execution functionality in the clients' browser. CVE-2006-3918: Summary: http_protocol.c in (1) IBM HTTP Server 6.0 before 6.0.2.13 and 6.1 before 6.1.0.1, and (2) Apache HTTP Server 1.3 before 1.3.35, 2.0 before 2.0.58, and 2.2 before 2.2.2, does not sanitize the Expect header from an HTTP request when it is reflected back in an error message, which might allow cross-site scripting (XSS) style attacks using web client components that can send arbitrary headers in requests, as demonstrated using a Flash SWF file. 1000 Weakness ChildOf 116 All Architecture and Design Implementation Account lockout is a security feature often present in applications as a countermeasure to the brute force attack on the password based authentication mechanism of the system. After a certain number of failed login attempts the users' account may be disabled for a certain period of time or until it is unlocked by an administrator. Other security events may also possibly trigger account lockout. An attacker may however use this very security feature as a means to denying service to legitimate system users. It is therefore important to ensure that the account lockout security mechanism is not overly restrictive. High Denial of Service The system has an account lockout mechanism. An attacker must be able to trigger the account lockout mechanism. Implement more intelligent password throttling mechanisms such as those which take IP address into account, in addition to the login name. Implement a lockout timeout that grows as the number of incorrect login attempts goes up, eventually resulting in a complete lockout. Consider alternatives to account lockout that would still be effective against password brute force attacks, such as presenting the user machine with a puzzle to solve (makes it do some computation). A famous example of this type an attack is the eBay attack. eBay always displays the user id of the highest bidder. In the final minutes of the auction, one of the bidders could try to log in as the highest bidder three times. After three incorrect log in attempts, eBay password throttling would kick in and lock out the highest bidder's account for some time. An attacker could then make their own bid and their victim would not have a chance to place the counter bid because they would be locked out. Thus an attacker could win the auction. 1000 Weakness ChildOf 287 All Architecture and Design When server side functionality relies on file name and/or file extension of a user supplied file to determine the proper course of action, such as selecting the correct process to which control should be passed, deciding what data should be made available or what resources should be allocated, it becomes possible for an attacker to deliberately cause the server side code to misclassify the supplied file in order to gain some advantage. It might become possible for an attacker to cause exhaustion of resources, denial of service, information disclosure of debug or system data (including application source code), or being bound to a particular server side process. This weakness may be due to a vulnerability in any of the technologies used by the web and application servers, due to misconfiguration or to a flaw in the application itself. High Information Leakage Denial of Service Privilege Escalation There is reliance on file name and/or file extension on the server side for processing. Make decisions on the server side based on file content and not on file name or extension. Properly configure web and applications servers. Install the latest security patches for all of the technologies being used on the server side. CVE-2000-0499: A vulnerability was found in 2000 in the IBM WebSphere application server that allowed a remote attacker to view source code of the jsp page by requesting a URL that provides a JSP extension in upper case. 1000 Weakness ChildOf 345 All Architecture and Design Implementation System Configuration If an application defines policy namespaces and makes authorization decisions based on URL containing a particular encoding for the path (e.g. using one way of representing an IP address) without having a default policy to deny access, an alternate (but equivalent) encoding for the path may be used to bypass the authorization checks. Therefore it is important to specify access control policy that is based on the path information in some canonical form with all alternate encodings rejected (which can be accomplished by a default deny rule). High Privilege Escalation Information Leakage An application specifies its policy namespaces and access control rules based on the path information. Alternate (but equivalent) encodings exist to represent the same path information that will be understood and accepted by the process consuming the path and granting access to resources. Make access control policy based on path information in canonical form. Use very restrictive regular expressions to validate that the path is in the expected form. Reject all alternate path encodings that are not in the expected canonical form. Example from CAPEC (CAPEC ID: 4, "Using Alternative IP Address Encodings") An attacker identifies an application server that applies a security policy based on the domain and application name, so the access control policy covers authentication and authorization for anyone accessing http://example.domain:8080/application. However, by putting in the IP address of the host the application authentication and authorization controls may be bypassed http://192.168.0.1:8080/application. The attacker relies on the victim applying policy to the namespace abstraction and not having a default deny policy in place to manage exceptions. 1000 Weakness ChildOf 287 All Architecture and Design Implementation System Configuration When an application contains certain functions that perform operations requiring an elevated level of privilege on the system and callers of these APIs are not careful in ensuring that assumptions made by these APIs are valid, do not account for weaknesses in design/implementation of the privileged APIs, call these APIs from an unsafe or unexpected context, or pass/receive data to or from the privileged function that may allow a malicious user or process to elevate their privilege, the stage might be set for escalation of privilege, process hijacking or theft of sensitive data. For instance, it is important to know if privileged APIs fail to properly shed their privileges before returning to the caller or if the privileged function might make certain assumptions about the data, context or state information passed to it by the caller. It is important to always know when and how privileged APIs can be called in order to ensure that their elevated level of privilege cannot be exploited. Low Elevation of privilege Information disclosure Arbitrary code execution An application contains functions running processes that hold higher privileges. There is code in the application that calls the privileged APIs. There is a way for a user to control the data that is being passed to the privileged API or control the context from which it is being called. Before calling privileged APIs always ensure that the assumptions made by the privileged code hold true prior to making the call. Know architecture and implementation weaknesses of the privileged APIs and make sure to account for these weaknesses before calling the privileged APIs to ensure that they can be called safely. If privileged APIs make certain assumptions about data, context or state validity that are passed by the caller, the calling code must ensure that these assumptions have been validated prior to making the call. If privileged APIs fail to shed their privilege prior to returning to the calling code then calling code needs to shed these privileges immediately and safely right after the call to the privileged APIs. In particular the calling code needs to ensure that under no circumstances a privileged thread of execution is returned to the user or made available to user controlled processes. Only call privileged APIs from safe, consistent and expected state. Ensure that a failure or an error will not leave a system in a state where privileges are not properly shed and privilege escalation is possible (i.e. fail securely with regards to handling of privileges). From http://xforce.iss.net/xforce/xfdb/12848: man-db is a Unix utility that displays online help files. man-db versions 2.3.12 beta and 2.3.18 to 2.4.1 could allow a local attacker to gain privileges, caused by a vulnerability when the open_cat_stream function is called. If man-db is installed setuid, a local attacker could exploit this vulnerability to gain "man" user privileges. 1000 Category ChildOf 265 1000 Weakness ChildOf 227 All Architecture and Design Implementation System Configuration When an application relies on obfuscation or incorrectly applied / weak encryption to protect client controllable tokens or parameters, that may have an effect on the user state, system state or some decision made on the server, without protecting the tokens/parameters for integrity, the application is vulnerable to an attack where an adversary blindly traverses the space of possible values of the said token/parameter in order to attempt to gain an advantage. The goal of the attacker is to find another admissible value that will somehow elevate his or her privileges in the system, disclose information or change the behavior of the system in some way beneficial to the attacker. If the application fails to protect these critical tokens/parameters for integrity it will not be able to determine that these values have been tampered with. Measures that are used to protect data for confidentiality should not be relied upon to provide the integrity service. High Elevation of Privilege Information Disclosure Functionality Abuse The application uses client controllable tokens/parameters in order to make decisions on the server side about user state, system state or other decisions related to the functionality of the application. The application fails to protect client controllable tokens/parameters for integrity and thus not able to catch tampering. Protect important client controllable tokens/parameters for integrity using PKI methods (i.e. digital signatures) or other means, and checks for integrity on the server side. Repeated requests from a particular user that include invalid values of tokens/parameters (those that should not be changed manually by users) should result in the user account lockout. Client side tokens/parameters should not be such that it would be easy/predictable to guess another valid state Obfuscation should not be relied upon. If encryption is used, it needs to be properly applied (i.e. proven algorithm and implementation, use padding, use random initialization vector, user proper encryption mode). Even with proper encryption where the ciphertext does not leak information about the plaintext or reveal its structure compromising integrity is possible (although less likely) without the provision of the integrity service. From CVE-2005-0039: Certain configurations of IPsec, when using Encapsulating Security Payload (ESP) in tunnel mode, integrity protection at a higher layer, or Authentication Header (AH), allow remote attackers to decrypt IPSec communications by modifying the outer packet in ways that cause plaintext data from the inner packet to be returned in ICMP messages, as demonstrated using CBC bit-flipping attacks and (1) Destination Address Rewriting, (2) a modified header length that causes portions of the packet to be interpreted as IP Options, or (3) a modified protocol field and source address. The reason for the vulnerability is a failure to require integrity checking of the IPSec packet as the result of either not configuring ESP properly to support the integrity service or using AH improperly. In either case, the security gateway receiving the the IPSec packet would not validate the integrity of the packet to ensure that it was not changed. Thus if the packets were intercepted the attacker could undetectably change some of the bits in the packets. The meaningful bit flipping was possible due to the known weaknesses in the CBC encryption mode. Since the attacker knew the structure of the packet, he or she was able (in one variation of the attack) to use bit flipping to change the destination IP of the packet to the destination machine controlled by the attacker. And so the destination security gateway would decrypt the packet and then forward the plaintext to the machine controlled by the attacker. The attacker could then read the original message. For instance if VPN was used with the vulnerable IPSec configuration the attacker could read the victim's e-mail. This vulnerability demonstrates the need to enforce the integrity service properly when critical data could be modified by an attacker. This problem might have also been mitigated by using an encryption mode that is not susceptible to bit flipping attacks, but the preferred mechanism to address this problem still remains message verification for integrity. While this attack focuses on the network layer and requires a man in the middle scenario, the situation is not much different at the software level where an attacker can modify tokens/parameters used by the application. 1000 Weakness ChildOf 345 All Architecture and Design Implementation Failure for a system to check for hardlinks can result in vulnerability to different types of attacks. For example, an attacker can escalate their privileges if an he/she can replace a file used by a privileged program with a hardlink to a sensitive file (e.g. etc/passwd). When the process opens the file, the attacker can assume the privileges of that process or possibly prevent a program from accurately processing data in a software system. Follow the principle of least privilege when assigning access rights to files. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted. CVE-2002-0725 CVE-2003-0844 Under-studied 1000 Category ChildOf 63 Windows hard link All If functionality on the server side trusts that the HTTP GET method will not allow for a resource representation residing at the URI being accessed to be modified (as per specification of the HTTP GET) and does not provide additional controls to impede such modification, the application will be vulnerable to resource modification and deletion attacks. An application may disallow the HTTP requests to perform DELETE, PUT and POST operations on the resource representation believing that that will be enough to prevent unintended resource alterations. However, there is nothing in the HTTP protocol itself that prevents the HTTP GET method from performing more than just query of the data. For instance, it is a common practice with REST based Web Services to have HTTP GET requests modifying resources on the server side. Whenever that happens however, the access control needs to be properly enforced in the application and no assumptions should be made that only HTTP DELETE, PUT, and POST methods have the power to alter the representation of the resource being accessed in the request. High Escalation of Privilege Modification of Resources Information Disclosure The application allows HTTP access to resources. The application is not properly configured to enforced access controls around the resources accessible via HTTP. Configure ACLs on the server side to ensure that proper level of access control is defined for each accessible resource representation. Do not make an assumption that only HTTP PUT, DELETE or POST methods can modify resources, since HTTP GET method may do the same. The HTTP GET method is designed to retrieve resources and not to alter the state of the application or resources on the server side. However, developers can easily code programs that accept a HTTP GET request that do in fact create, update or delete data on the server. Both Flickr (http://www.flickr.com/services/api/flickr.photosets.delete.html) and del.icio.us (http://del.icio.us/api/posts/delete) have implemented delete operations using standard HTTP GET requests. These HTTP GET methods do delete data on the server side, despite being called from GET, which is not supposed to alter state. 1000 Weakness ChildOf 227 All Architecture and Design Implementation System Configuration Web services architecture may require exposing a WSDL file that contains information on the publicly accessible services and how callers of these services should interact with them (e.g. what parameters they expect and what types they return). An information disclosure leak may occur if: 1. WSDL file is accessible to a wider audience that intended 2. WSDL file contains information on the methods/services that should not be publicly accessible or information about deprecated methods This problem is made more likely due to the WSDL often being automatically generated from the code 3. Information in WSDL file helps guess names/locations of methods/resources that should not be publicly accessible Information Disclosure The system employs a web services architecture. WSDL is used to advertise information information on how to communicate with the service. Limit access to the WSDL file as much as possible. If services are provided only to a limited number of entities, it may be better to provide WSDL privately to each of these entities than to publish WSDL publicly. Make sure that WSDL does not describe methods that should not be publicly accessible. Make sure to protect service methods that should not be publicly accessible with access controls. Do not use method names in WSDL that might help an adversary guess names of private methods/resources used by the service. The WSDL for a service providing information on the best price of a certain item exposes the following method: float getBestPrice(String ItemID) An attacker might guess that there is a method setBestPrice (String ItemID, float Price) that is available and invoke that method to try and change the best price of a given item to their advantage. The attack may succeed if the attacker correctly guesses the name of the method, the method does not have proper access controls around it and the service itself has the functionality to update the best price of the item. 1000 Weakness ChildOf 538 All Architecture and Design Implementation System Configuration When an application fails to properly validate and sanitize user input and uses that input to dynamically construct XQuery expressions used to retrieve data from an XML database the user will be able to control the structure of such query. The net effect is that user will have control over the information selected from the XML database and may use that ability to control application flow and bypass important checks (e.g. authentication). This weakness is similar to other weaknesses that enable injection style attacks, such as SQL injection, command injection and LDAP injection. The main difference is that the target of attack here is the XML database. High Controlling application flow (e.g. bypassing authentication) Information Disclosure Elevation of Privilege XQL queries are constructed dynamically using user supplied input that has not been sufficiently validated. Use parameterized queries. This will help ensure separation between data plane and control plane. Properly validate user input. Reject data where appropriate, filter where appropriate and escape where appropriate. Make sure input that will be used in XQL queries is safe in that context. From CAPEC 84: An attacker can pass XQuery expressions embedded in otherwise standard XML documents. Like SQL injection attacks, the attacker tunnels through the application entry point to target the resource access layer. The string below is an example of an attacker accessing the accounts.xml to request the service provider send all user names back. doc(accounts.xml)//user[name='*'] The attacks that are possible through XQuery are difficult to predict, if the data is not validated prior to executing the XQL. 1000 Weakness ChildOf 91 All Implementation The product does not sufficiently compartmentalize functionality or processes that require different privilege levels, rights, or permissions. When a weakness occurs in functionality that is accessible by lower-privileged users, then without strong boundaries, an attack might extend the scope of the damage to higher-privileged users. Some people and publications use the term "Separation of Privilege" to describe this weakness, but this term has dual meanings in current usage. This node conflicts with the original definition of "Separation of Privilege" by Saltzer and Schroeder; that original definition is more closely associated with CWE-654. Because there are multiple interpretations, use of the "Separation of Privilege" term is discouraged. Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) Confidentiality, Integrity, Availability: the exploitation of a weakness in low-privileged areas of the software can be leveraged to reach higher-privileged areas without having to overcome any additional obstacles. Break up privileges between different modules, objects or entities. Minimize the interfaces between modules and require strong access control between them. Single sign-on technology is intended to make it easier for users to access multiple resources or domains without having to authenticate each time. While this is highly convenient for the user and attempts to address problems with psychological acceptability, it also means that a compromise of a user's credentials can provide immediate access to all other resources or domains. The traditional UNIX privilege model provides root with arbitrary access to all resources, but root is frequently the only user that has privileges. As a result, administrative tasks require root privileges, even if those tasks are limited to a small area, such as updating user man pages. Some UNIX flavors have a "bin" user that is the owner of system executables, but since root relies on executables owned by bin, a compromise of the bin account can be leveraged for root privileges by modifying a bin-owned executable, such as CVE-2007-4238. The term "Separation of Privilege" is used in several different ways in the industry, but they generally combine two closely related principles: compartmentalization (this node) and using only one factor in a security decision (CWE-654). Proper compartmentalization implicitly introduces multiple factors into a security decision, but there can be cases in which multiple factors are required for authentication or other mechanisms that do not involve compartmentalization, such as performing all required checks on a submitted certificate. It is likely that CWE-653 and CWE-654 will provoke further discussion. There is a close association with CWE-250(Failure to Use Least Privilege). CWE-653 is about providing separate components for each privilege; CWE-250 is about ensuring that each component has the least amount of privileges possible. In this fashion, compartmentalization becomes one mechanism for reducing privileges. Jerome H. Saltzer 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 Michael Gegick Separation of Privilege 2005-12-06 https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/357.html 1000 Weakness ChildOf 657 1000 Category ChildOf 254 All A security mechanism relies exclusively, or to a large extent, on the evaluation of a single condition or the integrity of a single object or entity in order to make a decision about granting access to restricted resources or functionality. Some people and publications use the term "Separation of Privilege" to describe this weakness, but this term has dual meanings in current usage. While this node is closely associated with the original definition of "Separation of Privilege" by Saltzer and Schroeder, others use the same term to describe poor compartmentalization (CWE-653). Because there are multiple interpretations, use of the "Separation of Privilege" term is discouraged. Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) Integrity: If the single factor is compromised (e.g. by theft or spoofing), then the integrity of the entire security mechanism can be violated with respect to the user that is identified by that factor. Accountability: it can become difficult or impossible for the product to be able to distinguish between legitimate activities by the entity who provided the factor, versus illegitimate activities by an attacker. Use multiple simultaneous checks before granting access to critical operations or granting critical privileges. A weaker but helpful mitigation is to use several successive checks (multiple layers of security). Use redundant access rules on different choke points (e.g., firewalls). Password-only authentication is perhaps the most well-known example of use of a single factor. Anybody who knows a user's password can impersonate that user. When authenticating, use multiple factors, such as "something you know" (such as a password) and "something you have" (such as a hardware-based one-time password generator, or a biometric device). This node is closely associated with the term "Separation of Privilege." This term is used in several different ways in the industry, but they generally combine two closely related principles: compartmentalization (CWE-653) and using only one factor in a security decision (this node). Proper compartmentalization implicitly introduces multiple factors into a security decision, but there can be cases in which multiple factors are required for authentication or other mechanisms that do not involve compartmentalization, such as performing all required checks on a submitted certificate. It is likely that CWE-653 and CWE-654 will provoke further discussion. Jerome H. Saltzer 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 Michael Gegick Separation of Privilege 2005-12-06 https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/357.html 1000 Weakness ChildOf 657 1000 Category ChildOf 254 All A security mechanism is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose. Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) Integrity: by bypassing the security mechanism, a user might leave the system in a less secure state than intended by the administrator, making it more susceptible to compromise. Where possible, perform human factors and usability studies to identify where your product's security mechanisms are difficult to use, and why. Make the security mechanism as seamless as possible, while also providing the user with sufficient details when a security decision produces unexpected results. In "Usability of Security: A Case Study" (see References), the authors consider human factors in a cryptography product. Some of the weakness relevant discoveries of this case study were: users accidentally leaked sensitive information, could not figure out how to perform some tasks, thought they were enabling a security option when they were not, and made improper trust decisions. Enforcing complex and difficult-to-remember passwords that need to be frequently changed for access to trivial resources, e.g., to use a black-and-white printer. Complex password requirements can also cause users to store the passwords in an unsafe manner so they don't have to remember them, such as using a sticky note or saving them in an unencrypted file. Some CAPTCHA utilities produce images that are too difficult for a human to read, causing user frustration. This weakness covers many security measures causing user inconvenience, requiring effort or causing frustration, that are disproportionate to the risks or value of the protected assets, or that are perceived to be ineffective. Jerome H. Saltzer 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 Michael Gegick Psychological Acceptability 2005-09-15 https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/354.html J. D. Tygar Alma Whitten Usability of Security: A Case Study SCS Technical Report Collection, CMU-CS-98-155 1998-12-15 http://reports-archive.adm.cs.cmu.edu/anon/1998/CMU-CS-98-155.pdf 1000 Weakness ChildOf 657 1000 Category ChildOf 254 All The strength of a security mechanism depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to allow the mechanism to be compromised. This reliance on "security through obscurity" can produce resultant weaknesses if an attacker is able to reverse engineer the inner workings of the mechanism. Note that obscurity can be one small part of defense in depth, since it can create more work for an attacker; however, it is a significant risk if used as the primary means of protection. Never Assuming your secrets are safe Primary (Weakness exists independent of other weaknesses) Implicit (This is an implicit weakness) Confidentiality, Integrity, Availability: the security mechanism can be bypassed easily. Always consider whether knowledge of your code or design is sufficient to break it. Reverse engineering is a highly successful discipline, and financially feasible for motivated adversaries. Black-box techniques are established for binary analysis of executables that use obfuscation, runtime analysis of proprietary protocols, inferring file formats, and others. When available, use publicly-vetted algorithms and procedures, as these are more likely to undergo more extensive security analysis and testing. This is especially the case with encryption and authentication. The design of TCP relies on the secrecy of Initial Sequence Numbers (ISNs), as originally covered in CVE-1999-0077. If ISNs can be guessed (due to predictability, CWE-330) or sniffed (due to lack of encryption, CWE-311), then an attacker can hijack or spoof connections. Many TCP implementations have had variations of this problem over the years, including CVE-2004-0641, CVE-2002-1463, CVE-2001-0751, CVE-2001-0328, CVE-2001-0288, CVE-2001-0163, CVE-2001-0162, CVE-2000-0916, and CVE-2000-0328. CVE-2006-6588 Reliance on hidden form fields in a web application. Many web application vulnerabilities exist because the developer did not consider that "hidden" form fields can be processed using a modified client. CVE-2006-7142 Hard-coded cryptographic key stored in executable program. CVE-2005-4002 Hard-coded cryptographic key stored in executable program. CVE-2006-4068 Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks. Jerome H. Saltzer 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 Michael Gegick Never Assuming that Your Secrets Are Safe 2005-09-14 https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/352.html 1000 Weakness ChildOf 657 1000 Category ChildOf 254 1000 Weakness CanPrecede 259 1000 Weakness CanPrecede 321 1000 Weakness CanPrecede 472 All The product violates well-established principles for secure design. This can introduce resultant weaknesses or make it easier for developers to introduce related weaknesses during implementation. Because code is centered around design, it can be resource-intensive to fix design problems. Jerome H. Saltzer 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 Michael Gegick Design Principles 2005-09-19 https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/358.html 1000 Category ChildOf 17 The product does not properly handle a file name that identifies a "virtual" resource that is not directly specified within the directory that is associated with the file name, causing the product to perform file-based operations on a resource that is not a file. Virtual file names are represented like normal file names, but they are effectively aliases for other resources that do not behave like normal files. Depending on their functionality, they could be alternate entities. They are not necessarily listed in directories. File processing File/Directory 1000 Weakness ChildOf 21 Virtual Files All The software attempts to use a shared resource in an exclusive manner, but fails to prevent use by another thread or process. 1000 Category ChildOf 361 1000 Weakness ChildOf 691 The software calls a non-reentrant function in a context where a competing thread may have an opportunity to call the same function or otherwise influence its state. 1000 Weakness ChildOf 662 The software does not correctly initialize, use, or release a resource according to its specifications. Resources typically have explicit instructions on how to be created, used and destroyed. When software fails to follow these instructions it can lead to unexpected behaviors and potentially exploitable states. 1000 Category ChildOf 361 The software does not follow the proper procedures for initializing a resource and might leave the resource in an improper state for future uses. CVE-2001-1471 An invalid value prevents a library file from being included, skipping initialization of key variables, leading to resultant eval injection. CVE-2005-1036 Permission bitmap is not properly initialized, leading to resultant privilege elevation or DoS. 1000 Weakness ChildOf 664 Incorrect initialization All The software performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors. When a developer wants to initialize, use or release a resource, it is important to follow the specifications outlined for how to operate on that resource and to ensure that the resource is in the expected state. In this case, the software wants to perform a normally valid operation, initialization, use or release, on a resource when it is in the incorrect phase of its lifetime. 1000 Weakness ChildOf 664 The software does not properly acquire a lock on a resource, leading to unexpected resource state changes and behaviors. 1000 Weakness ChildOf 662 The product exposes a resource to the wrong sphere, in ways that are not related to incorrectly specified permissions. Accessibility A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors. 1000 Category ChildOf 361 The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource. Accessibility A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors. 1000 Category ChildOf 361 Failing to properly handle virtual filenames (e.g. AUX, CON, PRN, COM1, LPT1) can result in different types of vulnerabilities. In some cases an attacker can request a device via injection of a virtual filename in a URL, which may cause an error that leads to a denial-of-service or an error page that reveals sensitive information. A software system that allows device names to bypass filtering runs the risk of an attacker injecting malicious code in a file with the name of a device. High to Very High Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) File/Directory Be familiar with the device names in the operating system where your system is deployed. Check input for these device names. CVE-2002-0106 CVE-2002-0200 CVE-2002-1052 CVE-2001-0493 CVE-2001-0558 CVE-2000-0168 CVE-2001-0492 CVE-2004-0552 CVE-2005-2195 Historically, there was a bug in the Windows operating system that caused a blue screen of death, but even after that issue was fixed, DOS device names continue to be a factor. M. Howard D. LeBlanc Writing Secure Code 2nd Edition Microsoft 2003 1000 Weakness ChildOf 66 631 Category ChildOf 632 Windows MS-DOS device names All The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated. This weakness captures cases in which a particular code segment is always incorrect with respect to the algorithm that it is implementing. For example, if a C programmer intends to include multiple statements in a single block but does not include the enclosing braces (CWE-483), then the logic is always incorrect. This issue is in contrast to most weaknesses in which the code usually behaves correctly, except when it is externally manipulated in malicious ways. This issue typically appears in rarely-tested code, since the "always-incorrect" nature will be detected as a bug during normal usage. This node could possibly be split into lower-level nodes. "Early Return" is for returning control to the caller too soon (e.g., CWE-584). "Excess Return" is when control is returned too far up the call stack (CWE-600, CWE-395). "Improper control limitation" occurs when the product maintains control at a lower level of execution, when control should be returned "further" up the call stack (CWE-455). "Incorrect syntax" covers code that's "just plain wrong" such as CWE-484 and CWE-483. 1000 Category ChildOf 18 The product uses security features in a way that prevents the product's administrator from tailoring security settings to reflect the environment in which the product is being used. This introduces resultant weaknesses. If the product's administrator does not have the ability to manage security-related decisions at all times, then protecting the product from outside threats - including the product's developer - can become impossible. For example, a hard-coded account name and password cannot be changed by the administrator, thus exposing that product to attacks that the administrator can not prevent. Accessibility 1000 Weakness ChildOf 657 Architecture and Design The software fails to renew or discontinue the use of a resource after expiration, release or revocation. 1000 Weakness ChildOf 666 The product does not prevent the definition of control spheres from external actors. Typically, a product defines its control sphere within the code itself, or through configuration by the product's administrator. In some cases, an external party can change the definition of the control sphere. This is typically a resultant weakness. Mutability Consider a blog publishing tool, which might have three explicit control spheres: the creation of articles, only accessible to a "publisher;" commenting on articles, only accessible to a "commenter" who is a registered user; and reading articles, only accessible to an anonymous reader. Suppose that the application is deployed on a web server that is shared with untrusted parties. If a local user can modify the data files that define who a publisher is, then this user has modified the control sphere. In this case, the issue would be resultant from another weakness such as insufficient permissions. In Untrusted Search Path (CWE-426), a user might be able to define the PATH environment variable to cause the product to search in the wrong directory for a library to load. The product's intended sphere of control would include "resources that are only modifiable by the person who installed the product." The PATH effectively changes the definition of this sphere so that it overlaps the attacker's sphere of control. A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors. 1000 Category ChildOf 361 Architecture and Design The product does not properly control the amount of recursion that takes place, which consumes excessive resources, such as allocated memory or the program stack. Stack Exhaustion CPU Availability: resources including CPU, memory, and stack memory could berapidly consumed or exhausted, eventually leading to an exit or crash. Confidentiality: in some cases, an application's interpreter might kill a process or thread that appears to be consuming too much resources, such as with PHP's memory_limit setting. When the interpreter kills the process/thread, it might report an error containing detailed information such as the application's installation path. CVE-2007-1285 Deeply nested arrays trigger stack exhaustion. CVE-2007-3409 Self-referencing pointers create infinite loop and resultant stack exhaustion. 1000 Category ChildOf 399 All The product performs the same operation on a resource two or more times, when the operation should only be applied once. Uniqueness This weakness is probably closely associated with other issues related to doubling, such as CWE-462 (duplicate key in alist) or CWE-102 (Struts duplicate validation forms). It's usually a case of an API contract violation (CWE-227). 1000 Weakness ChildOf 573 1000 Weakness PeerOf 462 1000 Weakness PeerOf 586 1000 Weakness PeerOf 102 1000 Weakness PeerOf 227 All The program invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely. High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) This weakness is different than CWE-242 (Use of Inherently Dangerous Function). CWE-242 covers functions with such significant security problems that they can never be guaranteed to be safe. Some functions, if used properly, do not directly pose a security risk, but can introduce a weakness if not called correctly. These areregarded as potentially dangerous. A well-known example is the strcpy() function. When provided with a destination buffer that is larger than its source, strcpy() will not overflow. However, it is so often misused that some developers prohibit strcpy() entirely. 1000 Weakness ChildOf 573 Dangerous Functions C C++ When converting from one data type to another, such as long to integer, data can be omitted or incorrectly translated, resulting in unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur. 1000 Category ChildOf 189 The software performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management. 1000 Category ChildOf 189 The software calls a function, procedure, or routine, but the caller specifies the arguments in an incorrect order, leading to resultant weaknesses. While this weakness might be caught by the compiler in some languages, it can occur more frequently in cases in which the called function accepts variable numbers or types of arguments, such as format strings in C. It also can occur in languages or environments that do not enforce strong typing. Primary (Weakness exists independent of other weaknesses) CVE-2006-7049 Application calls functions with arguments in the wrong order, allowing attacker to bypass intended access restrictions. This issue is most likely to occur in rarely-tested code. 1000 Weakness ChildOf 628 Implementation The code does not function according to its published specifications, potentially leading to incorrect usage. When providing functionality to an external party, it is important that the software behaves in accordance with the details specified. Failing to document requirements or nuances can result in unintended behaviors for the caller, possibly leading to an exploitable state. 1000 Weakness ChildOf 227 The software calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, leading to undefined behavior and resultant weaknesses. Primary (Weakness exists independent of other weaknesses) While this weakness might be caught by the compiler in some languages, it can occur more frequently in cases in which the called function accepts variable numbers of arguments, such as format strings in C. It also can occur in languages or environments that do not require that functions always be called with the correct number of arguments, such as Perl. This issue is most likely to occur in rarely-tested code. 1000 Weakness ChildOf 628 C Perl Implementation The software calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, leading to resultant weaknesses. This weakness is most likely to occur in loosely typed languages, or in strongly typed languages in which the types of variable arguments cannot be enforced at compilation time, or where there is implicit casting. Primary (Weakness exists independent of other weaknesses) This issue is most likely to occur in rarely-tested code. 1000 Weakness ChildOf 628 Implementation The software calls a function, procedure, or routine, but the caller specifies an argument that contains the wrong value, leading to resultant weaknesses. Primary (Weakness exists independent of other weaknesses) This might require an understanding of intended program behavior or design to determine whether the value is incorrect. This Perl code intends to record whether a user authenticated successfully or not, and to exit if the user fails to authenticate. However, when it calls ReportAuth(), the third argument is specified as 0 instead of 1, so it does not exit. Perl When primary, this weakness is most likely to occur in rarely-tested code, since the wrong value can change the semantic meaning of the program's execution and lead to obviously-incorrect behavior. It can also be resultant from issues in which the program assigns the wrong value to a variable, and that variable is later used in a function call. In that sense, this issue could be argued as having chaining relationships with many implementation errors in CWE. 1000 Weakness ChildOf 628 Implementation The software calls a function, procedure, or routine, but the caller specifies the wrong variable or reference as one of the arguments, leading to undefined behavior and resultant weaknesses. Primary (Weakness exists independent of other weaknesses) While this weakness might be caught by the compiler in some languages, it can occur more frequently in cases in which the called function accepts variable numbers of arguments, such as format strings in C. It also can occur in loosely typed languages or environments. This might require an understanding of intended program behavior or design to determine whether the value is incorrect. CVE-2005-2548 Kernel code specifies the wrong variable in first argument, leading to resultant NULL pointer dereference. This issue is most likely to occur in rarely-tested code. 1000 Weakness ChildOf 628 C Perl Implementation Alternate data streams (ADS) were first implemented in the Windows NT operating system to provide compatibility between NTFS and the Macintosh Hierarchical File System (HFS). In HFS, data and resource forks are used to store information about a file. The data fork provides information about the contents of the file while the resource fork stores metadata such as file type. An attacker can use an ADS to hide information about a file (e.g. size, the name of the process) from a system or file browser tools such as Windows Explorer and 'dir' at the command line utility. System Process Software tools are capable of finding ADSs on your system. Ensure that the source code correctly parses the filename to read or write to the correct stream. CVE-1999-0278 CVE-2000-0927 Fault: multiple identifiers, non-atomic object M. Howard D. LeBlanc Writing Secure Code 2nd Edition Microsoft 2003 1000 Category ChildOf 68 1000 Weakness ChildOf 66 631 Category ChildOf 634 Windows ::DATA alternate data stream All 11 The code does not sufficiently manage its control flow during execution, creating conditions in which the control flow can be modified in unexpected ways. Validity This is a fairly high-level concept, although it covers a number of weaknesses in CWE that were more scattered throughout the natural hierarchy before Draft 9 was released. 1000 Category ChildOf 18 All The product does not use a protection mechanism that provides sufficient defense against directed attacks against the product. This weakness covers three distinct situations. A "missing" protection mechanism occurs when the application does not define any mechanism against a certain class of attack. An "insufficient" protection mechanism might provide some defenses - for example, against the most common attacks - but it does not protect against everything that is intended. Finally, an "ignored" mechanism occurs when a mechanism is available and in active use within the product, but the developer has not applied it in some code path. This is a fairly high-level concept, although it covers a number of weaknesses in CWE that were more scattered throughout the natural hierarchy before Draft 9 was released. The concept of protection mechanisms is well established, but protection mechanism failures have not been studied comprehensively. It is suspected that protection mechanisms can have significantly different types of weaknesses than the weaknesses that they are intended to prevent. 1000 Category ChildOf 254 All A Web application must define a default error page for 4xx errors (e.g. 404), 5xx (e.g. 500) errors and to catch java.lang.Throwable exceptions to prevent attackers from mining information from the application container's built-in error response. The default error page should not display sensitive information about the software system. Handle exceptions appropriately in source code. Always define appropriate error pages. Do not attempt to process an error or attempt to mask it. Verify return values are correct and do not supply sensitive information about the system. When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks. If the application shows the attacker a stack trace, it relinquishes information that makes the attacker's job significantly easier. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components. The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application. M. Howard D. LeBlanc J. Viega 19 Deadly Sins of Software Security McGraw-Hill/Osborne 2005 1000 Category ChildOf 4 1000 Weakness ChildOf 544 J2EE Misconfiguration: Missing Error Handling Java Software operating in a MAC OS environment where .DS_Store is in effect must carefully manage hard links otherwise an attacker may be able to leverage a hard link from .DS_Store to overwrite arbitrary files and gain privileges. BUGTRAQ:20010910 More security problems in Apache on Mac OS X CVE-2005-0342 The Finder in Mac OS X and earlier allows local users to overwrite arbitrary files and gain privileges by creating a hard link from the .DS_Store file to an arbitrary file. http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-0342 Under-studied 1000 Category ChildOf 70 1000 Weakness PeerOf 62 DS - Apple '.DS_Store All The Apple HFS+ file system permits files to have multiple data input streams. If an attacker can create/access a data input stream directly or indirectly (e.g. through Apache), then he/she may be able to access the file data or resource fork. CVE-2004-1084 Fault: multiple identifiers, non-atomic object Under-studied 1000 Category ChildOf 70 1000 Weakness ChildOf 66 Apple HFS+ alternate data stream All Allowing user input to control paths used in filesystem operations may enable an attacker to access or modify otherwise protected system resources. High to Very High Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) The following code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files. The following code uses input from a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt. Path manipulation errors occur when the following two conditions are met: 1. An attacker can specify a path used in an operation on the filesystem. 2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted. For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker. 1000 Weakness ChildOf 21 Path Manipulation All 80 79 72 64 13 76 78 The software fails to adequately filter user-controlled input data for syntax that has control-plane implications. Software has certain assumptions about what constitutes data and control respectively. It is the lack of verification of these assumptions for user-controlled input that leads to injection problems. Injection problems span a wide range of instantiations. This is usually attempted in order to alter the control flow of the process. Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Confidentiality: Many injection attacks involve the disclosure of important information -- in terms of both data sensitivity and usefulness in further exploitation Authentication: In some cases injectable code controls authentication; this may lead to remote vulnerability Access Control: Injection attacks are characterized by the ability to significantly change the flow of a given process, and in some cases, to the execution of arbitrary code. Integrity: Data injection attacks lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Accountability: Often the actions performed by injected control code are unlogged. Requirements specification: Programming languages and supporting technologies might be chosen which are not subject to these issues. Implementation: Utilize an appropriate mix of white-list and black-list parsing to filter control-plane syntax from all input. Injection problems encompass a wide variety of issues -- all mitigated in very different ways. For this reason, the most effective way to discuss these weaknesses is to note the distinct features which classify them as injection weaknesses. The most important issue to note is that all injection problems share one thing in common -- i.e., they allow for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows, and many other flaws, involve the use of some further issue to gain execution, injection problems need only for the data to be parsed. The most classic instantiations of this category of weakness are SQL injection and format string vulnerabilities. 1000 Weakness ChildOf 20 Injection problem ('data' used as something else) All 10 40 13 14 51 42 24 52 43 34 80 71 53 72 45 91 64 46 28 83 47 84 66 76 67 78 79 101 3 7 8 9 The software fails to adequately filter user-controlled input for special elements with control implications. Requirements specification: Programming languages and supporting technologies might be chosen which are not subject to these issues. Implementation: Utilize an appropriate mix of white-list and black-list parsing to filter special element syntax from all input. 1000 Weakness ChildOf 74 Special Element Injection All The software fails to adequately filter non-typical special elements that are equivalent to control-relevant special elements that are already being filtered. High to Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Requirements specification: Programming languages and supporting technologies might be chosen which are not subject to these issues. Implementation: Utilize an appropriate mix of white-list and black-list parsing to filter equivalent special element syntax from all input. Can include encoded special characters. 1000 Weakness ChildOf 75 Equivalent Special Element Injection All The software fails to adequately filter command (control plane) syntax from user-controlled input (data plane) and then allows potentially injected commands to execute within its context. Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Access control: Command injection allows for the execution of arbitrary commands and code by the attacker. Design: If at all possible, use library calls rather than external processes to recreate the desired functionality Implementation: Utilize black-list parsing to filter non-relevant command syntax from all input. Implementation: Ensure that all external commands called from the program are statically created, or -- if they must take input from a user -- that the input and final line generated are vigorously white-list checked. Run time: Run time policy enforcement may be used in a white-list fashion to prevent use of any non-sanctioned commands. Assign permissions to the software system that prevents the user from accessing/opening privileged files. The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system. Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected. However, if an attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition. The following code is from an administrative web application designed allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies what type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user. The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). Once the shell is invoked, it will happily execute multiple commands separated by two ampersands. If an attacker passes a string of the form "& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well. The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory. The code above allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system. The following code is from a web application that allows users access to an interface through which they can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory, the code for which is shown below. The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system. The following code is a wrapper around the UNIX command cat which prints the contents of a file to standard out. It is also injectable: C #include int main(int argc, char **argv) { char cat[] = "cat "; char *command; size_t commandLength; commandLength = strlen(cat) + strlen(argv[1]) + 1; command = (char *) malloc(commandLength); strncpy(command, cat, commandLength); strncat(command, argv[1], (commandLength - strlen(cat)) ); system(command); return (0); }]]> Used normally, the output is simply the contents of the file requested: $ ./catWrapper Story.txt When last we left our heroes... However, if we add a semicolon and another command to the end of this line, the command is executed by catWrapper with no complaint: $ ./catWrapper Story.txt; ls When last we left our heroes... Story.txt doubFree.c nullpointer.c unstosig.c www* a.out* format.c strlen.c useFree* catWrapper* misnull.c strlength.c useFree.c commandinjection.c nodefault.c trunc.c writeWhatWhere.c If catWrapper had been set to have a higher privilege level than the standard user, arbitrary commands could be executed with that higher privilege. Command injection is a common problem with wrapper programs. Often, parts of the command to be run are controllable by the end user. If a malicious user injects a character (such as a semi-colon) that delimits the end of one command and the beginning of another, he may then be able to insert an entirely new and unrelated command to do whatever he pleases. The most effective way to deter such an attack is to ensure that the input provided by the user adheres to strict rules as to what characters are acceptable. As always, white-list style checking is far preferable to black-list style checking. Dynamically generating operating system commands that include user input as parameters can lead to command injection attacks. An attacker can insert operating system commands or modifiers in the user input that can cause the request to behave in an unsafe manner. Such vulnerabilities can be very dangerous and lead to data and system compromise. If no validation of the parameter to the exec command exists, an attacker can execute any command on the system the application has the privilege to access. Command injection vulnerabilities take two forms: * An attacker can change the command that the program executes: the attacker explicitly controls what the command is. * An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means. In this case we are primarily concerned with the first scenario, in which an attacker explicitly controls the command that is executed. Command injection vulnerabilities of this type occur when: 1. Data enters the application from an untrusted source. 2. The data is part of a string that is executed as a command by the application. 3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have. G. Hoglund G. McGraw Exploiting Software: How to Break Code Addison-Wesley February 2004 1000 Weakness ChildOf 74 629 View ChildOf 629 Command Injection Command injection All 11 75 76 23 15 6 43 The software fails to adequately filter OS command syntax from user-controlled input and then allows potentially injected commands to execute within its context. A software system that accepts and executes input in the form of operating system commands (e.g. system(), exec(), open()) could allow an attacker with lesser privileges than the target software to execute commands with the elevated privileges of the executing process. The problem is exacerbated if the compromised process fails to follow the principle of least privilege. Shell injection, shell metacharacters Program invocation System Process Design: If at all possible, use library calls rather than external processes to recreate the desired functionality Implementation: Utilize black-list parsing to filter non-relevant OS command syntax from all input. Implementation: Ensure that all external commands called from the program are statically created, or -- if they must take input from a user -- that the input and final line generated are vigorously white-list checked. Run time: Run time policy enforcement may be used in a white-list fashion to prevent use of any non-sanctioned commands. Assign permissions to the software system that prevents the user from accessing/opening privileged files. CVE-1999-0067 CVE-2001-1246 CVE-2002-0061 CVE-2003-0041 CVE-2002-1898 Shell metacharacters in a telnet:// link (this is a multi-factor vulnerability, CVE-2007-3572 Chain: incomplete blacklist for OS command injection Fault: unquoted special characters, input restriction error G. Hoglund G. McGraw Exploiting Software: How to Break Code Addison-Wesley February 2004 1000 Weakness ChildOf 77 1000 Weakness CanAlsoBe 88 629 View ChildOf 629 630 View ChildOf 630 631 Category ChildOf 634 635 View ChildOf 635 OS Command Injection All 88 15 6 43 A weakness where the code path has: 1. start statement that accepts input 2. end statement that executes an operating system command where a. the input is used as a part of the operating system command b. the privilege of the operating system command is higher than privilege of the input and c. the operating system command is undesirable Where “undesirable” is defined through the following scenarios: 1. not validated 2. incorrectly validated The software does not sufficiently sanitize user-controllable input for content before it is prepared in output that is used as a web page. Unsanitized special elements that have control implications in web pages, such as HTML tags or mouse events, are interpreted as control characters that execute in violation of the client's trust in the application or system. This weakness usually enables cross-site scripting attacks in web applications. "CSS" was once used as the acronym for this problem, but this can cause confusion with the "Cascading Style Sheets," so this acronym has declined significantly. Its use is discouraged by CWE. High to Very High Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Confidentiality: The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies. Access control: In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is combined with other flaws. If successful, cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Carefully check each input parameter against a rigorous positive specification (white list) defining the specific characters and format allowed. All input should be sanitized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended. This involves "HTML Entity Encoding" all non-alphanumeric characters from data that was received from the user and is now being written to the request. With Struts, you should write all data from form beans with the bean's filter attribute set to true. To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as Internet Explorer), this attribute prevents the user's session cookie from being accessed by client-side scripts, including scripts inserted due to a XSS attack. The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user. JSP ... Employee ID: <%= eid %>]]> The following ASP.NET code segment reads an employee ID number from an HTTP request and displays it to the user. ASP.NET The code in this example operates correctly if eid contains only standard alphanumeric text. If eid has a value that includes meta-characters or source code, then the code will be executed by the web browser as it displays the HTTP response. Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS. The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name. JSP Employee Name: <%= name %>]]> The following ASP.NET code segment queries a database for an employee with a given employee ID and prints the name corresponding with the ID. ASP.NET This code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser. This type of exploit, known as Stored XSS, is particularly insidious because the indirection caused by the data store makes it more difficult to identify the threat and increases the possibility that the attack will affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code. As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim: * As in the previous example, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that may include session information, from the user's machine to the attacker or perform other nefarious activities. * As in this example, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Stored XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user. * A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content. CVE-2007-5727 Chain: only removes SCRIPT tags, enabling XSS CVE-2006-4308 Chain: only checks "javascript:" tag Cross-site scripting weakness occurs when dynamically generated web pages display input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site. If successful, Cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Cross-site scripting (XSS) vulnerabilities occur when an attacker uses a web application to send malicious code, generally JavaScript, to a different end user. When a web application uses input from a user in the output it generates without filtering it, an attacker can insert an attack in that input and the web application sends the attack to other users. The end user trusts the web application, and the attacks exploit that trust to do things that would not normally be allowed. Attackers frequently use a variety of methods to encode the malicious portion of the tag, such as using Unicode, so the request looks less suspicious to the user. XSS attacks can generally be categorized into two categories: stored and reflected. Stored attacks are those where the injected code is permanently stored on the target servers in a database, message forum, visitor log, and so forth. Reflected attacks are those where the injected code takes another route to the victim, such as in an email message, or on some other server. When a user is tricked into clicking a link or submitting a form, the injected code travels to the vulnerable web server, which reflects the attack back to the user's browser. The browser then executes the code because it came from a 'trusted' server. For a reflected XSS attack to work, the victim must submit the attack to the server. This is still a very dangerous attack given the number of possible ways to trick a victim into submitting such a malicious request, including clicking a link on a malicious Web site, in an email, or in an inner-office posting. XSS flaws are very likely in web applications, as they require a great deal of developer discipline to avoid them in most applications. It is relatively easy for an attacker to find XSS vulnerabilities. Some of these vulnerabilities can be found using scanners, and some exist in older web application servers. The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. The most severe XSS attacks involve disclosure of the user's session cookie, which allows an attacker to hijack the user's session and take over their account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, and modifying presentation of content. Cross-site scripting (XSS) vulnerabilities occur when: 1. Data enters a Web application through an untrusted source, most frequently a web request. 2. The data is included in dynamic content that is sent to a web user without being validated for malicious code. The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site. Cross-site scripting attacks can occur wherever an untrusted user has the ability to publish content to a trusted web site. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser -- performs some activity (such as sending all site cookies to a given E-mail address). If the input is unchecked, this script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also. There are several other possible attacks, such as running "Active X" controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy; cookie theft is however by far the most common. All of these attacks are easily prevented by ensuring that no script tags -- or for good measure, HTML tags at all -- are allowed in data to be posted publicly. Cross-site scripting attacks may occur anywhere that possibly malicious users are allowed to post unregulated material to a trusted web site for the consumption of other valid users. The most common example can be found in bulletin-board web sites which provide web based mailing list-style functionality. Jeremiah Grossman Robert "RSnake" Hansen Petko "pdp" D. Petkov Anton Rager Seth Fogie XSS Attacks Syngress 2007 M. Howard D. LeBlanc Writing Secure Code 2nd Edition Microsoft 2003 1000 Weakness ChildOf 74 1000 Weakness CanPrecede 494 1000 Compound_Element PeerOf 352 629 View ChildOf 629 635 View ChildOf 635 1000 692 Compound_Element CanPrecede 692 Cross-site scripting (XSS) Cross-site Scripting Cross-site scripting All 91 19 85 32 86 When an application exposes a remote interface for an entity bean, it might also expose methods that get or set the bean's data. These methods could be leveraged to read sensitive information, or to change data in ways that violate the application's expectations, potentially leading to other vulnerabilities. Declare Java beans "local" when possible. When a bean must be remotely accessible, make sure that sensitive information is not exposed, and ensure that your application logic performs appropriate validation of any data that might be modified by an attacker. EmployeeRecord com.wombat.empl.EmployeeRecordHome com.wombat.empl.EmployeeRecord ... ... ]]> Entity beans that expose a remote interface become part of an application's attack surface. For performance reasons, an application should rarely use remote entity beans, so there is a good chance that a remote entity bean declaration is an error. 1000 Category ChildOf 4 1000 Weakness ChildOf 668 J2EE Misconfiguration: Unsafe Bean Declaration The web application fails to adequately filter user-controlled input and sanitize its own output for any special characters, such as "<", ">", and "&". This may allow such characters to be treated as control characters, which are executed client-side in the context of the user's session. Although this can be classified as an injection problem, the more pertinent issue is the failure to convert such special characters to respective context-appropriate entities before displaying them to the user. High to Very High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Carefully check each input parameter against a rigorous positive specification (white list) defining the specific characters and format allowed. All input should be sanitized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended. This involves "HTML Entity Encoding" all non-alphanumeric characters from data that was received from the user and is now being written to the request. With Struts, you should write all data from form beans with the bean's filter attribute set to true. Additionally, to help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as Internet Explorer), this attribute prevents the user's session cookie from being accessed by client-side scripts, including scripts inserted due to a XSS attack. CVE-2002-0938 XSS in parameter in a link. CVE-2002-1495 XSS in web-based email product via attachment filenames. CVE-2003-1136 HTML injection in posted message. CVE-2004-2171 XSS not quoted in error page. 1000 Weakness ChildOf 79 630 View ChildOf 630 Basic XSS All 18 A weakness where the code path has: 1. start statement that accepts input from HTML page 2. end statement that publishes the a data item to HTML where a. the input is part of the data item and b. the input is undesirable Where “undesirable” is defined through the following scenarios: 1. not validated 2. incorrectly validated This Weakness occurs when a web developer displays user-controlled input on an error page (e.g. a customized 403 Forbidden page). If the input has not been appropriately filtered and sanitized prior to inclusion in the target page, an attacker can influence a victim to view/request a web page that causes an error, containing malicious HTML input, such as scripts. Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Do not write user-controlled input to error pages. Carefully check each input parameter against a rigorous positive specification (white list) defining the specific characters and format allowed. All input should be sanitized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended. This involves "HTML Entity Encoding" all non-alphanumeric characters from data that was received from the user and is now being written to the request. With Struts, you should write all data from form beans with the bean's filter attribute set to true. Additionally, to help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as Internet Explorer), this attribute prevents the user's session cookie from being accessed by client-side scripts, including scripts inserted due to a XSS attack. CVE-2002-0840 XSS in default error page from Host: header. CVE-2002-1053 XSS in error message. CVE-2002-1700 XSS in error page from targeted parameter. 1000 Weakness ChildOf 79 1000 Weakness CanAlsoBe 209 1000 Weakness CanAlsoBe 390 XSS in error pages All A Web application that trusts input in the form of HTML IMG tags is potentially vulnerable to XSS attacks. Attackers can embed XSS exploits into the values for IMG attributes (e.g. SRC) that is streamed and then executed in a victim's browser. Note that when the page is loaded into a user's browsers, the exploit will automatically execute. see the vulnerability category "Cross-site scripting (XSS)" CVE-2002-1649 javascript URI scheme in IMG tag. CVE-2002-1803 javascript URI scheme in IMG tag. CVE-2002-1804 javascript URI scheme in IMG tag. CVE-2002-1805 javascript URI scheme in IMG tag. CVE-2002-1806 javascript URI scheme in IMG tag. CVE-2002-1807 javascript URI scheme in IMG tag. CVE-2002-1808 javascript URI scheme in IMG tag. 1000 Weakness ChildOf 79 Script in IMG tags All 18 91 The software does not filter "javascript:" or other URI's from dangerous attributes within tags, such as onmouseover, onload, onerror, or style. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Carefully check each input parameter against a rigorous positive specification (white list) defining the specific characters and format allowed. All input should be sanitized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended. This involves "HTML Entity Encoding" all non-alphanumeric characters from data that was received from the user and is now being written to the request. With Struts, you should write all data from form beans with the bean's filter attribute set to true. Additionally, to help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as Internet Explorer), this attribute prevents the user's session cookie from being accessed by client-side scripts, including scripts inserted due to a XSS attack. CVE-2001-0520 Bypass filtering of SCRIPT tags using onload in BODY, href in A, BUTTON, INPUT, and others. CVE-2002-1493 guestbook XSS in STYLE or IMG SRC attributes. CVE-2002-1965 Javascript in onerror attribute of IMG tag. CVE-2002-1495 XSS in web-based email product via onmouseover event. CVE-2002-1681 XSS via script in <P> tag. CVE-2003-1136 Javascript in onmouseover attribute. CVE-2004-1935 Onload, onmouseover, and other events in an e-mail attachment. CVE-2005-0945 Onmouseover and onload events in img, link, and mail tags. CVE-2003-1136 Onmouseover attribute in e-mail address or URL. 1000 Weakness ChildOf 79 XSS using Script in Attributes All 18 The web application fails to filter user-controlled input for executable script disguised with URI encodings. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Resolve all URIs to absolute or canonical representations before processing. Carefully check each input parameter against a rigorous positive specification (white list) defining the specific characters and format allowed. All input should be sanitized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended. This involves "HTML Entity Encoding" all non-alphanumeric characters from data that was received from the user and is now being written to the request. With Struts, you should write all data from form beans with the bean's filter attribute set to true. Additionally, to help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as Internet Explorer), this attribute prevents the user's session cookie from being accessed by client-side scripts, including scripts inserted due to a XSS attack. CVE-2005-0563 Cross-site scripting (XSS) vulnerability in Microsoft Outlook Web Access (OWA) component in Exchange Server 5.5 allows remote attackers to inject arbitrary web script or HTML via an email message with an encoded javascript: URL ("jav&#X41sc&#0010;ript:") in an IMG tag. CVE-2005-2276 Cross-site scripting (XSS) vulnerability in Novell Groupwise WebAccess 6.5 before July 11, 2005 allows remote attackers to inject arbitrary web script or HTML via an e-mail message with an encoded javascript URI (e.g. "j&#X41vascript" in an IMG tag). CVE-2005-0692 Encoded script within BBcode IMG tag. CVE-2002-0117 Encoded "javascript" in IMG tag. CVE-2002-0118 Encoded "javascript" in IMG tag. 1000 Weakness ChildOf 79 XSS using Script Via Encoded URI Schemes All 18 32 The web application fails to filter user-controlled input for executable script disguised using doubling of the involved characters. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Resolve all filtered input to absolute or canonical representations before processing. Carefully check each input parameter against a rigorous positive specification (white list) defining the specific characters and format allowed. All input should be sanitized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended. This involves "HTML Entity Encoding" all non-alphanumeric characters from data that was received from the user and is now being written to the request. With Struts, you should write all data from form beans with the bean's filter attribute set to true. Additionally, to help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as Internet Explorer), this attribute prevents the user's session cookie from being accessed by client-side scripts, including scripts inserted due to a XSS attack. CVE-2002-2086 XSS using "<script". CVE-2000-0116 Encoded "javascript" in IMG tag. CVE-2001-1157 Extra "<" in front of SCRIPT tag. 1000 Weakness ChildOf 79 DOUBLE - Doubled character XSS manipulations, e.g. "<script" All 32 The software does not strip out invalid characters in the middle of tag names, schemes, and other identifiers, which are still rendered by some web browsers that ignore the characters. see the vulnerability category "Cross-site scripting (XSS)" CVE-2004-0595 XSS filter doesn't filter null characters before looking for dangerous tags, which are ignored by web browsers. Multiple Interpretation Error (MIE) and validate-before-cleanse. Commonly used characters include null, CRLF, and other non-standard whitespace. 1000 Weakness ChildOf 79 1000 Weakness PeerOf 184 Invalid Characters in Identifiers All 63 18 73 85 32 86 The software fails to adequately filter user-controlled input for alternate script syntax. Resolve all filtered input to absolute or canonical representations before processing. Carefully check each input parameter against a rigorous positive specification (white list) defining the specific characters and format allowed. All input should be sanitized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended. This involves "HTML Entity Encoding" all non-alphanumeric characters from data that was received from the user and is now being written to the request. With Struts, you should write all data from form beans with the bean's filter attribute set to true. Additionally, to help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as Internet Explorer), this attribute prevents the user's session cookie from being accessed by client-side scripts, including scripts inserted due to a XSS attack. CVE-2002-0738 XSS using "&={script}". 1000 Weakness ChildOf 79 Alternate XSS syntax All The software does not sufficiently delimit the arguments being passed to a component in another control sphere, allowing alternate arguments to be provided, leading to potentially security-relevant changes. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) System Process Avoid using user-controlled input in command arguments. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. CVE-1999-0113 Canonical Example CVE-2001-0150 CVE-2001-0667 CVE-2002-0985 CVE-2003-0907 CVE-2004-0121 CVE-2004-0473 CVE-2004-0480 CVE-2004-0489 CVE-2004-0411 CVE-2005-4699 Argument injection vulnerability in TellMe 1.2 and earlier allows remote attackers to modify command line arguments for the Whois program and obtain sensitive information via "--" style options in the q_Host parameter. CVE-2006-1865 Beagle before 0.2.5 can produce certain insecure command lines to launch external helper applications while indexing, which allows attackers to execute arbitrary commands. NOTE: it is not immediately clear whether this issue involves argument injection, shell metacharacters, or other issues. CVE-2006-2056 Argument injection vulnerability in Internet Explorer 6 for Windows XP SP2 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API. CVE-2006-2057 Argument injection vulnerability in Mozilla Firefox 1.0.6 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API. CVE-2006-2058 Argument injection vulnerability in Avant Browser 10.1 Build 17 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API. CVE-2006-2312 Argument injection vulnerability in the URI handler in Skype 2.0.*.104 and 2.5.*.0 through 2.5.*.78 for Windows allows remote authorized attackers to download arbitrary files via a URL that contains certain command-line switches. CVE-2006-3015 Argument injection vulnerability in WinSCP 3.8.1 build 328 allows remote attackers to upload or download arbitrary files via encoded spaces and double-quote characters in a scp or sftp URI. CVE-2006-4692 Argument injection vulnerability in the Windows Object Packager (packager.exe) in Microsoft Windows XP SP1 and SP2 and Server 2003 SP1 and earlier allows remote user-assisted attackers to execute arbitrary commands via a crafted file with a "/" (slash) character in the filename of the Command Line property, followed by a valid file extension, which causes the command before the slash to be executed, aka "Object Packager Dialogue Spoofing Vulnerability." CVE-2006-6597 Argument injection vulnerability in HyperAccess 8.4 allows user-assisted remote attackers to execute arbitrary vbscript and commands via the /r option in a telnet:// URI, which is configured to use hawin32.exe. CVE-2007-0882 Argument injection vulnerability in the telnet daemon (in.telnetd) in Solaris 10 and 11 (SunOS 5.10 and 5.11) misinterprets certain client "-f" sequences as valid requests for the login program to skip authentication, which allows remote attackers to log into certain accounts, as demonstrated by the bin account. At one layer of abstraction, this can overlap other weaknesses that have whitespace problems, e.g. injection of javascript into attributes of HTML tags. Fault: unquoted special characters, input restriction error, unquoted special terms, whitespace Steven Christey Argument injection issues http://www.securityfocus.com/archive/1/archive/1/460089/100/100/threaded 1000 Weakness ChildOf 74 631 Category ChildOf 634 Argument Injection or Modification All 88 41 The application fails to adequately filter SQL syntax from user-controllable input. This can lead to such input being interpreted as SQL rather than ordinary user data and be executed as part of a dynamically generated SQL query. This is a specific form of an injection problem, one that explicitly affects SQL databases, in which SQL commands are injected into data-plane input in order to effect the execution of dynamically generated SQL statements. Very High Confidentiality: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities. Authentication: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password. Authorization: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability. Integrity: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL injection attack. Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen. Design: Follow the principle of least privilege when creating user accounts to a SQL database. Users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data. Design: Duplicate any filtering done on the client-side on the server side. Implementation: Implement SQL strings using prepared statements that bind variables. Prepared statements that do not bind variables can be vulnerable to attack. Implementation: Use vigorous white-list style checking on any user input that may be used in a SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that have been entered in the database may neglect to escape meta-characters before use. Narrowly define the set of safe characters based on the expected value of the parameter in the request. The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user. C# The query that this code intends to execute follows: SELECT * FROM items WHERE owner = <userName> AND itemname = <itemName>; However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following: SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a'; The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query: SELECT * FROM items; This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner. This example examines the effects of a different malicious value passed to the query constructed and executed in the above example. If an attacker with the user name hacker enters the string "hacker'); DELETE FROM items; --" for itemName, then the query becomes the following two queries: SQL Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database. Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [19]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a'; One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from a whitelist of safe values or identify and escape a blacklist of potentially malicious values. Whitelisting can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, blacklisting is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers can: - Target fields that are not quoted - Find ways to bypass the need for certain escaped meta-characters - Use stored procedures to hide the injected meta-characters Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks. Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. For example, the following PL/SQL procedure is vulnerable to the same SQL injection attack shown in the first example. procedure get_item ( itm_cv IN OUT ItmCurTyp, usr in varchar2, itm in varchar2) is open itm_cv for ' SELECT * FROM items WHERE ' || 'owner = '|| usr || ' AND itemname = ' || itm || '; end get_item; Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks. MS SQL has a built in function that enables shell command execution. An SQL injection in such a context could be disastrous. For example, a query of the form: Where $user_input is taken from the user and unfiltered. If the user provides the string: The query will take the following form: " Now, this query can be broken down into: [1] a first SQL query: SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='' [2] a second SQL query, which executes a shell command: exec master..xp_cmdshell 'vol' [3] an MS SQL comment: --' ORDER BY PRICE As can be seen, the malicious input changes the semantics of the query into a query, a shell command execution and a comment. CVE-2004-0366 CVE-2004-0343 CVE-2003-0779 CVE-2003-0500 CVE-2003-0377 SQL injection has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind. Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before. This flaw depends on the fact that SQL makes no real distinction between the control and data planes. If successful, SQL Injection attacks can give an attacker access to backend database contents, the ability to remotely execute system commands, or in some circumstances the means to take control of the Windows server hosting the database. Dynamically generating queries that include user input can lead to SQL injection attacks. An attacker can insert SQL commands or modifiers in the user input that can cause the query to behave in an unsafe manner. Constructing a dynamic SQL statement with user input may allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands. Factors: resultant to special character mismanagement, MAID, or blacklist/whitelist problems. Can be primary to authentication errors. M. Howard D. LeBlanc Writing Secure Code 2nd Edition Microsoft 2003 1000 Weakness ChildOf 74 629 View ChildOf 629 630 View ChildOf 630 635 View ChildOf 635 SQL injection SQL Injection SQL injection All 66 7 A weakness where the code path has: 1. start statement that accepts input 2. end statement that performs an SQL command where a. the input is part of the SQL command and b. the SQL command is undesirable Where “undesirable” is defined through the following scenarios: 1. not validated 2. incorrectly validated If elevated access rights are assigned to EJB methods, then an attacker can take advantage of the permissions to exploit the software system. Follow the principle of least privilege when assigning access rights to EJB methods. Permission to invoke EJB methods should not be granted to the ANYONE role. The following deployment descriptor grants ANYONE permission to invoke the Employee EJB's method named getSalary(). ... ANYONE Employee getSalary ... ]]> If the EJB deployment descriptor contains one or more method permissions that grant access to the special ANYONE role, it indicates that access control for the application has not been fully thought through or that the application is structured in such a way that reasonable access control restrictions are impossible. 1000 Category ChildOf 4 1000 Category ChildOf 275 J2EE Misconfiguration: Weak Access Permissions The software does not sufficiently sanitize special elements that are used in LDAP queries or responses, allowing attackers to modify the syntax, contents, or commands of the LDAP query before it is executed. Assume all input is malicious. Use an appropriate combination of black lists and white lists to filter or quote LDAP syntax from user-controlled input. Factors: resultant to special character mismanagement, MAID, or blacklist/whitelist problems. Can be primary to authentication and verification errors. Under-reported. This is likely found very frequently by third party code auditors, but there are very few publicly reported examples. SPI Dynamics Web Applications and LDAP Injection 1000 Weakness ChildOf 74 629 View ChildOf 629 LDAP injection All The software does not properly filter or quote special characters or reserved words that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. In vulnerability theory terms, this is a representation-specific case of a Data/Directive Boundary Error. Under-reported. This is likely found regularly by third party code auditors, but there are very few publicly reported examples. Amit Klein Blind XPath Injection 2004-05-19 http://www.modsecurity.org/archive/amit/blind-xpath-injection.pdf 1000 Weakness ChildOf 74 629 View ChildOf 629 XML injection (aka Blind Xpath injection) All 83 The software does not properly filter or quote special characters or reserved words that are used in a custom or proprietary language or representation that is used by the product, allowing attackers to modify the syntax, content, or commands before they are processed by an end system. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Assume all input is malicious. Use an appropriate combination of black lists and white lists to appropriately filter or quote custom special characters or reserved words in user-controlled input. CVE-2001-0677 Read arbitrary files from mail client by providing a special MIME header that is internally used to store pathnames for attachments. CVE-2000-0703 Setuid program does not cleanse special escape sequence before sending data to a mail program, causing the mail program to process those sequences CVE-2003-0020 Multi-channel issue. Terminal escape sequences not filtered from log files. CVE-2003-0083 Multi-channel issue. Terminal escape sequences not filtered from log files. Factors: can be primary to interaction errors. Under-studied. It is likely that these issues are fairly common in applications that use their own custom format for configuration files, logs, meta-data, messaging, etc. They would only be found by accident or with a focused effort based on an understanding of the format. 1000 Weakness ChildOf 74 Custom Special Character Injection All 81 93 The software uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not properly sanitize CRLF sequences from inputs. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Avoid using CRLF as a special sequence. Appropriately filter or quote CRLF sequences in user-controlled input. CVE-2002-1771 CRLF injection enables spam proxy (add mail headers) using email address or name. CVE-2002-1783 CRLF injection in API function arguments modify headers for outgoing requests. CVE-2004-1513 Spoofed entries in web server log file via carriage returns CVE-2006-4624 Chain: inject fake log entries with fake timestamps using CRLF injection CVE-2005-1951 Chain: Application accepts CRLF in an object ID, allowing HTTP response splitting. CVE-2004-1687 Chain: HTTP response splitting via CRLF in parameter related to URL. Factors: primary to HTTP Response Splitting. Probably under-studied, although gaining more prominence in 2005 as a result of interest in HTTP response splitting. Ulf Harnhammar CRLF Injection Bugtraq 2002-05-07 http://cert.uni-stuttgart.de/archive/bugtraq/2002/05/msg00079.html 1000 Weakness ChildOf 74 1000 Weakness CanPrecede 117 629 View ChildOf 629 CRLF Injection All 81 15 The product does not sufficiently filter code (control-plane) syntax from user-controlled input (data plane) when that input is used within code that the product generates. Implementation: Utilize an appropriate mix of whitelist and blacklist parsing to filter non-relevant code syntax from all input that should not contain code. Run time: Run time policy enforcement may be used in a whitelist fashion to prevent execution of any non-sanctioned code. Assign permissions to the software system that prevent the user from accessing/opening privileged files. Many of these weaknesses are under-studied, and terminology is not sufficiently precise. 1000 Weakness ChildOf 74 1000 Weakness ChildOf 691 635 View ChildOf 635 (CODE) Code Evaluation and Injection All 35 77 The software allows user-controlled input to be fed directly into a function (e.g. "eval") that dynamically evaluates and executes the input as code, usually in the same interpreted language that the product uses. Direct Dynamic Code Evaluation is prevalent in handler/dispatch procedures that might want to invoke a large number of functions, or set a large number of variables. Direct code injection Medium Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Refactor your code so that it does not need to use eval() at all. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. edit-config.pl: This CGI script is used to modify settings in a configuration file. The script intends to take the 'action' parameter and invoke one of a variety of functions based on the value of that parameter - config_file_add_key(), config_file_set_key(), or config_file_delete_key(). It could set up a conditional to invoke each function separately, but eval() is a powerful way of doing the same thing in fewer lines of code, especially when a large number of functions or variables are involved. Unfortunately, in this case, the attacker can provide other values in the action parameter, such as: add_key(",","); system("/bin/ls"); This would produce the following string in handleConfigAction(): config_file_add_key(",","); system("/bin/ls"); Any arbitrary Perl code could be added after the attacker has "closed off" the construction of the original function call, in order to prevent parsing errors from causing the malicious eval() to fail before the attacker's payload is activated. This particular manipulation would fail after the system() call, because the "_key(\$fname, \$key, \$val)" portion of the string would cause an error, but this is irrelevant to the attack because the payload has already been activated. CVE-2002-1750 Direct code injection into Perl eval function. CVE-2002-1751 Direct code injection into Perl eval function. CVE-2002-1752 Direct code injection into Perl eval function. CVE-2002-1753 Direct code injection into Perl eval function. CVE-2005-1527 Direct code injection into Perl eval function. CVE-2005-2837 Direct code injection into Perl eval function. CVE-2005-1921 MFV. code injection into PHP eval statement using nested constructs that should not be nested. CVE-2005-2498 MFV. code injection into PHP eval statement using nested constructs that should not be nested. CVE-2005-3302 Code injection into Python eval statement from a field in a formatted file. CVE-2001-1471 Resultant eval injection. An invalid value prevents initialization of variables, which can be modified by attacker and later injected into PHP eval statement. This issue is probably under-reported. Most relevant CVEs have been for Perl and PHP, but eval injection applies to most interpreted languages. Javascript eval injection is likely to be heavily under-reported. This vulnerability is applicable to any interpreted language Factors: special character errors can play a role in increasing the variety of code that can be injected, although some vulnerabilities do not require special characters at all, e.g. when a single function without arguments can be referenced and a terminator character is not necessary. 1000 Weakness ChildOf 94 629 View ChildOf 629 Direct Dynamic Code Evaluation ('Eval Injection') Java Javascript Python Perl PHP 35 The software allows user-controlled input to be fed directly into an output file that is later processed as code, such as a library file or template. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) File/Directory Assume all input is malicious. Use an appropriate combination of black lists and white lists to filter code syntax from user-controlled input. Avoid writing user-controlled input to code files. Perform output validation to filter all code syntax from data written to non-code files. CVE-2002-0495 Perl code directly injected into CGI library file from parameters to another CGI program. CVE-2005-1876 Direct PHP code injection into supporting template file. CVE-2005-1894 Direct code injection into PHP script that can be accessed by attacker. CVE-2003-0395 PHP code from User-Agent HTTP header directly inserted into log file implemented as PHP script. "HTML injection" (see XSS) could be thought of as an example of this, but it is executed on the client side, not the server side. Server-Side Includes (SSI) are an example of direct static code injection. This issue is most frequently found in PHP applications that allow users to set configuration variables that are stored within executable php files. Technically, this could also be performed in some compiled code (e.g. by byte-patching an executable), although it is highly unlikely. 1000 Weakness ChildOf 94 631 Category ChildOf 632 Direct Static Code Injection PHP Perl All Interpreted Languages 35 81 63 18 73 85 86 77 The software fails to adequately filter server-side include (control-plane) syntax from user-controlled input (data plane) and then allows potentially injected server-side includes to be acted upon. Implementation: Utilize an appropriate mix of white-list and black-list parsing to filter server-side include syntax from all input. This can be resultant from XSS/HTML injection because the same special characters can be involved. However, this is server-side code execution, not client-side. 1000 Weakness ChildOf 96 Server-Side Includes (SSI) Injection All 35 101 The software allows user-controlled input to control resource identifiers. This may enable an attacker to access or modify otherwise protected system resources. High Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. The following Java code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files. Java The following code uses input from the command line to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can create soft links to the file, they can use the program to read the first part of any file on the system. C++ > s; cout << s;]]> The kind of resource the data affects indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash, are risky when used in methods that interact with the file system. (Resource injection, when it is related to file system resources, sometimes goes by the name "path manipulation.") Similarly, data that contains URLs and URIs is risky for functions that create remote connections. A resource injection issue occurs when the following two conditions are met: 1. An attacker can specify the identifier used to access a system resource. For example, an attacker might be able to specify part of the name of a file to be opened or a port number to be used. 2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted. For example, the program may give the attacker the ability to overwrite the specified file, run with a configuration controlled by the attacker, or transmit sensitive information to a third-party server. Note: Resource injection that involves resources stored on the filesystem goes by the name path manipulation and is reported in separate category. See the path manipulation description for further details of this vulnerability. 1000 Weakness ChildOf 74 1000 Weakness CanAlsoBe 73 630 View ChildOf 630 Resource Injection All 10 75 A weakness where the code path has: 1. start statement that accepts input followed by 2. a statement that allocates a System Resource where the input is part of the name of the System Resource 3. end statement that accesses the System Resource where a. the System Resource is protected and b. the name of the System Resource violates protection A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold or when a program attempts to put data in a memory area past a buffer. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers. Some prominent vendors and researchers use the term "buffer overrun," but most people use "buffer overflow." Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported. Memory Management High to Very High Resultant (Weakness is typically related to the presence of some other weaknesses) Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Memory Availability: Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop. Access control (instruction processing): Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service. Pre-design: Use a language or compiler that performs automatic bounds checking. Design: Use an abstraction library to abstract away risky APIs. Not a complete solution. Design: Use the <strsafe.h> library. This library has buffer overflow safe functions that will help with the detection of buffer overflows. Pre-design through Build: Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution. Implementation: Programmers should adhere to the following rules when allocating and managing their applications memory: Double check that your buffer is as large as you specify. When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string. Check buffer boundaries if calling this function in a loop and make sure you are not in danger of writing past the allocated space. Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions Operational: Use OS-level preventative functionality. Not a complete solution. CVE-2000-1094 buffer overflow using command with long argument CVE-1999-0046 buffer overflow in local program using long environment variable CVE-2002-1337 buffer overflow in comment characters, when product increments a counter for a ">" but does not decrement for "<" CVE-2003-0595 - By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers. CVE-2001-0191 - By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers. At the programmer level, stack-based and heap-based overflows do not differ significantly, so they are not distinguished here. Obviously, from the exploit perspective using shellcode, they can be quite different. Buffer overflows are one of the best known types of security problem. The best solution is enforced run-time bounds checking of array access, but many C/C++ programmers assume this is too costly or do not have the technology available to them. Even this problem only addresses failures in access control -- as an out-of-bounds access is still an exception condition and can lead to an availability problem if not addressed. Some platforms are introducing mitigating technologies at the compiler or OS level. All such technologies to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is more common to make the workload of an attacker much higher -- for example, by leaving the attacker to guess an unknown value that changes every program execution. 1000 Weakness ChildOf 119 1000 Weakness Requires 227 1000 Weakness Requires 242 1000 Weakness CanPrecede 123 631 Category ChildOf 633 1000 680 Compound_Element CanPrecede 680 Unbounded Transfer ('classic overflow') Buffer Overflow Buffer overflow C C++ Implementation 100 10 14 42 24 8 9 45 46 47 92 67 A weakness where the code path includes a Buffer Write Operation such that: 1. the expected size of the buffer is greater than the actual size of the buffer where expected size is equal to the sum of the size of the data item and the position in the buffer Where Buffer Write Operation is a statement that writes a data item of a certain size into a buffer at a certain position and at a certain index The use of IP addresses as authentication is flawed and can easily be spoofed by malicious users. High Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Authentication: Malicious users can fake authentication information, impersonating any IP address. Design: Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate. C C++ Java As IP addresses can be easily spoofed, they do not constitute a valid authentication mechanism. Alternate methods should be used if significant authentication is necessary. 1000 Weakness ChildOf 290 1000 Weakness Requires 348 1000 Weakness Requires 471 1000 Weakness PeerOf 292 1000 Weakness PeerOf 293 Trusting self-reported IP address All Architecture and Design 4 The web product does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request. Note: CSRF is multi-channel: 1. Attacker-to-victim (injection; external or internal channel) 2. Victim-to-server (activation; internal channel) Session Riding Cross Site Reference Forgery XSRF CVE-2004-1703 CVE-2004-1995 CVE-2004-1967 CVE-2004-1842 CVE-2005-1947 CVE-2005-2059 CVE-2005-1674 CSRF Could be resultant from XSS, although XSS is not necessarily required. Peter W Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images) Bugtraq http://marc.info/?l=bugtraq&m=99263135911884&w=2 Robert Auger CSRF - The Cross-Site Request Forgery (CSRF/XSRF) FAQ http://www.cgisecurity.com/articles/csrf-faq.shtml 1000 Weakness ChildOf 345 1000 Weakness Requires 346 1000 Weakness Requires 441 1000 Weakness Requires 642 1000 Weakness Requires 613 629 View ChildOf 629 635 View ChildOf 635 Cross-Site Request Forgery (CSRF) All Architecture and Design 62 Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions. Such a scenario is commonly observed when: 1. A web application authenticates a user without first invalidating the existing session, thereby continuing to use the session already associated with the user 2. An attacker is able to force a known session identifier on a user so that, once the user authenticates, the attacker has access to the authenticated session 3. The application or container uses predictable session identifiers. In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to associate, and possibly authenticate, against the server using that session identifier, giving the attacker access to the user's account through the active session. Invalidate any existing session identifiers prior to authorizing a new user session For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again. The following example shows a snippet of code from a J2EE web application where the application authenticates users with LoginContext.login() without first calling HttpSession.invalidate(). Java In order to exploit the code above, an attacker could first create a session (perhaps by logging into the application) from a public terminal, record the session identifier assigned by the application, and reset the browser to the login page. Next, a victim sits down at the same public terminal, notices the browser open to the login page of the site, and enters credentials to authenticate against the application. The code responsible for authenticating the victim continues to use the pre-existing session identifier, now the attacker simply uses the session identifier recorded earlier to access the victim's active session, providing nearly unrestricted access to the victim's account for the lifetime of the session. Even given a vulnerable application, the success of the specific attack described here is dependent on several factors working in the favor of the attacker: access to an unmonitored public terminal, the ability to keep the compromised session active and a victim interested in logging into the vulnerable application on the public terminal. In most circumstances, the first two challenges are surmountable given a sufficient investment of time. Finding a victim who is both using a public terminal and interested in logging into the vulnerable application is possible as well, so long as the site is reasonably popular. The less well known the site is, the lower the odds of an interested victim using the public terminal and the lower the chance of success for the attack vector described above. The biggest challenge an attacker faces in exploiting session fixation vulnerabilities is inducing victims to authenticate against the vulnerable application using a session identifier known to the attacker. In the example above, the attacker did this through a direct method that is not subtle and does not scale suitably for attacks involving less well-known web sites. However, do not be lulled into complacency; attackers have many tools in their belts that help bypass the limitations of this attack vector. The most common technique employed by attackers involves taking advantage of cross-site scripting or HTTP response splitting vulnerabilities in the target site [12]. By tricking the victim into submitting a malicious request to a vulnerable application that reflects JavaScript or other code back to the victim's browser, an attacker can create a cookie that will cause the victim to reuse a session identifier controlled by the attacker. It is worth noting that cookies are often tied to the top level domain associated with a given URL. If multiple applications reside on the same top level domain, such as bank.example.com and recipes.example.com, a vulnerability in one application can allow an attacker to set a cookie with a fixed session identifier that will be used in all interactions with any application on the domain example.com [29]. The following example shows a snippet of code from a J2EE web application where the application authenticates users with a direct post to the <code>j_security_check</code>, which typically does not invalidate the existing session before processing the login request. ]]> Other attack vectors include DNS poisoning and related network based attacks where an attacker causes the user to visit a malicious site by redirecting a request for a valid site. Network based attacks typically involve a physical presence on the victim's network or control of a compromised machine on the network, which makes them harder to exploit remotely, but their significance should not be overlooked. Less secure session management mechanisms, such as the default implementation in Apache Tomcat, allow session identifiers normally expected in a cookie to be specified on the URL as well, which enables an attacker to cause a victim to use a fixed session identifier simply by emailing a malicious URL. 1000 Category ChildOf 361 1000 Weakness ChildOf 287 1000 Weakness Requires 346 1000 Weakness Requires 472 1000 Weakness Requires 441 Session Fixation All 21 39 31 60 59 61 If a function performs automatic path searching for resources and an attacker can influence that path, then the attacker may be able to redirect the search path to point to resources under the control of the attacker. Untrusted Path Program invocation, code libraries. High System Process Authorization: There is the potential for arbitrary code execution with privileges of the vulnerable program. Implementation: Use other functions which require explicit paths. Making use of any of the other readily available functions which require explicit paths is a safe way to avoid this problem. CVE-1999-1120 Application relies on its PATH environment variable to find and execute program. CVE-2002-0470 Application relies on its PATH environment variable to find and execute program. CVE-2007-2027 Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages. Search path issues on Windows are under-studied and possibly under-reported. 1000 Category ChildOf 417 1000 Weakness ChildOf 673 1000 Weakness Requires 216 1000 Category Requires 275 1000 Weakness Requires 471 631 Category ChildOf 634 Untrusted Search Path Relative path library search All 38 The software allows the attacker to upload or transfer files of dangerous types that can be automatically processed within the product's environment. Formerly called "File Upload of Dangerous Type" File/Directory Determine the size and type of files that users are expected to upload to your system. Take measures to assure that the files meet those requirements. CVE-2001-0901 Web-based mail product stores ".shtml" attachments that could contain SSI CVE-2002-1841 PHP upload does not restrict file types CVE-2005-1868 upload and execution of .php file CVE-2005-1881 upload file with dangerous extension CVE-2005-0254 program does not restrict file types CVE-2004-2262 improper type checking of uploaded files CVE-2006-4558 Double "php" extension leaves an active php extension in the generated filename. CVE-2006-6994 ASP program allows upload of .asp files by bypassing client-side checks http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2006-6994 CVE-2005-3288 ASP file upload http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2005-3288 CVE-2006-2428 ASP file upload http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2006-2428 This can have a chaining relationship with incomplete blacklist / permissive whitelist errors when the product tries, but fails, to properly limit which types of files are allowed. This can also overlap multiple interpretation errors for intermediaries, e.g. anti-virus products that do not filter attachments with certain file extensions that can be processed by client systems. This can be primary when there is no check at all. If is frequently resultant when use of double extensions (e.g. ".php.gif") bypass sanity checks. Also resultant from client-side enforcement; some products will include web script in web clients to check the filename, without verifying on the server side. PHP applications are most targeted, but this likely applies to other languages that support file upload, as well as non-web technologies. ASP applications have also demonstrated this problem. Richard Stanway (r1CH) Dynamic File Uploads, Security and You http://shsc.info/FileUploadSecurity 1000 Category ChildOf 429 1000 Weakness ChildOf 669 1000 Weakness Requires 351 1000 Weakness Requires 436 1000 Weakness PeerOf 184 1000 Weakness PeerOf 183 1000 Weakness PeerOf 216 1000 Weakness PeerOf 436 1000 Weakness PeerOf 430 629 View ChildOf 629 631 Category ChildOf 632 Unrestricted File Upload All A software system that allows UNIX symbolic links (symlink) as part of paths whether in internal code or through user input can allow an attacker to spoof the symbolic link and traverse the file system to unintended locations or access arbitrary files. The symbolic link can permit an attacker to read/write/corrupt a file that they originally did not have permissions to access. Symlink following, symlink vulnerability. High to Very High Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files. Follow the principle of least privilege when assigning access rights to files. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted. CVE-1999-1386 CVE-2000-0972 CVE-2000-1178 CVE-2004-0217 CVE-2003-0517 CVE-2004-0689 Possible interesting example CVE-2005-1879 Second-order symlink vulns CVE-2005-1880 Second-order symlink vulns CVE-2005-1916 Symlink in Python program CVE-2000-0972 Setuid product allows file reading by replacing a file being edited with a symlink to the targeted file, leaking the result in error messages when parsing fails. CVE-2005-0824 Signal causes a dump that follows symlinks. Fault: filename predictability, insecure directory permissions, non-atomic operations, race condition. These are typically reported for temporary files or privileged programs. Symlink vulnerabilities are regularly found in C and shell programs, but all programming languages can have this problem. "Second-order symlink vulnerabilities" may exist in programs that invoke other programs that follow symlinks. They are rarely reported but are likely to be fairly common when process invocation is used. Reference: [Christey2005] Steve Christey Second-Order Symlink Vulnerabilities Bugtraq 2005-06-07 http://www.securityfocus.com/archive/1/401682 Shaun Colley Crafting Symlinks for Fun and Profit Infosec Writers Text Library 2004-04-12 http://www.infosecwriters.com/texts.php?op=display&id=159 1000 Category ChildOf 60 1000 Weakness Requires 362 1000 Weakness Requires 340 1000 Weakness Requires 216 1000 Weakness Requires 386 1000 Category Requires 275 UNIX symbolic link following All 27 The product performs a calculation to determine how much memory to allocate, but an integer overflow can occur that causes less memory to be allocated than expected, leading to a buffer overflow. Validity 1000 Weakness ChildOf 20 All The product, while copying or cloning a resource, does not set the resource's permissions or access control until the copy is complete, leaving the resource exposed to other spheres while the copy is taking place. Primary (Weakness exists independent of other weaknesses) CVE-2002-0760 Archive extractor decompresses files with world-readable permissions, then later sets permissions to what the archive specified. CVE-2005-2174 Product inserts a new object into database before setting the object's permissions, introducing a race condition. CVE-2006-5214 error file has weak permissions before a chmod is performed. CVE-2005-2475 Archive permissions issue using hard link. CVE-2003-0265 database product creates files world-writable before initializing the setuid bits, leading to modification of executables. This is a general issue, although few subtypes are currently known. The most common examples occur in file archive extraction, in which the product begins the extraction with insecure default permissions, then only sets the final permissions (as specified in the archive) once the copy is complete. The larger the archive, the larger the timing window for the race condition. This weakness has also occurred in some operating system utilities that perform copies of deeply nested directories containing a large number of files. Under-studied. It seems likely that this weakness could occur in any situation in which a complex or large copy operation occurs, when the resource can be made available to other spheres as soon as it is created, but before its initialization is complete. 1000 Category ChildOf 275 1000 Weakness Requires 362 1000 Weakness Requires 276 1000 Weakness Requires 668 C Perl Implementation The product does not check for an error after calling a function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference. While unchecked return value weaknesses are not limited to returns of NULL pointers (see the examples in CWE-252), functions often return NULL to indicate an error status. When this error condition is not checked, a NULL pointer dereference can occur. Validity Black box: This typically occurs in rarely-triggered error conditions, reducing the chances of detection during black box testing. White box: Code analysis can require knowledge of API behaviors for library functions that might return NULL, reducing the chances of detection when unknown libraries are used. CVE-2008-1052 Large Content-Length value leads to NULL pointer dereference when malloc fails. CVE-2006-6227 Large message length field leads to NULL pointer dereference when malloc fails. CVE-2006-2555 Parsing routine encounters NULL dereference when input is missing a colon separator. CVE-2003-1054 URI parsing API sets argument to NULL when a parsing failure occurs, such as when the Referer header is missing a hostname, leading to NULL dereference. A typical occurrence of this weakness occurs when an application includes user-controlled input to a malloc() call. The related code might be correct with respect to preventing buffer overflows, but if a large value is provided, the malloc() will fail due to insufficient memory. This problem also frequently occurs when a parsing routine expects that certain elements will always be present. If malformed input is provided, the parser might return NULL. For example, strtok() can return NULL. 1000 Weakness ChildOf 20 C C++ The product uses a blacklist-based protection mechanism to defend against XSS attacks, but the blacklist is incomplete, allowing XSS variants to succeed. Validity CVE-2007-5727 Blacklist only removes <SCRIPT> tag. CVE-2006-3617 Blacklist only removes <SCRIPT> tag. CVE-2006-4308 Blacklist only checks "javascript:" tag While XSS might seem simple to prevent, web browsers vary so widely in how they parse web pages, that a blacklist cannot keep track of all the variations. The "XSS Cheat Sheet" (see references) contains a large number of attacks that are intended to bypass incomplete blacklists. S. Christey Blacklist defenses as a breeding ground for vulnerability variants February 2006 http://seclists.org/fulldisclosure/2006/Feb/0040.html 1000 Weakness ChildOf 20 C C++ The software allows user-controlled data to be directly processed by the PHP interpreter before inclusion in the script through use of "require," "include," or similar statements. PHP remote file inclusion File/Directory Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. CVE-2004-0285 Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request. CVE-2004-0030 Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request. CVE-2004-0068 Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request. CVE-2005-2157 Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request. CVE-2005-2162 Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request. CVE-2005-2198 Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request. CVE-2004-0128 Modification of assumed-immutable variable in configuration script leads to file inclusion. CVE-2005-1864 PHP file inclusion. CVE-2005-1869 PHP file inclusion. CVE-2005-1870 PHP file inclusion. CVE-2005-2154 PHP local file inclusion. CVE-2002-1704 PHP remote file include. CVE-2002-1707 PHP remote file include. CVE-2005-1964 PHP remote file include. CVE-2005-1681 PHP remote file include. CVE-2005-2086 PHP remote file include. CVE-2004-0127 Directory traversal vulnerability in PHP include statement. CVE-2005-1971 Directory traversal vulnerability in PHP include statement. CVE-2005-3335 PHP file inclusion issue, both remote and local; local include uses ".." and "%00" characters as a manipulation, but many remote file inclusion issues probably have this vector. This is frequently a functional consequence of other weaknesses. It is usually multi-factor with other factors (e.g. MAID), although not all inclusion bugs involve assumed-immutable data. Direct request weaknesses frequently play a role. Can overlap directory traversal in local inclusion problems. Other interpreted languages with "require" and "include" functionality could also product vulnerable applications, but as of 2007, PHP has been the focus. Shaun Clowes A Study in Scarlet http://www.cgisecurity.com/lib/studyinscarlet.txt 1000 Weakness ChildOf 94 1000 Compound_Element CanAlsoBe 426 1000 Weakness Requires 456 1000 Weakness Requires 473 1000 Weakness Requires 425 1000 Weakness Requires 216 629 View ChildOf 629 631 Category ChildOf 632 PHP File Include PHP