本论坛为只读模式,仅供查阅,不能注册新用户,不能发帖/回帖,有问题可发邮件 xikug.xp (^) gmail.com
查看: 16149|回复: 17

VISTA & WIN7对直接磁盘写入的防护 [复制链接]

Rank: 5Rank: 5

发表于 2009-5-4 04:49:18 |显示全部楼层
在VISTA 和WINDOWS 7的NTFS驱动中,对直接写入磁盘分区做了限制,RING3无法直接写入"受保护"的磁盘分区

你可以尝试诸如WINHEX之类的工具,他们将无法直接对系统分区的第16个分区开始,直到磁盘分区的可用数据长度为止的位置进行写入

诸如金山文件粉碎机、磁盘级感染蠕虫之类的东西,自然也GAME OVER了

不过由于放行了前16扇区,BootSector的磁盘感染还是可以的

NTFS并不是使用IO权限来对其进行限制的,拥有高完整性Adminratrators权限的账户,可以以写权限打开NTFS卷,也可以对其调用NtWriteFile并产生IRP_MJ_WRITE的IRP,但是发送到NTFS的IRP DISPATCH后,会返回0xc0000022(STATUS_ACCESS_DENIED)

NTFS实际在NtfsWriteDispatch->NtfsCommonWrite中对其做了处理,这个函数很复杂,大约有将近2000行代码,大约在600行附近有这样的判断:

//检查如果是写入的IRP

if ( IrpMajorFunction == IRP_MJ_WRITE )
{

//检查当前卷是否被LOCK,VISTA下,如果卷的Vcb->CleanupCount > 预定值,或者已被mount上,是无法LOCK的


    if ( !FlagOn(Vcb->VcbState & VCB_STATE_LOCKED)

//检查IoStackLocation的Flags是否有0x10,这个未在MSDN或WRK中有定义, 也许可以理解为SL_WRITE_THROUGH_DISK?


      && !(IrpStack->Flags & 0x10)

//检查是否在可用数据区域之内

    && WriteByteOffset_ >= 0
   && WriteByteOffsetHigh <= Scb ->ValidDataLengthHigh)
    && (WriteByteOffsetHigh < Scb ->ValidDataLengthHigh || WriteByteOffset < Scb->ValidDataLengthLow)

//检查是否在预留扇区之内(前16个扇区可写)


      && WriteEnd >16 * Vpb->BytesPreSector) )
    {
      NtfsPreWriteReturn(v28, v9, v185, v180);
      v5 = 0xC0000022u;
       //下面完成IRP,并返回错误,

     //这里通常是调用FLTMGR的一个 Completion routine
    }

可以看到如果卷不被LOCK,而且IoStackLocation又没有特定的标记,是不允许写入指定的范围的。

VISTA和WIN7下无法在线LOCK系统卷,因此在RING3下直接写入磁盘修改系统数据应该几乎不可能了

但若有驱动则简单了:直接给IoStackLocation设上标记即可

加上VISTA和WIN7下,系统文件即使SYSTEM或高Administrators账户也无法修改,仅有TrustInstaller账户可以修改。VISTA和WIN7下想在RING3下修改系统文件,是相当困难的

这一改动,应当是为了对抗PageFile/Hiber file attack所使用的,这一点blackhat上也有提及。

另外,对于直接写入物理磁盘(\Device\Harddisk0\DRX)以及使用SCSI/ATA/IDE PassThrough指令来写入磁盘的方式

VISTA和WIN7对Partmgr进行了一些修改,实现了强大而猥琐的函数:partmgr!PmRedirectRequest->(WorkItem)PmSplitAndRedirectWrite->(PmDiskRedirect / PmPartitionRedirect)等

这些函数最后会发送Internal device io control的IRP到volmgr.sys

调用volmgr!VmpRedirectRequest去查询这个请求是否允许(volmgr内部实现了一系列IO虚拟化函数),VmpRedirectRequest最终会调用VmpIsSafeForDirectWrites函数检查这个卷设备是否允许直接写入,如果不允许,则会给这个IRP设置拒绝。

