Sometimes You Can't Make Anyone Happy

I've mentioned before that the problem with being Microsoft is that you're damned if you do and you're damned if you don't.  They got flack for insecurities in Windows, and when they set to work fixed them, they started getting flack for allegedly locking out security product makers.

Not long ago a security researcher named Joanna Rutkowska demonstrated a kernel-level hack in Vista and allowed arbitrary code execution by injecting data into the pagefile.  Microsoft has apparently addressed the problem by disallowing write access to raw disk sectors for user mode applications, even when they are running in administrative mode.  This means any application that wants to do sector-level disk editing will need its own signed kernel driver (not signed by Microsoft, though, but simply signed by the ISV with a valid certificate) to do so.

There's apparently a fair amount of back-and-forthing going on in the comment sections in the above-linked post, though.  From what I've discerned, it is still possible to do sector writes in post-RC2 -- provided you're doing so on a locked or completely dismounted file system.  But direct writes are not possible on a live file system such as the system partition, and one of the problems Rutkowska flagged with this issue is how it makes things like a secure-delete tool a lot more difficult to implement.  It could still be done with a separate boot-to-CD tool, but a live secure-erase tool would probably be more difficult.

I am not a programmer, but one of the APIs mentioned that allows direct access is FSCTL_LOCK_VOLUME, and according to Microsoft's own documentation, "The NTFS file system treats a locked volume as a dismounted volume."  (This doesn't mean the volume is dismounted and remounted, just that no other disk activity can take place until the lock is released.)  If there are open files on the volume (such as an open application), or a pagefile, the lock will not work.  This has been defended (again, see the comments in the post above) by saying that arbitrary writes to an open file system can destabilize things, so it sounds like a signed kernel driver may be the only way to go.

I'll keep us posted on this.  There's always the chance this is simply a provisional measure until something more elegant is worked out.