Mac & i: ...and we had high hopes that 10.6 would improve on ASLR. But somehow they seem to have forgotten the Dynamic Linker. In 10.5 the Execute Disable bit for the stack, which DEP depends upon on Intel processors, could even be disabled by a daring programmer with a call to mprotect - has Apple at least changed that in Snow Leopard? Can the heap and stack be considered safe in this regard?
CM: The ALSR on 10.5 is identical to that of 10.6, no improvements were made there. There are still plenty of things that are not randomised, such as the location of the dynamic linker, the comm page, and the executable itself, as well as the stack and heap. DEP for the heap has been added (for 64-bit processes) in Snow Leopard which is a big improvement. However it is still lacking for 32-bit processes such as the QuickTime and Flash browser plugins. Additionally, older Apple computers, like those before 2007, will not support 64-bit processes and so DEP for the heap will not exist in any process. Compare this to Windows where they have full ASLR (everything is randomised) and DEP.
DDZ: On just about all systems with non-executable memory, the system calls to make memory pages executable (mprotect, vm_protect, VirtualProtect, etc) are still permitted. The grsec patches for Linux can disable this behaviour and on iOS, it is prevented by code signing enforcement. What the lack of ASLR does is make it easier for attackers to find bits of code that they can reuse in order to effect a system call that makes the memory containing their shellcode executable (if it wasn't already).
Mac & i: Speaking of 64-bit support, Apple claims that, besides DEP, 64-bit technology gives it a more secure function argument-passing method and "strengthened checksums for the system heap". Are these Apple technologies, or just windfall profits from using current Intel processors or compiler versions?
CM: 64-bit does make the type of exploitation, called return oriented programming, which bypasses DEP, more difficult. But, for example, just yesterday I gave a talk at a conference in Korea that shows exactly how to do return oriented programming in 64-bit processes since the location of the dynamic linker is known. As for their heap checksums, it is much improved as well, so that is good and adds another barrier, although a small one, to exploitation.
DDZ: The fact that 64-bit code passes arguments in registers rather than on the stack simply makes ROP require more work, as Charlie has just recently demonstrated. PowerPC code also passes function arguments through registers and reliable exploitation requires ROP-like techniques to work around cache coherency issues, but this was not a serious impediment to exploitation against older Mac OS X operating systems.
The heap checksums do effectively mitigate exploitation through corrupted heap block metadata, however, application-specific data on the heap (such as C++ vtables) are a much more popular target these days and the checksums do nothing to prevent attacks against those.
Mac & i: I see – great answers, by the way. Let's talk about another mitigation technique. Apple has finally endowed Safari with canaries. Wouldn't it be sensible to compile all applications with canaries in place? We had a quick look, and iPhoto seems to be one of those apps that still doesn't use the respective compiler feature.
DDZ: Making use of the newer compiler-based protections often requires migrating a development project to a newer version of that compiler. It is common for large older projects to continue making use of an old compiler since migrating to a newer version may require significant changes in their source code (i.e. C++ STL interfaces, etc). While almost the entirety of Snow Leopard is compiled with stack canaries, there are likely a number of common 3rd-party applications still compiled with older compilers. It appears that iLife may be one of them.
CM: I think the applications with significant security risk are compiled in this way. There is not as much risk of iPhoto parsing a malicious image, as say Safari or Mail.