When an IOCTL contains privileged functionality and is exposed unnecessarily, attackers may be able to access this functionality by invoking the IOCTL. Even if the functionality is benign, if the programmer has assumed that the IOCTL would only be accessed by a trusted process, there may be little or no validation of the incoming data, exposing weaknesses that would never be reachable if the attacker cannot call the IOCTL directly.
The implementations of IOCTLs will differ between operating system types and versions, so the methods of attack and prevention may vary widely.
| Impact | Details |
|---|---|
|
Varies by Context |
Scope: Integrity, Availability, Confidentiality
Attackers can invoke any functionality that the IOCTL offers. Depending on the functionality, the consequences may include code execution, denial-of-service, and theft of data.
|
| Phase(s) | Mitigation |
|---|---|
|
Architecture and Design |
In Windows environments, use proper access control for the associated device or device namespace. See References.
|
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. | 749 | Exposed Dangerous Method or Function |
| CanPrecede | Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. | 781 | Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code |
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | Category Category - a CWE entry that contains a set of other entries that share a common characteristic. | 1011 | Authorize Actors |
| Phase | Note |
|---|---|
| Architecture and Design | |
| Implementation | REALIZATION: This weakness is caused during implementation of an architectural security tactic. |
C (Often Prevalent)
C++ (Often Prevalent)
Class: Unix (Undetermined Prevalence)
Class: Windows (Undetermined Prevalence)
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
| Reference | Description |
|---|---|
|
Operating system does not enforce permissions on an IOCTL that can be used to modify network settings.
|
|
|
Device driver does not restrict ioctl calls to its direct rendering manager.
|
|
|
ioctl does not check for a required capability before processing certain requests.
|
|
|
Chain: insecure device permissions allows access to an IOCTL, allowing arbitrary memory to be overwritten.
|
|
|
Chain: anti-virus product uses weak permissions for a device, leading to resultant buffer overflow in an exposed IOCTL.
|
|
|
Chain: sandbox allows opening of a TTY device, enabling shell commands through an exposed ioctl.
|
|
|
Anti-virus product uses insecure security descriptor for a device driver, allowing access to a privileged IOCTL.
|
|
|
Unauthorized user can disable keyboard or mouse by directly invoking a privileged IOCTL.
|
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 1416 | Comprehensive Categorization: Resource Lifecycle Management |
Rationale
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.Comments
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.Relationship
Applicable Platform
Because IOCTL functionality is typically performing low-level actions and closely interacts with the operating system, this weakness may only appear in code that is written in low-level languages.
| Submissions | ||
|---|---|---|
| Submission Date | Submitter | Organization |
|
2009年07月15日
(CWE 1.5, 2009年07月27日) |
CWE Content Team | MITRE |
| Modifications | ||
| Modification Date | Modifier | Organization |
| 2023年10月26日 | CWE Content Team | MITRE |
| updated Common_Consequences | ||
| 2023年06月29日 | CWE Content Team | MITRE |
| updated Mapping_Notes | ||
| 2023年04月27日 | CWE Content Team | MITRE |
| updated References, Relationships | ||
| 2023年01月31日 | CWE Content Team | MITRE |
| updated Description | ||
| 2021年03月15日 | CWE Content Team | MITRE |
| updated Observed_Examples | ||
| 2020年02月24日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2017年11月08日 | CWE Content Team | MITRE |
| updated Likelihood_of_Exploit, Modes_of_Introduction, Relationships | ||
| 2009年12月28日 | CWE Content Team | MITRE |
| updated Time_of_Introduction | ||
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.