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: <1093260526.6693.7.camel@Gibson>
From: barrie at reboot-robot.net (Barrie Dempster)
Subject: Unsecure file permission of ZoneAlarm pro.
	(ZA will fail to load)

On Sun, 2004-08-22 at 20:11, bipin gautam wrote:

> Not really, I've discoverd a NTFS feature (BUG?).
> well... If you have system/administrative privilages
> in a disk.... you can read/modify a file even though
> it has "EVERYONE: DENY" permission set.

This is neither a feature nor a bug of NTFS because, as you have stated
you are not using NTFS at all but reading from the disk directly, this
always has been possible on any non-encrypted filesystem. the super user
has direct hardware access on most OS's (Windows and Linux at least) so
they can directly manipulate the hardware this is why things like custom
TCP/IP stacks work, they override the OS's mechanisms, because the OS is
designed to let you have that control.

IMO if  the super user could NOT bring back a file with those severely
restricted permissions, then _that_ would be the bug as it would be a
trivially exploited DoS attack.

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/60b02133/attachment.bin