Hack The Gibson - Episode #66

Read the reason for these posts. Read Steve Gibson's response.

This again will be a short one. Steve talks about Vista which I have no immediate experience with (I've seen it on some decent machines and all that I can say is that it's reeeeeeeeeeeeally slow. really, really, really slow. Event without the Aero interface).

Now for some fun (although it isn't so funny when you think about how many people listen to the podcast and get erroneous information): BitLocker and booting from an USB device has nothing in common even though Steve implies this. And TPM (the Trusted Platform Module) is not (just) a pre-boot technology. The external USB device is needed (if you don't have a TPM) to store the encryption key (similar to the way you can setup TrueCrypt). And the TPM is basically (there are of course some details like validating the BIOS before running it) a secure place to store stuff. An encrypted memory.

Now about the topic of Patchguard, Kernel patching & co.:

Even though Steve implies the contrary, there are many documented functions to create firewalls (TDI drivers, NDIS drivers, Filter Hook drivers and the Windows Filtering platform which again is just an evolutionary step, not a revolutionary one as Steve implies and you certainly don't have to wait for Vista to write a driver which uses well documented standardized APIs) and AV products (by using File System Filters and Registry Filters).

In my opinion most of the people participating in this debate are coming at it from the wrong way. No offense to anyone, but to understand the whole picture and to be able to make a fair decision you must know at least some details about the inner workings of the Windows kernel. I'll try to explain it here as simple as possible, but again, to make up your own mind it's necessary to have read the Windows Internals or an equivalent book. So here goes my version:

In programming there are certain linkage points between components which are written by different groups (think different companies here, like Microsoft and other companies who produce software that runs on Windows). These are called API and are well documented. Their advantage is that the one who is offering it is (or should be) commited to them, meaning that in future version they will work the same way (so that third party software can continue to work without modification). This also means that bugs will be fixed in it. An other advantage (this time from the point of view of the one offering it) is that s/he can change the inner workings of the software, as long as the effects of the APIs remain the same. This is the ideal world.

Now for the real life: sometimes programmers find the available APIs insufficient. This can have multiple causes: (a) the developer doesn't know about all the available APIs (ignorance) (b) the developer is trying to do something that breaks some assumption the system is built on or (c) there is truly no API for this. In this situation the developer might reverse-engineer the system s/he is developing against and try to modify (patch it) such a way that s/he is able to accomplish her/his goal. The are many, many problems with this approach: (a) it reduces system stability - there are many steps one must take to create a reliable patch and if one is missed, the stability of the system is in danger. (b) they are not guaranteed to work in every condition. because reverse-engineering includes most of the time a fair amount of black-box testing and because you never actually spoke to the original implementers of the code, you can never be sure that you covered all the possible situations. (c) they can be broken at any update of the system. because the original vendor doesn't know about this patch, there is no way it can guarantee that a future updated version is not going to break it.

The actual debate is about the fact that some vendors said that the current API is insufficient, but did not say what other APIs they would need (most probably because there is a documented API almost for anything including for notification when a process is created). They created products which rely on patchwork, even though this puts the customer at risk and now that they have to get their act together are whining. Or they created some dubious HIPS product which is pretty much useless. So no, Vista won't contain less security, it will contain more security. Even though some companies brag that they bypassed the patchguard, I'm sure that Microsoft will modify it so that they mechanism gets invalidated. Would you like to buy a product which stops working for a couple of days randomly after security updates (until the the given company catches up - it they do)?