Hey TitanApe,
I somewhat agree with you but you sometimes have to take CNET articles with a grain of salt.
As of Mac OS X 10.5, both the stack and heap use the
NX bit for
ALL 64 bit processes and most of what is accessible for exploitation in 10.6 is running as 64 bit. 64 bit processes have not been exploited on 10.6 AFAIK but they have on 64 bit Linux that also uses stack and heap NX protection.
http://www.exploit-db.com/exploits/15024/(Only processes related to 32-bit emulation and compatibility are being exploited on x86_64 Linux.)
Both
ASLR and DEP were defeated on 64 bit Windows 7 at the last PWN2OWN but
DEP in Windows may be optional at the discretion of the developer as its wiki suggests.
This article outlines the issues with Windows ASLR/DEP in depth.
Full ASLR for 64 bit processes on 10.6 may not be necessary given that the 64 bit dyld file is located in the same folder as the 32 bit dyld file. The 32 bit dyld file is accessed during exploitation of 32 bit processes but 64 bit processes are not being exploited even though the file is equally accessible. (
EDIT: in remote exploitation, the dyld information is acquired via an executable located at usr/lib/dyld that equally provides information for x86 and x86_64 processes). This makes me believe that, for now, NX bit is enough to protect these processes with partial ASLR.
ASLR is necessary to help protect 32 bit processes and Apple should improve its ASLR or move everything over to 64 bit. Apple appears to be focusing on migrating over to 64 bit which is most likely the more reliable option. Apple is also working on developing a split process model for
WebKit2 (underpinnings of Safari and Mail) to help improve security as well. Split process model style of sandboxing seems effective given that Google Chrome survived PWN2OWN.
Safari was exploited at PWN2OWN via libraries from Preview. The Preview app is largely built on top of Adobe Reader which has not had the greatest security record. I believe the exploit only included arbitrary code execution but did not include privilege escalation.
Mac OS X 10.5 and 10.6 seem to be secure as neither has had a report of a remote privilege escalation exploit. Both have not had an arbitrary code execution paired with local privilege escalation as well. Either of these two conditions are typically required for viruses and worms to be installed without user intervention.