.NET and Visual Studio Elevation of Privilege Vulnerability
.NET and Visual Studio Elevation of Privilege Vulnerability
The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.
https://cwe.mitre.org/data/definitions/1220.html →Open in CWE collection →The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
https://cwe.mitre.org/data/definitions/362.html →Open in CWE collection →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.
https://capec.mitre.org/data/definitions/1.html →Open in CAPEC collection →The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
https://capec.mitre.org/data/definitions/26.html →Open in CAPEC collection →This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.
https://capec.mitre.org/data/definitions/29.html →Open in CAPEC collection →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.
https://capec.mitre.org/data/definitions/180.html →Open in CAPEC collection →| Product | Vendor | Status |
|---|---|---|
| dotnet6 | Tracked | |
| dotnet6 | Tracked | |
| dotnet6 | Tracked | |
| dotnet7 | Tracked | |
| dotnet7 | Tracked | |
| dotnet7 | Tracked | |
| .net | * | Tracked |
| visual_studio_2022 | * | Tracked |
| Windows | Microsoft | Tracked |
| Windows | Microsoft | Tracked |
| Windows | Microsoft | Tracked |
| Windows | Microsoft | Tracked |
| Windows | Microsoft | Tracked |
| Windows | Microsoft | Tracked |