对磁盘、分区的数据直接写入进行拦截,防止修改受保护的区域的磁盘数据。

由于RING3下无论是NtDeviceIoControl还是NtWriteFile,都要走IoGetRelatedDeviceObject/IoGetAttachedDeviceObject,所以Partmgr可以捕获到这些直接磁盘写入请求,并返回拒绝访问,因此想直接写物理磁盘或者pass through指令写入磁盘的,在RING3下也行不通

Rank: 3Rank: 3

发表于 2009-5-4 09:47:42 |显示全部楼层
很好
好像某些sata一直不提供pass through,比如nv的

Rank: 4

发表于 2009-5-4 10:40:52 |显示全部楼层
//检查IoStackLocation的Flags是否有0x10,这个未在MSDN或WRK中有定义, 也许可以理解为SL_WRITE_THROUGH_DISK?


      && !(IrpStack->Flags & 0x10)
那在什么情况下系统会设置这么一位呢???

Rank: 4

发表于 2009-5-4 10:55:03 |显示全部楼层
//
// Read / Write
//

#define SL_KEY_SPECIFIED                0x01
#define SL_OVERRIDE_VERIFY_VOLUME       0x02
#define SL_WRITE_THROUGH                0x04
#define SL_FT_SEQUENTIAL_WRITE          0x08
#define SL_FORCE_DIRECT_WRITE           0x10
#define SL_REALTIME_STREAM              0x20
头文件里有申明

IrpSp->Flags
If the SL_FORCE_DIRECT_WRITE flag is set, kernel-mode drivers can write to volume areas that they normally cannot write to because of direct write blocking. Direct write blocking was implemented for security reasons in Windows Vista and later operating systems. This flag is checked both at the file system layer and storage stack layer. For more information about direct write blocking, see Blocking Direct Write Operations to Volumes and Disks. The SL_FORCE_DIRECT_WRITE flag is available in Windows Vista and later versions of Windows.

Blocking Direct Write Operations to Volumes and Disks
Some of the most compelling new features in Windows Vista are its guarantees regarding code and data integrity. To better protect Windows Vista from potentially malicious techniques, changes to the storage driver stack have been introduced to block direct write operations to volume and disk handles. If your application or driver writes directly to a volume that has a file system mounted on it, without first obtaining exclusive access to it, you could cause corruption or system instability, or both. This is because those writes might collide with other changes coming from the file system and leave the contents of the volume or file system, or both in an inconsistent state. To prevent this, we have made the following changes.

Write operations on a DASD volume handle will succeed if the file system is not mounted, or if:

The sectors being written to are the boot sectors.
The sectors being written to reside outside file system space.
The file system has been locked implicitly by requesting exclusive write access.
The file system has been locked explicitly by sending down a lock/dismount request.
The write request has been flagged by a kernel-mode driver that indicates that this check should be bypassed. The flag is called SL_FORCE_DIRECT_WRITE and it is in the IrpSp->flags field. This flag is checked by both the file system and storage drivers.


The changes that are mentioned previously will not apply if the file system on the volume is not mounted or the volume has no file system.

Write operations on a disk handle will succeed if:

The sectors being written to do not fall within a file system.
The sectors being written to fall within a mounted file system that is locked explicitly.
The sectors being written to fall within a file system that is not mounted or the volume has no file system.


In addition to the various Win32 File I/O API routines (such as WriteFile), there are device I/O control requests that can be used to issue write operations to a volume or disk. The changes mentioned previously will apply to the device I/O control requests as well. They include the following:

