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, 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 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