In contrast to complete vertical integration of architecting, designing, manufacturing, assembling, and testing chips all within a single organization, an organization can choose to simply architect and design a chip before outsourcing the rest of the process to OSAT entities (e.g., external foundries and test houses). In the latter example, the device enters an OSAT facility in a much more vulnerable pre-production stage where many debug and test modes are accessible. Therefore, the chipmaker must place a certain level of trust with the OSAT. To counter this, the chipmaker often requires the OSAT partner to enter into restrictive non-disclosure agreements (NDAs). Nonetheless, OSAT vendors likely have many customers, which increases the risk of accidental sharing of information. There may also be a security vulnerability in the information technology (IT) system of the OSAT facility. Alternatively, a malicious insider at the OSAT facility may carry out an insider attack. Considering these factors, it behooves the chipmaker to minimize any confidential information in the device that may be accessible to the OSAT vendor.
Logic errors during design or synthesis could misconfigure the interconnection of the debug components, which could provide improper authorization to sensitive information.
Scope | Impact | Likelihood |
---|---|---|
Confidentiality Integrity Access Control Authentication Authorization Availability Accountability Non-Repudiation | Gain Privileges or Assume Identity, Bypass Protection Mechanism, Execute Unauthorized Code or Commands, Modify Memory, Modify Files or Directories Note: The impact depends on the confidential information itself and who is inadvertently granted access. For example, if the confidential information is a key that can unlock all the parts of a generation, the impact could be severe. | Medium |
CAPEC-ID | Attack Pattern Name |
---|---|
CAPEC-1 | Accessing Functionality Not Properly Constrained by ACLs In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to. |
CAPEC-180 | Exploiting Incorrectly Configured Access Control Security Levels An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack. |
Name | Organization | Date | Date release | Version |
---|---|---|---|---|
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna | Intel Corporation | 4.2 |
Name | Organization | Date | Comment |
---|---|---|---|
CWE Content Team | MITRE | updated Related_Attack_Patterns | |
CWE Content Team | MITRE | updated Applicable_Platforms | |
CWE Content Team | MITRE | updated Applicable_Platforms | |
CWE Content Team | MITRE | updated Maintenance_Notes | |
CWE Content Team | MITRE | updated References, Relationships | |
CWE Content Team | MITRE | updated Mapping_Notes |