IOCTL_DISK_COPY_DATA
IOCTL_SCSI_PASS_THROUGH
IOCTL_SCSI_PASS_THROUGH_DIRECT
SCSIOP_WRITE6
SCSIOP_WRITE
SCSIOP_WRITE_VERIFY
SCSIOP_WRITE_SAME
SCSIOP_WRITE_LONG
SCSIOP_XDWRITE
SCSIOP_XPWRITE
SCSIOP_XDWRITE_READ
SCSIOP_WRITE12SCSIOP_WRITE_VERIFY12
SCSIOP_WRITE16
SCSIOP_WRITE_VERIFY16
SCSIOP_WRITE_SAME16
SCSIOP_WRITE_LONG16
SCSIOP_WRITE_XDWRITE_EXTENDED16
SCSIOP_WRITE_COPY
SCSIOP_WRITE_COPY_COMPARE
IOCTL_ATA_PASS_THROUGH_DIRECT
IOCTL_ATA_PASS_THROUGH
IDE_COMMAND_WRITE
IDE_COMMAND_WRITE_DMA
IDE_COMMAND_WRITE_DMA_QUEUED
IDE_COMMAND_WRITE_MULTIPLE
IDE_COMMAND_WRITE_EXT
IDE_COMMAND_WRITE_DMA_EXT
IDE_COMMAND_WRITE_DMA_FUA_EXT
IDE_COMMAND_WRITE_DMA_QUEUED_EXT
IDE_COMMAND_WRITE_DMA_QUEUED_FUA_EXT
IDE_COMMAND_WRITE_MULTIPLE_EXT
IDE_COMMAND_WRITE_MULTIPLE_FUA_EXT


The application needs to lock the volume, dismount the volume, or both, before it can issue DASD I/O. This is new to Windows Vista and was done to address potentially malicious techniques.

The file system will block all write operations to reserved sections of the disk. In this case, those reserved sections include the MBR and the two FAT areas. To block these areas, you need to lock the volume by sending FSCTL_LOCK_VOLUME. You must issue this structure on the same volume handle that performs the actual write operations. This request can fail if there are open file handles. In this case, the application can force a dismount of the file system by issuing FSCTL_DISMOUNT_VOLUME. However, the volume is not actually dismounted until the file handle is closed. Until then, the application can continue to issue DASD I/O by using the same file handle that is currently open.
There is an extended region beyond the volume space that is known to the file system where write operations will be blocked. To allow write operations to this region, you must issue FSCTL_ALLOW_EXTENDED_DASD_IO on the volume handle.


You can use the Win32 API routine DeviceIoControl to issue all the previous FSCTSs.

Rank: 4

发表于 2009-5-4 10:55:37 |显示全部楼层
看来做得很到位啊~

Rank: 4

发表于 2009-5-4 11:15:06 |显示全部楼层
再补充点东西
在 Windows Vista 和 Windows Server 2008 中对文件系统和存储堆栈进行的更改可限制对磁盘和卷的直接访问
本文介绍在 Windows Server 2008 和 Windows Vista 中对文件系统和存储堆栈所做的更改,这些更改可限制对磁盘和卷进行直接访问。
背景
当程序打开独占的文件句柄时,会假定该文件的内容无法再修改。但是,如果存在以下情况,则可以对文件的内容进行修改:
另一个程序将文件句柄打开至底层卷或底层磁盘。
程序对文件所在的位置进行了更改。
如果程序没有首先获得文件系统所安装的卷的独占访问权,而直接写入该卷,则可能会发生损坏或系统不稳定现象。这是因为卷的写入操作可能会与文件系统的写入操作发生冲突。当发生此类冲突时,卷的内容可能停留在不一致的状态。

为了降低该问题的影响,对文件系统和存储堆栈进行了更改来限制对磁盘或卷的直接访问。
对文件系统和存储堆栈所做更改的详细信息
只有存在以下情况时,文件系统才可以写入卷句柄:
情况 1:正要写入的扇区是启动扇区。

注意:这种情况是为了支持防病毒程序、安装程序以及其他必须更新系统卷启动代码的程序。无法锁定系统卷。
情况 2:正要写入的扇区位于文件系统空间外。

注意:文件系统空间末尾和卷空间末尾之间的区域不受文件系统的控制。因此,没有理由要求锁定卷以禁止对其进行写入操作。
情况 3:已经通过请求独占写入权限隐式锁定卷。
情况 4:已经通过锁定请求或卸载请求显式锁定卷。
情况 5:写入请求具有 SL_FORCE_DIRECT_WRITE 标志,该标志表示必须忽略情况 2。

