Re: Unsecure file permission of ZoneAlarm pro. (ZA will fail to load)

[Barrie Dempster <barrie () reboot-robot net>]

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