Linked by Thom Holwerda on Thu 5th Mar 2009 23:02 UTC
Thread beginning with comment 352007
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Address Space Randomization
by erikharmon on Fri 6th Mar 2009 23:18
in reply to "RE[4]: Address Space Randomization"
And, also, while many library offsets are randomized, the heap and stack appear not to be (http://www.matasano.com/log/986/what-weve-since-learned-about-leopa...).
I didn't think this was so bad at first because Wikipedia indicates that OS X supports the NX bit, but it appears they only do so on the stack and not the heap.




Member since:
2009-02-15
Hi Vai777,
I understand your frustration, but I won't admit to being guilty to all of your charges. When I first read the article I remembered having read some time ago that some version of Darwin introduced address space randomization. I checked Wikipedia's version history to find when that was and posted the link.
And I wasn't completely wrong. Here is from Apple about this feature in Mac OS X 10.5 (http://www.apple.com/macosx/features/300.html#security):
One of the most common security breaches occurs when a hacker’s code calls a known memory address to have a system function execute malicious code. Leopard frustrates this plan by relocating system libraries to one of several thousand possible randomly assigned addresses.
However, the Wikipedia article on ASLR, which is linked from the article I linked to and I should have read, points out that the Leopard implementation is incomplete. This was discovered by a third party; specifically (http://www.matasano.com/log/981/a-roundup-of-leopard-security-featu...):
The dynamic linker library (dyld) is not randomized. From what I can tell, ten different Leopard macs booted at ten different times will have the same offset to dyld.
And, also, while many library offsets are randomized, the heap and stack appear not to be (http://www.matasano.com/log/986/what-weve-since-learned-about-leopa...).