注意:有些文件系统筛选器不用首先锁定卷就可以写入卷的可用空间区域。如果文件系统筛选器必须这样做,则文件系统筛选器可在写入请求上设置一个标志,通知文件系统允许执行写入行为。仅可在内核模式下设置该标志。
如果没有安装卷或卷没有文件系统,则对文件系统和存储堆栈的更改不适用。
UDFS 文件系统和 FASTFAT 文件系统限制对文件系统和存储堆栈所做的更改。这些更改限于磁盘类型的介质。

注意:大多数 CD 控制程序都能够直接写入卷,而不用首先锁定卷。某些 CD 控制程序甚至会绕过文件系统层。在这些情况下,此类程序可直接写入存储层。由于分页文件只能放在磁盘驱动器上,因此没有理由将对文件系统和存储堆栈的更改应用到光驱。
如果存在以下情况,则存储驱动器可以写入磁盘句柄:
情况 1:正要写入的扇区不位于卷内。

注意:程序使用卷之外的扇区来存储元数据。分区表也位于卷之外的扇区中。由于这些扇区不受任何文件系统的控制,因此没有理由阻止对这些扇区的访问。
情况 2:正要写入的扇区位于已显式锁定的已安装卷内。
情况 3:正要写入的扇区位于未安装或者无文件系统的卷内。
对文件系统和对存储堆栈的更改也将应用到卷的奇偶校验块。
对文件系统和存储堆栈的更改将应用到 32 位系统和 64 位系统。
除了各种 WriteFile API 之外,还有其他设备 IO 控制请求可以向卷或磁盘进行写操作。对文件系统和存储堆栈的更改也将应用到设备 IO 控制请求。设备 IO 控制请求包含以下命令:
IOCTL_DISK_COPY_DATA
IOCTL_SCSI_PASS_THROUGH
IOCTL_SCSI_PASS_THROUGH_DIRECT
SCSIOP_WRITE6
SCSIOP_WRITE
SCSIOP_WRITE_VERIFY
SCSIOP_WRITE_SAME
SCSIOP_WRITE_LONG
SCSIOP_XDWRITE
SCSIOP_XPWRITE
SCSIOP_XDWRITE_READ
SCSIOP_WRITE12
SCSIOP_WRITE_VERIFY12
SCSIOP_WRITE16
SCSIOP_WRITE_VERIFY16
SCSIOP_WRITE_SAME16
SCSIOP_WRITE_LONG16
SCSIOP_WRITE_XDWRITE_EXTENDED16
SCSIOP_WRITE_COPY
SCSIOP_WRITE_COPY_COMPARE
对于这些命令,系统将查询 LBA 位,以确定偏移是以 CHS 格式还是以 LBA 格式指定的。由于系统无法获得真正的几何数据,因此所有以 CHS 格式发送的请求都将失败。由于当前所有磁盘都是以 LBA 格式处理偏移,因此这应该不是一个问题。

因为 CDB 中仅有 16 字节,所以没有对 32 字节 SCSI 写入命令进行筛选。另外,也没有对扩展的复制命令进行筛选。对于长写入命令,传输长度是以字节为单位的。但是,所有其他命令都是以扇区为单位的。

以下命令组将会失败,因为它们已过时:
IOCTL_ATA_PASS_THROUGH
IOCTL_ATA_PASS_THROUGH_DIRECT
IDE_COMMAND_WRITE
IDE_COMMAND_WRITE_DMA
IDE_COMMAND_WRITE_DMA_QUEUED
IDE_COMMAND_WRITE_MULTIPLE
IDE_COMMAND_WRITE_EXT
IDE_COMMAND_WRITE_DMA_EXT
IDE_COMMAND_WRITE_DMA_FUA_EXT
IDE_COMMAND_WRITE_DMA_QUEUED_EXT
IDE_COMMAND_WRITE_DMA_QUEUED_FUA_EXT
IDE_COMMAND_WRITE_MULTIPLE_EXT
IDE_COMMAND_WRITE_MULTIPLE_FUA_EXT
程序兼容性问题和缓解操作
对文件系统和存储堆栈的更改可能导致某些程序失败。此类程序失败的原因是它们对磁盘或卷使用直接访问。

