VIEW SLICE: CWE-677: Weakness Base Elements
(Draft 9)
View ID
| Status: Draft 677 (View) | | Objective | This view (slice) displays only weakness base elements. | | View Data | Filter Used: .//@Weakness_Abstraction='Base' | CWEs in this view | | Total CWEs |
|---|
| Total | 276 | out of | 695 | | Views | 0 | out of | 14 | | Categories | 0 | out of | 64 | | Weaknesses | 276 | out of | 605 | | Compound_Elements | 0 | out of | 12 |
|
View Components View Components A |
B |
C |
D |
E |
F |
G |
H |
I |
J |
K |
L |
M |
N |
O |
P |
Q |
R |
S |
T |
U |
V |
W |
X |
Y |
Z
Weakness ID
| Status: Draft 36 (Weakness Base) | | Description | Summary The software, when constructing
file or directory names from input, does not properly
sanitize absolute path sequences such as "/path/here." | | Potential Mitigations | see "Path Traversal" (CWE-22) | | Relationships | | | Source Taxonomies | PLOVER - Absolute Path Traversal | | Applicable Platforms | All |
Weakness ID
| Status: Draft 349 (Weakness Base) | | Description | Summary 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. | | Observed Examples | | Reference | Description |
|---|
| CVE-2002-0018 | Does not verify that trusted entity is authoritative for all entities in its
response. |
| | Relationships | | | Source Taxonomies | PLOVER - Untrusted Data Appended with Trusted Data | | Applicable Platforms | All | | Related Attack Patterns | | CAPEC-ID | Attack Pattern Name |
|---|
| 75 | Manipulating Writeable Configuration Files |
|
Weakness ID
| Status: Incomplete 464 (Weakness Base) | | Description | Summary The accidental addition of a data-structure sentinel can cause serious programming logic
problems. | | Likelihood of Exploit | High to Very High | | Common Consequences | Availability: Generally this error will cause the data structure to not work
properly by truncating the data. | | Potential Mitigations | 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. | Demonstrative Examples | C/C++ Example: char *foo; foo=malloc(sizeof(char)*4); foo[0]='a'; foo[1]='a'; foo[2]=0; foo[3]='c'; printf("%c %c %c %c %c \n",foo[0],foo[1],foo[2],foo[3]); printf("%s\n",foo); | | Context Notes | 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. | | Relationships | | | Source Taxonomies | CLASP - Addition of data-structure sentinel | | Applicable Platforms | C C++ |
Weakness ID
| Status: Incomplete 407 (Weakness Base) | | Description | Summary 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. | | Common Consequences | The typical consequence is CPU consumption, but memory consumption
and consumption of other resources can also occur. | | Observed Examples | | Reference | Description |
|---|
| 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. |
| | Context Notes | Similar issues can occur in cryptography. | | References | | | Relationships | | | Source Taxonomies | PLOVER - Algorithmic Complexity | | Applicable Platforms | All |
Weakness ID
| Status: Draft 88 (Weakness Base) | | Description | Summary 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. | | Weakness Ordinality | Primary (Weakness exists independent of other weaknesses) | | Causal Nature | Explicit (This is an explicit weakness resulting from behavior of the developer) | | Affected Resource | System Process | | Potential Mitigations | 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. | | Observed Examples | | Reference | Description |
|---|
| 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. |
| | Context Notes | 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 | | References | | | Relationships | | | Source Taxonomies | PLOVER - Argument Injection or Modification | | Applicable Platforms | All | | Related Attack Patterns | | CAPEC-ID | Attack Pattern Name |
|---|
| 88 | OS Command Injection | | 41 | Using Meta-characters in E-mail Headers to Inject Malicious Payloads |
|
Weakness ID
| Status: Draft 587 (Weakness Base) | | Description | Summary The software sets a pointer to a specific address other than NULL or 0. Extended Description If the pointer is set to a specific address, that address will probably not be valid in all environments or platforms. | | Weakness Ordinality | Primary (Weakness exists independent of other weaknesses) | | Potential Mitigations | Implementation: Never set a pointer to a fixed address. | Demonstrative Examples | C Example: int (*pt2Function) (float, char, char)=0x08040000; int result2 = (*pt2Function) (12, 'a', 'b'); // Here we can inject code to execute. | | Context Notes | 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. | | Relationships | | | Applicable Platforms | C C++ C# Assembly |
Weakness ID
| Status: Incomplete 294 (Weakness Base) | | Description | Summary 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). | | Likelihood of Exploit | High | | Common Consequences | Authorization: Messages sent with a capture-relay attack allow access to
resources which are not otherwise accessible without proper
authentication. | | Potential Mitigations | 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. | Demonstrative Examples | C/C++ Example: unsigned char *simple_digest(char *alg,char *buf,unsigned int len, int *olen) { const EVP_MD *m; EVP_MD_CTX ctx; unsigned char *ret; OpenSSL_add_all_digests(); if (!(m = EVP_get_digestbyname(alg))) return NULL; if (!(ret = (unsigned char*)malloc(EVP_MAX_MD_SIZE))) return NULL; EVP_DigestInit(&ctx, m); EVP_DigestUpdate(&ctx,buf,len); EVP_DigestFinal(&ctx,ret,olen); return ret; } unsigned char *generate_password_and_cmd(char *password_and_cmd) { simple_digest("sha1",password,strlen(password_and_cmd) ...); } Java Example: String command = new String("some cmd to execute & the password") MessageDigest encer = MessageDigest.getInstance("SHA"); encer.update(command.getBytes("UTF-8")); byte[] digest = encer.digest(); | | Context Notes | 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. | | Relationships | | | Source Taxonomies | PLOVER - Authentication bypass by replay CLASP - Capture-replay | | Applicable Platforms | All | | Time of Introduction | Architecture and Design | | Related Attack Patterns | | CAPEC-ID | Attack Pattern Name |
|---|
| 94 | Man in the Middle Attack | | 60 | Reusing Session IDs (aka Session Replay) |
|
Weakness ID
| Status: Draft 305 (Weakness Base) | | Description | Summary 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. | | Observed Examples | | | Context Notes | Most "authentication bypass" errors are resultant, not primary. | | Relationships | | | Source Taxonomies | PLOVER - Authentication Bypass by Primary Weakness | | Applicable Platforms | All |
Weakness ID
| Status: Incomplete 290 (Weakness Base) | | Description | Summary Weaknesses in this attack-focused category are caused by improperly implemented
authentication schemes that are subject to spoofing attacks. | | Context Notes | Resultant vuln from insufficient verification. | | Relationships | | | Source Taxonomies | PLOVER - Authentication bypass by spoofing | | Related Attack Patterns | | CAPEC-ID | Attack Pattern Name |
|---|
| 21 | Exploitation of Session Variables, Resource IDs and other Trusted Credentials | | 22 | Exploiting Trust in Client (aka Make the Client Invisible) | | 94 | Man in the Middle Attack | | 60 | Reusing Session IDs (aka Session Replay) | | 59 | Session Credential Falsification through Prediction |
|
Weakness ID
| Status: Draft 439 (Weakness Base) | | Description | Summary A's behavior or functionality changes with a new version of A, or a new environment,
which is not known (or manageable) by B. | | Alternate Terms | Functional change | | Observed Examples | | Reference | Description |
|---|
| 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. |
| | Relationships | | | Source Taxonomies | PLOVER - CHANGE Behavioral Change | | Applicable Platforms | All |
Weakness ID
| Status: Incomplete 205 (Weakness Base) | | Description | Summary 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. | | Potential Mitigations | 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. | | Relationships | | | Source Taxonomies | PLOVER - Behavioral Discrepancy Infoleak | | Applicable Platforms | All |
Weakness ID
| Status: Incomplete 124 (Weakness Base) | | Description | Summary 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. | | Alternate Terms | 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). | | Likelihood of Exploit | Medium | | Weakness Ordinality | Primary (Weakness exists independent of other weaknesses) | | Causal Nature | Explicit (This is an explicit weakness resulting from behavior of the developer) | | Common Consequences | 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. | | Potential Mitigations | 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. | Demonstrative Examples | 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 Example: int main() { ... strncpy(destBuf, &srcBuf[find(srcBuf, ch)], 1024); ... } If the index to srcBuf is somehow under user control, this is an arbitrary
write-what-where condition. | | Observed Examples | | Reference | Description |
|---|
| CVE-2002-2227 | Unchecked length of SSLv2 challenge value leads to buffer underflow. | | CVE-2007-4580 | Buffer underflow from a small size value with a large buffer (length parameter
inconsistency, CWE-130) | | 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. | | CVE-2007-0886 | Buffer underflow resultant from encoded data that triggers an integer overflow. | | CVE-2006-6171 | Product sets an incorrect buffer size limit, leading to "off-by-two" buffer
underflow. | | CVE-2006-4024 | Negative value is used in a memcpy() operation, leading to buffer underflow. | | CVE-2004-2620 | Buffer underflow due to mishandled special characters |
| | Context Notes | 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). | | Research Gaps | 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. | | References | | | Relationships | | | Source Taxonomies | PLOVER - UNDER - Boundary beginning violation ('buffer underflow'
?) CLASP - Buffer underwrite | | Applicable Platforms | C C++ | | Time of Introduction | Implementation |
Weakness ID
| Status: Draft 182 (Weakness Base) | | Description | Summary Software cleanses or filters data in a way that causes the data to "collapse" into an
unsafe value. | | Potential Mitigations | 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). | | Observed Examples | | Reference | Description |
|---|
| 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 "../". |
| | Context Notes | Overlaps regular expressions, although an implementation might not necessarily use
regexp's. | | Relationships | | | Source Taxonomies | PLOVER - Collapse of Data into Unsafe Value | | Applicable Platforms | All | | Time of Introduction | Architecture and Design Implementation |
Weakness ID
| Status: Draft 14 (Weakness Base) | | Description | Summary 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." | | Affected Resource | Memory | | Potential Mitigations | Overwrite sensitive data in memory prior to clearing. Where possible, encrypt sensitive data that are used by a software
system. | Demonstrative Examples | 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(). void GetData(char *MFAddr) { char pwd[64]; if (GetPasswordFromUser(pwd, sizeof(pwd))) { if (ConnectToMainframe(MFAddr, pwd)) { // Interaction with mainframe } } memset(pwd, 0, sizeof(pwd)); } 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. | | Context Notes | 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. | | References | | | Relationships | | | Source Taxonomies | 7 Pernicious Kingdoms - Insecure Compiler Optimization PLOVER - Sensitive memory uncleared by compiler optimization | | Applicable Platforms | .NET |
Weakness ID
| Status: Draft 368 (Weakness Base) | | Description | Summary 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. | | Observed Examples | | Reference | Description |
|---|
| 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. |
| | Context Notes | 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. | | Research Gaps | Under-studied as a concept. Frequency unknown; few vulnerability reports give enough
detail to know when a context switching race condition is a factor. | | Relationships | | | Source Taxonomies | PLOVER - Context Switching Race Condition | | Applicable Platforms | All | | Related Attack Patterns | | CAPEC-ID | Attack Pattern Name |
|---|
| 26 | Leveraging Race Conditions | | 29 | Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions |
|
Weakness ID
| Status: Incomplete 515 (Weakness Base) | | Description | Summary 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. | | Likelihood of Exploit | High | | Common Consequences | Confidentiality: Covert storage channels may provide attackers with important
information about the system in question. | | Potential Mitigations | Implementation: Ensure that all reserved fields are set to zero before messages are
sent and that no unnecessary information is included. | Demonstrative Examples | 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. | | Context Notes | 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. | | Relationships | | | Source Taxonomies | Landwehr - Storage CLASP - Covert storage channel |
Weakness ID
| Status: Incomplete 385 (Weakness Base) | | Description | Summary 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. | | Likelihood of Exploit | Medium | | Common Consequences | Confidentiality: Information leakage. | | Potential Mitigations | 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. | Demonstrative Examples | Python Example: def validate_password(actual_pw, typed_pw): if len(actual_pw) <> 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. | | Context Notes | 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. | | Relationships | | | Source Taxonomies | Landwehr - Timing CLASP - Covert Timing Channel | | Applicable Platforms | All |
Weakness ID
| Status: Incomplete 379 (Weakness Base) | | Description | Summary On some operating systems, the fact that the temp file exists may be apparent to any
user. | | Likelihood of Exploit | Low | | Common Consequences | 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. | | Potential Mitigations | 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. | Demonstrative Examples | C/C++ Example: FILE *stream; char tempstring[] = "String to be written"; if( (stream = tmpfile()) == NULL ) { perror("Could not open new temporary file\n"); return (-1); } /* write data to tmp file */ /* ... */ _rmtmp(); In cygwin and some older unixes one can ls /tmp and see that this temp
file exists. Java Example: try { File temp = File.createTempFile("pattern", ".suffix"); temp.deleteOnExit(); BufferedWriter out = new BufferedWriter(new FileWriter(temp)); out.write("aString"); out.close(); } catch (IOException e) { } This temp file is readable by all users. | | Context Notes | 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. | | Relationships | | | Source Taxonomies | CLASP - Guessed or visible temporary file | | Applicable Platforms | All |
Weakness ID
| Status: Draft 378 (Weakness Base) | | Description | Summary Opening temporary files without appropriate measures or controls can leave the file, its
contents and any function that it impacts vulnerable to attack. | | Likelihood of Exploit | High | | Common Consequences | 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. | | Potential Mitigations | 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. | Demonstrative Examples | C/C++ Example: FILE *stream; char tempstring[] = "String to be written"; if( (stream = tmpfile()) == NULL ) { perror("Could not open new temporary file\n"); return (-1); } /* write data to tmp file */ /* ... */ _rmtmp(); The temp file created in the above code is always readable and writable
by all users. Java Example: try { File temp = File.createTempFile("pattern", ".suffix"); temp.deleteOnExit(); BufferedWriter out = new BufferedWriter(new FileWriter(temp)); out.write("aString"); out.close(); } catch (IOException e) { } This temp file is readable by all users. | | Context Notes | 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. | | Relationships | | | Source Taxonomies | CLASP - Improper temp file opening | | Applicable Platforms | All |
Weakness ID
| Status: Incomplete 212 (Weakness Base) | | Description | Summary 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. | | Potential Mitigations | 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. |
|