In reply to my own previous email, I assumed ZA would fail, as others have on this list, with an EVERYONE:DENY security policy, however this isn't the case. ZA 5.1 PRO Trial version will change this to EVERYONE:FULL for the duration of the program after which it will then change these settings back to the original EVERYONE:DENY. This throws out the DoS theory, but the permissions are still extremely permissive, if the "truevector driver" was to have issues with it's integrity checks then the files in this folder would be easily compromised. Since ZA can obviously access the file when they are set to EVERYONE:DENY it makes sense to leave them like that, which would be an added layer of security, you shouldn't override a security mechanism with your own if they can work together, especially if the existing mechanism doesn't conflict with yours, which in this case it obviously doesn't. Although as configuration files are in that folder, there is also an information disclosure issue to be addressed. I'm sure your clients would feel more secure in their choice of firewall product if it followed good security practise and maintained a level of least privilege, considering security as an in depth process. Consider /etc/passwd on unix, pre-shadow, this file was viewable by all and contained password hashes, but if you followed good security practise, changed the passwords regularly and made them difficult to break then this wasn't that much of an issue, however there was the chance that someone could crack a password before it's end of life, therefore it was felt prudent to hide these from the user as the user didn't _need_ to know (least privilege). This issue is very akin to that example. As a security vendor these are not new concepts to ZoneLabs, therefore they should be addressed Again apologies for my initial incorrect assumption, but the issue still stands, its unnecessarily open and requires a rethink. On Mon, 2004-08-23 at 12:28, Barrie Dempster wrote: > As for the ZA bug in particular, changing these permissions breaks ZA, > the admin could fix it and bring it back, but it would still be a DoS > and an effective ZA countermeasure for a virus. ZA, please fix this, the > people on this list complaining about it are correct, it does pose a > potential problem. > -- Barrie Dempster (zeedo) - Fortiter et Strenue http://www.bsrf.org.uk [ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ]
Attachment:
signature.asc
Description: This is a digitally signed message part