ID: 781 类型:变量 | 状态:草稿 |
描述
软件为了进行I/O操作而定义了一个使用METHOD_NEITHER的IOCTL,但是它却没有验证或者不正确地验证所提供的地址。
扩展描述
当IOCTL使用METHOD_NEITHER选项及进行I/O控制,IOCTL负责验证已提供给它的地址。如果验证丢失或不正确,攻击者可以提供任意内存地址,从而导致代码执行或拒绝服务。
相关视图
与“研究层面”视图(CWE-1000)相关
与“开发层面”视图(CWE-699)相关
引入模式
阶段 | 说明 |
架构与设计 | |
实现 |
应用平台
语言
C (经常出现)
C++ (经常出现)
操作系统
Windows NT (有时粗线)
后果
范围 | 冲击 | 可能性 |
完整性 | 技术冲击: 修改内存; 内存读取; 执行未获授权的代码或命令; DoS: 崩溃、退出或重启 攻击者可能能够访问属于另一个进程或用户的内存。如果攻击者能够控制ioctl写入的内容,则可能导致代码在高权限级别执行。至少,可能会发生碰撞。 |
应对措施
阶段: 实现 如果需要在IOCTL中使用NEITHER,要确保所有用户空间的地址在被访问之前已经被恰当的验证过。可以使用ProbeForRead和ProbeForWrite来完成这项任务。还要恰当的保护和管理用户提供的缓冲区,因为当使用METHOD_NEITHER 时,I/O管理器不进行这些处理。 |
阶段: 架构与设计 可能的话,避免在IOCTL中使用METHOD_NEITHER,选择能有效控制缓冲区大小的方法,例如METHOD_BUFFERED, METHOD_IN_DIRECT, or METHOD_OUT_DIRECT. |
阶段: 架构与设计; 实现 如果IOCTL仅仅被用于可信用户访问的驱动,对相关设备或者设备命名空间使用恰当的访问控制。 |
说明
应用平台
由于IOCTL功能通常执行低级操作,并与操作系统紧密交互,因此这种弱点可能只出现在用低级语言编写的代码中。
研究空白
虽然这类问题自2006年以来就已为人所知,但可能仍在研究和报告中。大部分的重点一直放在高知名度的软件和安全产品上,但其他类型的系统软件也使用驱动程序。由于开发需要开发自定义代码,因此需要一些技巧来发现这个弱点。