Difference between revisions of "Overflow of static internal buffer"

Jump to: navigation, search
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
[[ASDR Table of Contents]]

Revision as of 08:20, 27 February 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

Last revision (mm/dd/yy): 02/27/2009

Vulnerabilities Table of Contents


A non-final static field can be viewed and edited in dangerous ways.


  • Integrity: The object could potentially be tampered with.
  • Confidentiality: The object could potentially allow the object to be read.

Exposure period

  • Design through Implementation: This is a simple logical issue which can be easily remedied through simple protections.


  • Languages: Java, C++
  • Operating platforms: Any

Required resources




Likelihood of exploit


Non-final fields, which are not public can be read and written to by arbitrary Java code.

Risk Factors

  • Talk about the factors that make this vulnerability likely or unlikely to actually happen
  • Discuss the technical impact of a successful exploit of this vulnerability
  • Consider the likely [business impacts] of a successful attack


In C++:

public int password r = 45;

In Java:

static public String r;

This is a uninitiated static class which can be accessed without a get-accessor and changed without a set-accessor.

Related Attacks

Related Vulnerabilities

Related Controls

  • Design through Implementation: Make any static fields private and final.

Related Technical Impacts


Note: A reference to related CWE or CAPEC article should be added when exists. Eg: