Daily Archives: May 26, 2022

CWE

CWE-587 – Assignment of a Fixed Address to a Pointer

Read Time:44 Second

Description

The software sets a pointer to a specific address other than NULL or 0.

Using a fixed address is not portable, because that address will probably not be valid in all environments or platforms.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-344
CWE-758

 

Consequences

Integrity, Confidentiality, Availability: Execute Unauthorized Code or Commands

If one executes code at a known location, an attacker might be able to inject code there beforehand.

Availability: DoS: Crash, Exit, or Restart, Reduce Maintainability, Reduce Reliability

If the code is ported to another platform or environment, the pointer is likely to be invalid and cause a crash.

Confidentiality, Integrity: Read Memory, Modify Memory

The data at a known pointer location can be easily read or influenced by an attacker.

 

Potential Mitigations

Phase: Implementation

Description: 

Never set a pointer to a fixed address.

CVE References

CWE

CWE-586 – Explicit Call to Finalize()

Read Time:36 Second

Description

The software makes an explicit call to the finalize() method from outside the finalizer.

While the Java Language Specification allows an object’s finalize() method to be called from outside the finalizer, doing so is usually a bad idea. For example, calling finalize() explicitly means that finalize() will be called more than once: the first time will be the explicit call and the last time will be the call that is made after the object is garbage collected.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-1076

 

Consequences

Integrity, Other: Unexpected State, Quality Degradation

 

Potential Mitigations

Phase: Implementation, Testing

Description: 

Do not make explicit calls to finalize(). Use static analysis tools to spot such instances.

CVE References

CWE

CWE-585 – Empty Synchronized Block

Read Time:50 Second

Description

The software contains an empty synchronized block.

An empty synchronized block does not actually accomplish any synchronization and may indicate a troubled section of code. An empty synchronized block can occur because code no longer needed within the synchronized block is commented out without removing the synchronized block.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-1071

 

Consequences

Other: Other

An empty synchronized block will wait until nobody else is using the synchronizer being specified. While this may be part of the desired behavior, because you haven’t protected the subsequent code by placing it inside the synchronized block, nothing is stopping somebody else from modifying whatever it was you were waiting for while you run the subsequent code.

 

Potential Mitigations

Phase: Implementation

Description: 

When you come across an empty synchronized statement, or a synchronized statement in which the code has been commented out, try to determine what the original intentions were and whether or not the synchronized block is still necessary.

CVE References

CWE

CWE-584 – Return Inside Finally Block

Read Time:19 Second

Description

The code has a return statement inside a finally block, which will cause any thrown exception in the try block to be discarded.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-705

 

Consequences

Other: Alter Execution Logic

 

Potential Mitigations

Phase: Implementation

Description: 

Do not use a return statement inside the finally block. The finally block should have “cleanup” code.

CVE References

CWE

CWE-583 – finalize() Method Declared Public

Read Time:37 Second

Description

The program violates secure coding principles for mobile code by declaring a finalize() method public.

A program should never call finalize explicitly, except to call super.finalize() inside an implementation of finalize(). In mobile code situations, the otherwise error prone practice of manual garbage collection can become a security threat if an attacker can maliciously invoke a finalize() method because it is declared with public access.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-668

 

Consequences

Confidentiality, Integrity, Availability: Alter Execution Logic, Execute Unauthorized Code or Commands, Modify Application Data

 

Potential Mitigations

Phase: Implementation

Description: 

If you are using finalize() as it was designed, there is no reason to declare finalize() with anything other than protected access.

CVE References

CWE

CWE-582 – Array Declared Public, Final, and Static

Read Time:1 Minute, 11 Second

Description

The program declares an array public, final, and static, which is not sufficient to prevent the array’s contents from being modified.

Because arrays are mutable objects, the final constraint requires that the array object itself be assigned only once, but makes no guarantees about the values of the array elements. Since the array is public, a malicious program can change the values stored in the array. As such, in most cases an array declared public, final and static is a bug.

Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects’ state and behavior by adversaries who have access to the same virtual machine where your program is running.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-668

 

Consequences

Integrity: Modify Application Data

 

Potential Mitigations

Phase: Implementation

Description: 

In most situations the array should be made private.

CVE References

CWE

CWE-581 – Object Model Violation: Just One of Equals and Hashcode Defined

Read Time:41 Second

Description

The software does not maintain equal hashcodes for equal objects.

Java objects are expected to obey a number of invariants related to equality. One of these invariants is that equal objects must have equal hashcodes. In other words, if a.equals(b) == true then a.hashCode() == b.hashCode().

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-573
CWE-697

 

Consequences

Integrity, Other: Other

If this invariant is not upheld, it is likely to cause trouble if objects of this class are stored in a collection. If the objects of the class in question are used as a key in a Hashtable or if they are inserted into a Map or Set, it is critical that equal objects have equal hashcodes.

 

Potential Mitigations

Phase: Implementation

Description: 

Both Equals() and Hashcode() should be defined.

CVE References

CWE

CWE-580 – clone() Method Without super.clone()

Read Time:32 Second

Description

The software contains a clone() method that does not call super.clone() to obtain the new object.

All implementations of clone() should obtain the new object by calling super.clone(). If a class does not follow this convention, a subclass’s clone() method will return an object of the wrong type.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-664
CWE-573

 

Consequences

Integrity, Other: Unexpected State, Quality Degradation

 

Potential Mitigations

Phase: Implementation

Description: 

Call super.clone() within your clone() method, when obtaining a new object.

Phase: Implementation

Description: 

In some cases, you can eliminate the clone method altogether and use copy constructors.

CVE References

CWE

CWE-58 – Path Equivalence: Windows 8.3 Filename

Read Time:59 Second

Description

The software contains a protection mechanism that restricts access to a long filename on a Windows operating system, but the software does not properly restrict access to the equivalent short “8.3” filename.

On later Windows operating systems, a file can have a “long name” and a short name that is compatible with older Windows file systems, with up to 8 characters in the filename and 3 characters for the extension. These “8.3” filenames, therefore, act as an alternate name for files with long names, so they are useful pathname equivalence manipulations.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-41

 

Consequences

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

 

Potential Mitigations

Phase: System Configuration

Description: 

Disable Windows from supporting 8.3 filenames by editing the Windows registry. Preventing 8.3 filenames will not remove previously generated 8.3 filenames.

CVE References

  • CVE-1999-0012
    • Multiple web servers allow restriction bypass using 8.3 names instead of long names
  • CVE-2005-0471
    • Multi-Factor Vulnerability. Product generates temporary filenames using long filenames, which become predictable in 8.3 format.
CWE

CWE-579 – J2EE Bad Practices: Non-serializable Object Stored in Session

Read Time:44 Second

Description

The application stores a non-serializable object as an HttpSession attribute, which can hurt reliability.

A J2EE application can make use of multiple JVMs in order to improve application reliability and performance. In order to make the multiple JVMs appear as a single application to the end user, the J2EE container can replicate an HttpSession object across multiple JVMs so that if one JVM becomes unavailable another can step in and take its place without disrupting the flow of the application. This is only possible if all session data is serializable, allowing the session to be duplicated between the JVMs.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-573

 

Consequences

Other: Quality Degradation

 

Potential Mitigations

Phase: Implementation

Description: 

In order for session replication to work, the values the application stores as attributes in the session must implement the Serializable interface.

CVE References