Category Archives: CWE

CWE

CWE-552 – Files or Directories Accessible to External Parties

Read Time:38 Second

Description

The product makes files or directories accessible to unauthorized actors, even though they should not be.

Web servers, FTP servers, and similar servers may store a set of files underneath a “root” directory that is accessible to the server’s users. Applications may store sensitive files underneath this root without also using access control to limit which users may request those files, if any. Alternately, an application might package multiple files or directories into an archive file (e.g., ZIP or tar), but the application might not exclude sensitive files that are underneath those directories.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-668
CWE-668
CWE-285

 

Consequences

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

 

Potential Mitigations

CVE References

CWE

CWE-553 – Command Shell in Externally Accessible Directory

Read Time:22 Second

Description

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.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-552

 

Consequences

Confidentiality, Integrity, Availability: Execute Unauthorized Code or Commands

 

Potential Mitigations

Phase: Installation, System Configuration

Description: 

Remove any Shells accessible under the web root folder and children directories.

CVE References

CWE

CWE-554 – ASP.NET Misconfiguration: Not Using Input Validation Framework

Read Time:16 Second

Description

The ASP.NET application does not use an input validation framework.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-1173

 

Consequences

Integrity: Unexpected State

Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

CVE References

CWE

CWE-555 – J2EE Misconfiguration: Plaintext Password in Configuration File

Read Time:28 Second

Description

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 to access the password-protected resource, making it an easy target for attackers.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-260

 

Consequences

Access Control: Bypass Protection Mechanism

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Do not hardwire passwords into your software.

Phase: Architecture and Design

Description: 

Use industry standard libraries to encrypt passwords before storage in configuration files.

CVE References

CWE

CWE-556 – ASP.NET Misconfiguration: Use of Identity Impersonation

Read Time:25 Second

Description

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.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-266

 

Consequences

Access Control: Gain Privileges or Assume Identity

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Use the least privilege principle.

CVE References

CWE

CWE-558 – Use of getlogin() in Multithreaded Application

Read Time:52 Second

Description

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.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-663

 

Consequences

Integrity, Access Control, Other: Modify Application Data, Bypass Protection Mechanism, Other

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Using names for security purposes is not advised. Names are easy to forge and can have overlapping user IDs, potentially causing confusion or impersonation.

Phase: Implementation

Description: 

Use getlogin_r() instead, which is reentrant, meaning that other processes are locked out from changing the username.

CVE References

CWE

CWE-56 – Path Equivalence: ‘filedir*’ (Wildcard)

Read Time:42 Second

Description

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.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-41
CWE-155

 

Consequences

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

 

Potential Mitigations

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-560 – Use of umask() with chmod-style Argument

Read Time:24 Second

Description

The product calls umask() with an incorrect argument that is specified as if it is an argument to chmod().

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-687

 

Consequences

Confidentiality, Integrity, Access Control: Read Files or Directories, Modify Files or Directories, Bypass Protection Mechanism

 

Potential Mitigations

Phase: Implementation

Description: 

Use umask() with the correct argument.

Phase: Testing

Description: 

If you suspect misuse of umask(), you can use grep to spot call instances of umask().

CVE References

CWE

CWE-561 – Dead Code

Read Time:51 Second

Description

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.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-1164

 

Consequences

Other: Quality Degradation

Dead code that results from code that can never be executed is an indication of problems with the source code that needs to be fixed and is an indication of poor quality.

Other: Reduce Maintainability

 

Potential Mitigations

Phase: Implementation

Description: 

Remove dead code before deploying the application.

Phase: Testing

Description: 

Use a static analysis tool to spot dead code.

CVE References

  • CVE-2014-1266
    • chain: incorrect “goto” in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple “goto fail” bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).
CWE

CWE-562 – Return of Stack Variable Address

Read Time:1 Minute, 11 Second

Description

A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.

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.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-758
CWE-672
CWE-825

 

Consequences

Availability, Integrity, Confidentiality: Read Memory, Modify Memory, Execute Unauthorized Code or Commands, DoS: Crash, Exit, or Restart

If the returned stack buffer address is dereferenced after the return, then an attacker may be able to modify or read memory, depending on how the address is used. If the address is used for reading, then the address itself may be exposed, or the contents that the address points to. If the address is used for writing, this can lead to a crash and possibly code execution.

 

Potential Mitigations

Phase: Testing

Description: 

Use static analysis tools to spot return of the address of a stack variable.

CVE References