All posts by rocco

CWE

CWE-245 – J2EE Bad Practices: Direct Management of Connections

Read Time:30 Second

Description

The J2EE application directly manages connections, instead of using the container’s connection management facilities.

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

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-695

 

Consequences

Other: Quality Degradation

 

Potential Mitigations

CVE References

CWE

CWE-246 – J2EE Bad Practices: Direct Use of Sockets

Read Time:15 Second

Description

The J2EE application directly uses sockets instead of using framework method calls.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-695

 

Consequences

Other: Quality Degradation

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Use framework method calls instead of using sockets directly.

CVE References

CWE

CWE-248 – Uncaught Exception

Read Time:27 Second

Description

An exception is thrown from a function, but it is not caught.

When an exception is not caught, it may cause the program to crash or expose sensitive information.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-705
CWE-703
CWE-703
CWE-703

 

Consequences

Availability, Confidentiality: DoS: Crash, Exit, or Restart, Read Application Data

An uncaught exception could cause the system to be placed in a state that could lead to a crash, exposure of sensitive information or other unintended behaviors.

 

Potential Mitigations

CVE References

CWE

CWE-249 – DEPRECATED: Often Misused: Path Manipulation

Read Time:1 Minute, 18 Second

Description

This entry has been deprecated because of name
confusion and an accidental combination of multiple
weaknesses. Most of its content has been transferred to
CWE-785.

This entry was deprecated for several reasons. The primary
reason is over-loading of the “path manipulation” term and the
description. The original description for this entry was the
same as that for the “Often Misused: File System” item in the
original Seven Pernicious Kingdoms paper. However, Seven
Pernicious Kingdoms also has a “Path Manipulation” phrase that
is for external control of pathnames (CWE-73), which is a
factor in symbolic link following and path traversal, neither
of which is explicitly mentioned in 7PK. Fortify uses the
phrase “Often Misused: Path Manipulation” for a broader range
of problems, generally for issues related to buffer
management. Given the multiple conflicting uses of this term,
there is a chance that CWE users may have incorrectly mapped
to this entry.

The second reason for deprecation is an implied combination of
multiple weaknesses within buffer-handling functions. The
focus of this entry was generally on the path-conversion
functions and their association with buffer
overflows. However, some of Fortify’s Vulncat entries have the
term “path manipulation” but describe a non-overflow weakness
in which the buffer is not guaranteed to contain the entire
pathname, i.e., there is information truncation (see CWE-222
for a similar concept). A new entry for this non-overflow
weakness may be created in a future version of CWE.

Modes of Introduction:

 

 

Related Weaknesses

 

Consequences

 

Potential Mitigations

CVE References

CWE

CWE-25 – Path Traversal: ‘/../filedir’

Read Time:36 Second

Description

The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize “/../” sequences that can resolve to a location that is outside of that directory.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-23

 

Consequences

Confidentiality, Integrity: Read Files or Directories, Modify Files or Directories

 

Potential Mitigations

Phase: Implementation

Description: 

Phase: Implementation

Description: 

Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CVE References

CWE

CWE-250 – Execution with Unnecessary Privileges

Read Time:3 Minute, 50 Second

Description

The software performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-657
CWE-269

 

Consequences

Confidentiality, Integrity, Availability, Access Control: Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands, Read Application Data, DoS: Crash, Exit, or Restart

An attacker will be able to gain access to any resources that are allowed by the extra privileges. Common results include executing code, disabling services, and reading restricted data.

 

Potential Mitigations

Phase: Architecture and Design, Operation

Description: 

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phase: Architecture and Design

Description: 

Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.

Phase: Architecture and Design

Description: 

Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.

Phase: Implementation

Description: 

Perform extensive input validation for any privileged code that must be exposed to the user and reject anything that does not fit your strict requirements.

Phase: Implementation

Description: 

When dropping privileges, ensure that they have been dropped successfully to avoid CWE-273. As protection mechanisms in the environment get stronger, privilege-dropping calls may fail even if it seems like they would always succeed.

Phase: Implementation

Description: 

If circumstances force you to run with extra privileges, then determine the minimum access level necessary. First identify the different permissions that the software and its users 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 [REF-76]. Perform extensive input validation and canonicalization to minimize the chances of introducing a separate vulnerability. This mitigation is much more prone to error than dropping the privileges in the first place.

Phase: Operation, System Configuration

Description: 

Ensure that the software runs properly under the Federal Desktop Core Configuration (FDCC) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.

