ZoneAlarm and DLL protection
Mark Miller over at Developer Express recently posted this interesting entry to his blog regarding DLL protection. Mark is dead right in the general sense about the risks inherent in plug-in architectures like the Visual Studio IDE, in which an otherwise trusted application can potentially load and run arbitrary code. Mark calls out Zone Alarm's application-aware firewall as a potential source of a false sense of security when it comes to this type of scenario. This was interesting to me, if course, since I used to be responsible for product architecture over at Zone Labs and even worked on the design of a feature that combats the very case about which Mark complains.
As much as I enjoy giving Mark a bad time, I can't blame him for getting this wrong because it sounds like he's talking about the free edition of Zone Alarm, whereas the paid "Pro" edition is the one that contains the protection against rogue in-process DLLs. I can, however, remind Mark that you get what you pay for. Oh, I should also mention that this feature can make for an excessively chatty personal firewall ("Are you really, really, super duper sure you trust this program?"), so it is as a result disabled by default.
For those that aren't aware, Zone Alarm Pro, and other such application-aware personal firewalls work on the concept of associating network activity with specific applications. One of the big points of distinction between personal firewalls is how well they identify an application and the state of the application. For example, a really cheesy personal firewall might identify applications simply based on the path name of the .EXE file, which makes for pretty hacker-friendly security since such a system of identification enables malware to run freely just by naming it the same as a trusted app. Better security involves doing things like checking a digital code signature on the .EXE file and comparing an MD5 and/or SHA1 hash of the binary against a database of trusted hashes. This is certainly better than a path name, but it still falls short when you consider an application is made up of more than a single .EXE file.
That's where Zone Alarm Pro's DLL protection feature comes in. With this feature enabled, when you answer "Yes" to the question of whether or not you trust an application that Zone Alarm Pro sees for the first time, you are not only asserting your trust of the application's .EXE file but also of all of the dynamic libraries loaded by that application. In subsequent runs of that application, Zone Alarm Pro will notify the user if a DLL has been changed or if new DLLs are found in the process. Of course, the tacit assumption here is that the application was in a non-corrupted state when you initially asserted your trust, but that's an issue inherent in almost all application-aware personal firewalls. And while DLL security is certainly better security technology than just looking at .EXEs, it's not necessarily more secure because it tends to raise more false alarms that its worth -- the user gets so tired of seeing the pop ups, they just start answering "Yes" to everything.
Comments
- Anonymous
August 10, 2006
Thank you for publicising this issue. I still think there's room for improvement:
> when you answer "Yes" to the question of whether or
> not you trust an application that Zone Alarm Pro sees for
> the first time, you are not only asserting your trust of the
> application's .EXE file but also of all of the dynamic
> libraries loaded by that application. [...] the tacit
> assumption here is that the application was in a non-
> corrupted state when you initially asserted your trust,
I agree with you that that assumption is pretty much unavoidable. But in fact you're also making a second assumption, and the second one is very much avoidable. When the question pops up for the first time for an .EXE that is newly being checked, it should also list the .DLLs and let the user select the individual DLLs that the user trusts. Again it pretty much has to be assumed that the DLLs are real, but the user might think "hey I didn't write that DLL myself so I deny permission".
Of course there are other ways to mitigate the danger too. For example allow Visual Studio to access ports 80 and 443 in network 207.46.. but not to access anything else. - Anonymous
August 11, 2006
The comment has been removed - Anonymous
August 11, 2006
What stops malicious code from infecting the process and then calling FreeLibrary() on itself? - Anonymous
August 11, 2006
PingBack from http://blogs.msdn.com/texblog/archive/2006/08/11/696024.aspx - Anonymous
August 11, 2006
The comment has been removed - Anonymous
August 24, 2006
I wrote recently about some of the challenges faced by personal firewalls and the state of desktop security... - Anonymous
June 19, 2009
PingBack from http://debtsolutionsnow.info/story.php?id=13284