full-disclosure - Unsecure file permission of ZoneAlarm pro. (ZA will fail to load)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1093263787.6693.39.camel@Gibson>
From: barrie at reboot-robot.net (Barrie Dempster)
Subject: Unsecure file permission of ZoneAlarm pro.
	(ZA will fail to load)

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 ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040823/78d37bb4/attachment.bin