CVE References

  • CVE-2007-4217
    • FTP client program on a certain OS runs with setuid privileges and has a buffer overflow. Most clients do not need extra privileges, so an overflow is not a vulnerability for those clients.
  • CVE-2008-1877
    • Program runs with privileges and calls another program with the same privileges, which allows read of arbitrary files.
  • CVE-2007-5159
    • OS incorrectly installs a program with setuid privileges, allowing users to gain privileges.
  • CVE-2008-4638
    • Composite: application running with high privileges (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).
  • CVE-2008-0162
    • Program does not drop privileges before calling another program, allowing code execution.
  • CVE-2008-0368
    • setuid root program allows creation of arbitrary files through command line argument.
  • CVE-2007-3931
    • Installation script installs some programs as setuid when they shouldn’t be.
  • CVE-2020-3812
    • mail program runs as root but does not drop its privileges before attempting to access a file. Attacker can use a symlink from their home directory to a directory only readable by root, then determine whether the file exists based on the response.
CWE

CWE-252 – Unchecked Return Value

Read Time:2 Minute, 37 Second

Description

The software does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.

Two common programmer assumptions are “this function call can never fail” and “it doesn’t matter if this function call fails”. If an attacker can force the function to fail or otherwise return a value that is not expected, then the subsequent program logic could lead to a vulnerability, because the software is not in a state that the programmer assumes. For example, if the program calls a function to drop privileges but does not check the return code to ensure that privileges were successfully dropped, then the program will continue to operate with the higher privileges.

Many functions will return some value about the success of their actions. This will alert the program whether or not to handle any errors caused by that function.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-754
CWE-754
CWE-476

 

Consequences

Availability, Integrity: Unexpected State, DoS: Crash, Exit, or Restart

An unexpected return value could place the system in a state that could lead to a crash or other unintended behaviors.

 

Potential Mitigations

Phase: Implementation

Effectiveness: High

Description: 

Check the results of all functions that return a value and verify that the value is expected.

Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.

Phase: Implementation

Description: 

Ensure that you account for all possible return values from the function.

Phase: Implementation

Description: 

When designing a function, make sure you return a value or throw an exception in case of an error.

CVE References

  • CVE-2020-17533
    • Chain: unchecked return value (CWE-252) of some functions for policy enforcement leads to authorization bypass (CWE-862)
  • CVE-2020-6078
    • Chain: The return value of a function returning a pointer is not checked for success (CWE-252) resulting in the later use of an uninitialized variable (CWE-456) and a null pointer dereference (CWE-476)
  • CVE-2019-15900
    • Chain: sscanf() call is used to check if a username and group exists, but the return value of sscanf() call is not checked (CWE-252), causing an uninitialized variable to be checked (CWE-457), returning success to allow authorization bypass for executing a privileged (CWE-863).
  • CVE-2007-3798
    • Unchecked return value leads to resultant integer overflow and code execution.
  • CVE-2006-4447
    • Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
  • CVE-2006-2916
    • Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
  • CVE-2008-5183
    • chain: unchecked return value can lead to NULL dereference
  • CVE-2010-0211
    • chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824).
  • CVE-2017-6964
    • Linux-based device mapper encryption program does not check the return value of setuid and setgid allowing attackers to execute code with unintended privileges.
CWE

CWE-253 – Incorrect Check of Function Return Value

Read Time:47 Second

Description

The software incorrectly checks a return value from a function, which prevents the software from detecting errors or exceptional conditions.

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.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-573
CWE-754

 

Consequences

Availability, Integrity: Unexpected State, DoS: Crash, Exit, or Restart

An unexpected return value could place the system in a state that could lead to a crash or other unintended behaviors.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Use a language or compiler that uses exceptions and requires the catching of those exceptions.

Phase: Implementation

Description: 

Properly check all functions which return a value.

Phase: Implementation

Description: 

When designing any function make sure you return a value or throw an exception in case of an error.

CVE References

CWE

CWE-256 – Plaintext Storage of a Password

Read Time:55 Second

Description

Storing a password in plaintext may result in a system compromise.

Password management issues occur when a password is stored in plaintext in an application’s properties, configuration file, or memory. Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource. In some contexts, even storage of a plaintext password in memory is considered a security risk if the password is not cleared immediately after it is used.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-522

 

Consequences

Access Control: Gain Privileges or Assume Identity

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Avoid storing passwords in easily accessible locations.

Phase: Architecture and Design

Description: 

Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext.

Phase:

Effectiveness: None

Description: 

A programmer might 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 because the encoding can be detected and decoded easily.

CVE References