由于以下原因,对程序兼容性的影响将降至最低:
备份程序必须先卸载卷,然后再写入卷。否则,程序写入操作将与文件系统写入操作发生冲突。此冲突将导致损坏或系统不稳定问题。
分区程序指向卷区域之外扇区中的分区表。文件系统不对此类扇区进行控制。因为启用了对这些扇区的访问,所以分区程序不受影响。
恢复程序很可能在文件系统无法安装的卷上运行。因为启用了对 RAW 卷的访问,所以此类恢复程序不受影响。
数据块级加密程序通常有一个筛选驱动程序,该驱动程序位于分区管理器驱动程序之下的磁盘堆栈中。筛选驱动器会筛选分区管理器驱动程序发出的输入输出 (IO)。因此,对文件系统和存储堆栈的更改不会影响数据块级加密程序。如果筛选驱动器位于卷堆栈内,则筛选驱动器将位于文件系统下。因此,对文件系统和存储堆栈的更改不会影响数据块级加密程序。
CD 控制程序不受影响,因为在光驱上安装文件系统时,UDFS 文件系统和 FAT32 文件系统不执行检查。但是,在以下情况下,CD 控制程序可能会受到影响:
程序将其文件锁定。
程序查询文件的区块。
程序使用卷句柄来直接写入文件的区块。
但是,我们不鼓励这种情况,因为该情况可能导致文件元数据不同步。当文件元数据不同步时,可能会发生文件损坏。

Rank: 3Rank: 3

发表于 2009-5-4 11:27:18 |显示全部楼层
引用第5楼wowocock于2009-05-04 08:15发表的  :
再补充点东西
在 Windows Vista 和 Windows Server 2008 中对文件系统和存储堆栈进行的更改可限制对磁盘和卷的直接访问
本文介绍在 Windows Server 2008 和 Windows Vista 中对文件系统和存储堆栈所做的更改,这些更改可限制对磁盘和卷进行直接访问。
背景
当程序打开独占的文件句柄时,会假定该文件的内容无法再修改。但是,如果存在以下情况,则可以对文件的内容进行修改:
.......
不错,收藏,看来能写的都拦了~~

Rank: 1

发表于 2009-5-4 12:05:18 |显示全部楼层
用第三方驱动就行了吧

为了保护pagefile之类的,阻止写硬盘根本就不是解决方案,加密pagefile才是正道,几年前就讨论过了

Rank: 5Rank: 5

发表于 2009-5-4 15:47:47 |显示全部楼层
wowocock 的头文件比我新啊~

其实磁盘防护主要是防止了RING3下绕过文件权限和独占来访问文件,对于保护系统文件,还是比较有利的,不光是PAGEFILE

Rank: 5Rank: 5

发表于 2009-5-4 16:10:32 |显示全部楼层
MJ,问个问题:win7下TrustInstall如何产生啊?

Rank: 5Rank: 5

发表于 2009-5-4 16:18:32 |显示全部楼层
参考微软补丁。。。

Rank: 4

发表于 2009-5-4 16:36:04 |显示全部楼层
Windows Modules Installer。。。

Rank: 1

发表于 2009-5-5 12:50:33 |显示全部楼层
太强大了,学习了

Rank: 1

发表于 2009-11-3 18:49:23 |显示全部楼层
安全性越来越好了啊

Rank: 2

发表于 2009-11-4 01:09:17 |显示全部楼层
VISTA....

Rank: 1

发表于 2009-12-4 18:52:50 |显示全部楼层
非常强大,做个标记

Rank: 2

发表于 2010-1-14 15:25:41 |显示全部楼层
很好啊……

Rank: 1

发表于 2013-5-28 22:08:52 |显示全部楼层
学习了。膜拜!
您需要登录后才可以回帖 登录 | 立即加入

Archiver|手机版|第8个男人 - 论坛为只读模式,仅供查阅

GMT+8, 2019-2-22 23:27 , Processed in 0.035428 second(s), 8 queries .

Design by pvo.cn

© 2011 Pvo Inc.

回顶部