Security: October 2006 Archives

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.

False Senses of Security

| | Comments (0)

The other day someone asked me a question about Vista that I honestly wasn't prepared to answer.  I thought it bears repeating and discussing here, because it cuts to the heart of a lot of what has been surrounding the reasons for upgrading to Vista in the first place:

"If Vista is inherently more secure than older versions of Windows, why do I need to bother with products like Windows Defender -- or for that matter, any third party antivirus or antispyware product?"

I thought about that one for a minute.  The fellow asking was someone I would call a moderately experienced user, someone who doesn't always follow the absolute latest trends in everything, but that made the question all the more intriguing.  Think about Mac OS X, for instance -- viruses and spyware as we know them in Windows are essentially nonexistent in OS X.  So if Windows is (theoretically) headed in the same direction, isn't stuff like Windows Defender -- and, presumably, future iterations of third-party products like that-- a waste?

The one answer I came up with doesn't seem entirely satisfactory.  For one, it's possible to turn off some of Vista's protections against privilege escalation, so someone might want to spend the money (or invest the time) in obtaining something that grants them an extra level of protection in case they make a mistake.  (It's fortunately not a trivial action to turn those things off, nor is it recommended.)  Also, these changes may not protect against things like buffer overflow attacks (which Unix-derived OSes are also vulnerable to).  The sum total of my counter-argument was that it's not possible to always foresee every possible attack.  Vista does a good deal of "minimizing the attack surface" of the OS -- to use a phrase I personally can't stand -- but it can't take everything into account.  I still felt like I was ducking the issue in some way, though -- if only because I was downplaying the importance of personal responsibility.  You cannot make a thoughtless user any less thoughtless by habitually protecting them from the consequences of their ignorance.

This connects with the recent controversies involving Mcafee and Symantec's demands that Vista's innards be opened up to third party security developers in the same way XP was.  The street-level comebacks about this whole row (from places like Digg) are mostly in the vein of snarking at Mcafee and Symantec for writing such lousy programs in the first place: Now that Microsoft is actually making a secure OS, the other guys are whining that they're being put out of a job.  Microsoft's stance is that they bent over backwards to allow third-party developers to write their own security products for Vista, and while I'm curious to see how this plays out I'm tentatively siding with them on this one, as the technical details have been kind of skimpy.

My personal feeling is that good computer practices and safe surfing habits (and a browser that isn't a porous membrane for spyware) will keep you safe from the vast majority of stuff out there.  And a firewall never hurts, either, but personal awareness and responsibility are paramount.

About this Archive

This page is a archive of entries in the Security category from October 2006.

Security: December 2006 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Pages

Powered by Movable Type 4.2rc3-en