CWE-385 – Covert Timing Channel

Read Time:39 Second

Description

Covert timing channels convey information by modulating some aspect of system behavior over time, so that the program receiving the information can observe system behavior and infer protected information.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-514

 

Consequences

Confidentiality, Other: Read Application Data, Other

Information exposure.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Whenever possible, specify implementation strategies that do not introduce time variances in operations.

Phase: Implementation

Description: 

Often one can artificially manipulate the time which operations take or — when operations occur — can remove information from the attacker.

Phase: Implementation

Description: 

It is reasonable to add artificial or random delays so that the amount of CPU time consumed is independent of the action being taken by the application.

CVE References

CWE-384 – Session Fixation

Read Time:44 Second

Description

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.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-610
CWE-610
CWE-346
CWE-472
CWE-441

 

Consequences

Access Control: Gain Privileges or Assume Identity

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Invalidate any existing session identifiers prior to authorizing a new user session.

Phase: Architecture and Design

Description: 

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.

CVE References

CWE-383 – J2EE Bad Practices: Direct Use of Threads

Read Time:37 Second

Description

Thread management in a Web application is forbidden in some circumstances and is always highly error prone.

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.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-695

 

Consequences

Other: Quality Degradation

 

Potential Mitigations

Phase: Architecture and Design

Description: 

For EJB, use framework approaches for parallel execution, instead of using threads.

CVE References

CWE-382 – J2EE Bad Practices: Use of System.exit()

Read Time:49 Second

Description

A J2EE application uses System.exit(), which also shuts down its container.

It is never a good idea for a web application to attempt to shut down the application container. Access to a function that can shut down the application is an avenue for Denial of Service (DoS) attacks.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-705

 

Consequences

Availability: DoS: Crash, Exit, or Restart

 

Potential Mitigations

Phase: Architecture and Design

Description: 

The shutdown function should be a privileged function available only to a properly authorized administrative user

Phase: Implementation

Description: 

Web applications should not call methods that cause the virtual machine to exit, such as System.exit()

Phase: Implementation

Description: 

Web applications should also not throw any Throwables to the application server as this may adversely affect the container.

Phase: Implementation

Description: 

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

CVE References

CWE-38 – Path Traversal: ‘absolutepathnamehere’

Read Time:55 Second

Description

A software system that accepts input in the form of a backslash absolute path (‘absolutepathnamehere’) without appropriate validation can allow an attacker to traverse the file system to unintended locations or access arbitrary files.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-36

 

Consequences

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

 

Potential Mitigations

Phase: Implementation

Effectiveness: High

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

  • CVE-1999-1263
    • Mail client allows remote attackers to overwrite arbitrary files via an e-mail message containing a uuencoded attachment that specifies the full pathname for the file to be modified.
  • CVE-2003-0753
    • Remote attackers can read arbitrary files via a full pathname to the target file in config parameter.
  • CVE-2002-1525
    • Remote attackers can read arbitrary files via an absolute pathname.

CWE-379 – Creation of Temporary File in Directory with Insecure Permissions

Read Time:1 Minute, 8 Second

Description

The software creates a temporary file in a directory whose permissions allow unintended actors to determine the file’s existence or otherwise access that file.

On some operating systems, the fact that the temporary file exists may be apparent to any user with sufficient privileges to access that directory. Since the file is visible, the application that is using the temporary 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.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-377

 

Consequences

Confidentiality: Read Application Data

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

Phase: Requirements

Description: 

Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible.

Phase: Implementation

Description: 

Try to store sensitive tempfiles in a directory which is not world readable — i.e., per-user directories.

Phase: Implementation

Description: 

Avoid using vulnerable temp file functions.

CVE References

CWE-378 – Creation of Temporary File With Insecure Permissions

Read Time:1 Minute, 15 Second

Description

Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-377

 

Consequences

Confidentiality: Read Application Data

If the temporary file can be read by the attacker, sensitive information may be in that file which could be revealed.

Authorization, Other: Other

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.

Integrity, Other: Other

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.

 

Potential Mitigations

Phase: Requirements

Description: 

Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible.

Phase: Implementation

Description: 

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 that owns the file.

Phase: Implementation

Description: 

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.

CVE References

CWE-375 – Returning a Mutable Object to an Untrusted Caller

Read Time:50 Second

Description

Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.

In situations where functions return references to mutable data, it is possible that the external code which called the function may make changes to the data sent. If this data was not previously cloned, the class will then be using modified data which may violate assumptions about its internal state.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-668

 

Consequences

Access Control, Integrity: Modify Memory

Potentially data could be tampered with by another function which should not have been tampered with.

 

Potential Mitigations

Phase: Implementation

Description: 

Declare returned data which should not be altered as constant or immutable.

Phase: Implementation

Description: 

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.

CVE References

CWE-374 – Passing Mutable Objects to an Untrusted Method

Read Time:54 Second

Description

The program sends non-cloned mutable data as an argument to a method or function.

The function or method that has been called can alter or delete the mutable data. This could violate assumptions that the calling function has made about its state. In situations where unknown code is called with references to mutable data, this external code could make changes to the data sent. If this data was not previously cloned, the modified data might not be valid in the context of execution.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-668

 

Consequences

Integrity: Modify Memory

Potentially data could be tampered with by another function which should not have been tampered with.

 

Potential Mitigations

Phase: Implementation

Description: 

Pass in data which should not be altered as constant or immutable.

Phase: Implementation

Description: 

Clone all mutable data before passing it into an external function . 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.

CVE References