Thanks for the tests, Aigle. There was extensive discussion in this thread about the implications of allowing some driver alerts to be mixed in with registry alerts:
While in theory, Defense+ has not been bypassed because one of the hundreds of registry alerts allowed the user to block the driver installs, I must make two points:
A casual user risks not understanding the exact registry entries that correspond to driver installation. Hence, this casual user, thinking the driver installation alert to be no different from the registry alert, risks allowing the activity without understanding the full consequences of such an action.
A more experienced or expert user would recognize the specific keys that correspond to driver installation alerts. However, in order to pick this alert out amongst the hundreds of other trivial ones, they would have to either carefully scrutinize every alert, thus wasting precious time, or simply click past many at once, thus allowing the driver install. Neither of these options are acceptable.
In essence, Defense+ is fine on a theoretical level, but in practice, it can be easily bypassed. Driver installation is not the same as registry modfiication. The difference is critical in both its theoretical and practical aspects, for all classes of users, new or experienced, and the implications are grave. Being able to correctly alert users to driver installations is one area in which Defense+ could and should vastly improve in the next version. An important function of a HIPS is to act as an anti rootkit. What good is it if it allows driver installs by poorly alerting the user?
Now, let’s put this problem in perspective. There are two other ways in which Defense+ can be improved in the area of preventing driver installs:
- Protected files/folders. Take a look at reply #17 (egeman’s post) in the following thread:
The topic is locked because the last post before mine was August 2008, but it is as relevant as ever. Confusing protected files/folderrs with driver installations is dangerous for the following two reasons:
a. There are many protected folder directories. Only a small handful of them pertain at all to driver installations. Therefore, relying on protecting file/folder directories to prevent the installation of drivers risks mixing in the driver installatoin alerts with the protected file/folder alerts in the same way driver installation alerts can be mixed in with registry alerts.
b. Only some methods of driver installation require the file to be in Windows\system32\drivers. Thus, methods that do not have such a requirement will not be caught by the protected file/folder method.
- Here is the final way in which Defense+ can be improved: Detect driver installation attempts even by system applications when they are invoked by COM access. This can best be seen by Egeman’s reply #17 in this post:
services.exe or svchost.exe is trying to install a driver. So what? This happens a lot, right? It is precisely because such events are so common that users need to be alerted as to WHICH file is invoking services.exe or svchost.exe. They don’t invoke themselves. The COM access is nice to have, but it does NOT eliminate the need to also alert users that services.exe or another system application is trying to install a driver.
I have said a lot in these posts. Let me sum up this entire Wishlist suggestion in a few lines:
I. On driver installations, do NOT mix in the alert with registry modifications. Separate the two so that users do not confuse trivial registry alerts with driver installs.
II. On driver installations, do NOT mix in the alert with protected files/folders alerts. There are many protected folders that do not involve driver installations, and there are many drivers that do not need a file in a specific folder to be installed. Separate driver installation alerts with protected files/folder alerts so that users do not confuse trivial protected files/folders with driver installs.
III. When an unknown application attempts to invoke a system application to load drivers, whether through COM access or by any other means, combine the invocation alert (COM access being one example) with the driver installation alert. A good example alert would be as follows:
Program xyz.exe, through protected COM Interface ABC, is attempting to use services.exe to load driver xyz.sys.
[ ] Allow this request [ ] Block this request
Implementing I, II, and III in the next version of Defense+ would give Defense+ far greater protection against driver installations, and thus the threats that are associated with rootkits. Thank you for your concern.