Exposed IOCTL with Insufficient Access Control
Weakness ID: 782 (Weakness Variant)Status: Draft
+ Description

Description Summary

The software implements an IOCTL with functionality that should be restricted, but it does not properly enforce access control for the IOCTL.

Extended Description

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.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C: (Often)

C++: (Often)

Operating Systems

UNIX-based

Windows-based

Platform Notes

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.

+ Common Consequences
ScopeEffect
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.

+ Likelihood of Exploit

Low to Medium

+ Observed Examples
ReferenceDescription
CVE-2009-2208Operating system does not enforce permissions on an IOCTL that can be used to modify network settings.
CVE-2008-3831Device driver does not restrict ioctl calls to its master.
CVE-2008-3525ioctl does not check for a required capability before processing certain requests.
CVE-2008-0322Chain: insecure device permissions allows access to an IOCTL, allowing arbitrary memory to be overwritten.
CVE-2007-4277Chain: anti-virus product uses weak permissions for a device, leading to resultant buffer overflow in an exposed IOCTL.
CVE-2007-1400Chain: sandbox allows opening of a TTY device, enabling shell commands through an exposed ioctl.
CVE-2006-4926Anti-virus product uses insecure security descriptor for a device driver, allowing access to a privileged IOCTL.
CVE-1999-0728Unauthorized user can disable keyboard or mouse by directly invoking a privileged IOCTL.
+ Potential Mitigations

Phase: Architecture and Design

In Windows environments, use proper access control for the associated device or device namespace. See References.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class284Access Control (Authorization) Issues
Development Concepts699
ChildOfWeakness BaseWeakness Base749Exposed Dangerous Method or Function
Development Concepts (primary)699
Research Concepts (primary)1000
CanPrecedeWeakness VariantWeakness Variant781Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code
Research Concepts1000
+ Relationship Notes

This can be primary to many other weaknesses when the programmer assumes that the IOCTL can only be accessed by trusted parties. For example, a program or driver might not validate incoming addresses in METHOD_NEITHER IOCTLs in Windows environments (CWE-781), which could allow buffer overflow and similar attacks to take place, even when the attacker never should have been able to access the IOCTL at all.

+ References
Microsoft. "Securing Device Objects". <http://msdn.microsoft.com/en-us/library/ms794722.aspx>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-07-15MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2009-12-28CWE Content TeamMITREInternal
updated Time of Introduction
Back to top