Category Archives: CWE

CWE

CWE-573 – Improper Following of Specification by Caller

Read Time:33 Second

Description

The software does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.

When leveraging external functionality, such as an API, it is important that the caller does so in accordance with the requirements of the external functionality or else unintended behaviors may result, possibly leaving the system vulnerable to any number of exploits.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-710

 

Consequences

Other: Quality Degradation, Varies by Context

 

Potential Mitigations

CVE References

  • CVE-2006-7140
    • Crypto implementation removes padding when it shouldn’t, allowing forged signatures
  • CVE-2006-4339
    • Crypto implementation removes padding when it shouldn’t, allowing forged signatures
CWE

CWE-574 – EJB Bad Practices: Use of Synchronization Primitives

Read Time:44 Second

Description

The program violates the Enterprise JavaBeans (EJB) specification by using thread synchronization primitives.

The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the program violates the following EJB guideline: “An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.” The specification justifies this requirement in the following way: “This rule is required to ensure consistent runtime semantics because while some EJB containers may use a single JVM to execute all enterprise bean’s instances, others may distribute the instances across multiple JVMs.”

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-695
CWE-821

 

Consequences

Other: Quality Degradation

 

Potential Mitigations

Phase: Implementation

Description: 

Do not use Synchronization Primitives when writing EJBs.

CVE References

CWE

CWE-575 – EJB Bad Practices: Use of AWT Swing

Read Time:42 Second

Description

The program violates the Enterprise JavaBeans (EJB) specification by using AWT/Swing.

The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the program violates the following EJB guideline: “An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.” The specification justifies this requirement in the following way: “Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server system.”

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-695

 

Consequences

Other: Quality Degradation

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Do not use AWT/Swing when writing EJBs.

CVE References

CWE

CWE-576 – EJB Bad Practices: Use of Java I/O

Read Time:44 Second

Description

The program violates the Enterprise JavaBeans (EJB) specification by using the java.io package.

The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the program violates the following EJB guideline: “An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.” The specification justifies this requirement in the following way: “The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data.”

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-695

 

Consequences

Other: Quality Degradation

 

Potential Mitigations

Phase: Implementation

Description: 

Do not use Java I/O when writing EJBs.

CVE References

CWE

CWE-577 – EJB Bad Practices: Use of Sockets

Read Time:50 Second

Description

The program violates the Enterprise JavaBeans (EJB) specification by using sockets.

The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the program violates the following EJB guideline: “An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.” The specification justifies this requirement in the following way: “The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean– to serve the EJB clients.”

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-573

 

Consequences

Other: Quality Degradation

 

Potential Mitigations

Phase: Architecture and Design, Implementation

Description: 

Do not use Sockets when writing EJBs.

CVE References

CWE

CWE-578 – EJB Bad Practices: Use of Class Loader

Read Time:54 Second

Description

The program violates the Enterprise JavaBeans (EJB) specification by using the class loader.

The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the program violates the following EJB guideline: “The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.” The specification justifies this requirement in the following way: “These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container’s ability to properly manage the runtime environment.”

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-573

 

Consequences

Confidentiality, Integrity, Availability, Other: Execute Unauthorized Code or Commands, Varies by Context

 

Potential Mitigations

Phase: Architecture and Design, Implementation

Description: 

Do not use the Class Loader when writing EJBs.

CVE References

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

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