Apple Adds Memory Randomization To Leopard
.mack notes a ZDNet blog outlining some of the security features added to OSX Leopard (10.5). Here's Apple's brief description of all 11 new security features. "Apple has announced plans to add code-scrambling diversity to Mac OS X Leopard, a move aimed at making the operating system more resilient to virus and worm attacks. The security technology, known as ASLR (address space layout randomization), randomly arranges the positions of key data areas to prevent malware authors from predicting target addresses. Another new feature coming in Leopard is Sandboxing (systrace), which limits an application's access to the system by enforcing access policies for system calls."
Apple is finally catching up with BSD, Linux and Vista!
If only this broke bootcamp compatibility - then they'd really prevent viruses.
From the changelog:
It sounds like a high-level player finally decided to take on Exchange. My biggest questions: are there Windows programs that support these features via CalDAV, and is there a CalDAV server in FreeBSD's ports?
Dewey, what part of this looks like authorities should be involved?
Even Vista has a not-completely-broken implementation of ASLR. Linux, of course, has been doing it for years...
Everything I needed to know about life, I learnt from Blake's Seven
To give you closeted folk an excuse to talk about your feelings in public.
Dewey, what part of this looks like authorities should be involved?
Okay, so from a practical standpoint, what does this mean for pre-binding? I understand that we don't need to pre-bind ourselves on Tiger, but what about the system libraries?
Because the Macintosh is the Gay Computer.
Why bother.
ASLR or 'Address Space Layout Randomization' has seemingly been a 'feature' since Windows 3.1. You never know just *where* or *when* a blue-screen-of-death(tm) will occur. Microsoft should sue Apple for copying this 'valuable' feature :)
Ok, jokes aside, wouldn't this make debugging programs hell? If something crashes (oh wait, nothing on apple ever crashes)...crash dumps would be almost meaningless.
Or, another way of looking at this, target addresses can still be found, since the program must have some sort of debug hooks. (Unless debuggers have access to kernel protected areas)..
In other words, another kind of useless feature...Crash Different!
All measures like this are just bandaids and may in fact open up more holes because it adds complexity to an already complex beast.
There is just no way to do this in software. The future is going to be implementing these types of features in well proven hardware. Things like the no-execute bit, virtualization extensions and such are steps in the right direction but eventually I think we will see some really good security measures put into hardware.
The ratio of people to cake is too big
Nifty patch that (among others) adds similar safeguards to the linux kernel. Too bad it's not in the mainstream kernel.
The Raven
If sandboxing is systrace as the article mentions, does this mean they have solved the problems related to syscall wrappers first disclosed by watson's woot07 paper? Is the infrastructure tied directly into the system calls instead, or have they simply ignored the problem?
http://www.watson.org/~robert/2007woot/
Hail Eris, friend. I needed some bizarre humor this morning. :)
Hail Eris, full of mischief...
E pluribus sanguinem
When I first started using Quark XPress 6.5 in Mac OS X here at my new job, it took a while to work out the kinks for a rather complex project (doing layout for a journal w/ a 24 hr. turn-around), to the point that I actually put up a ``crash log'' outside of my cubicle, so that people could gauge my mood before entering. It's been a year now, and while I've gotten the project in question worked out (had to train myself _never_ to undo re-sizing a text box &c.), the totals might be interesting to people:
2006:
Quark XPress: 207 crashes (as many as 9 per day)
Adobe Illustrator: 25
InDesign: 35
PhotoShop: 15
Acrobat: 65
Microsoft Word: 23
Macromedia FreeHand: 9
Mac OS X: 14 (this includes Mac OS X apps like Mail.app and Safari.app)
The totals for this year are a bit more reasonable --- Quark XPress v6.5: 26, v7: 46 (I had to move the afore-mentioned journal over to Quark 7 after a re-design and that involved a new set of things to work-around) --- but I find Mac OS X overall reliable and workable as an environment (thought not as nice, consistent and synergistic as NeXTstep).
William
Sphinx of black quartz, judge my vow.
These are bandaids because they're like "morning after" pills...
The first line of defense is being BADLY neglected.
Get rid of the dangerous APIs (such as the single set of bindings in LaunchServices) and browser features (who the hell thinks automatically opening 'safe' files after downloading is a good idea?) first.
There's currently a massive bug that accidently implements ASLR on PowerPCs in 10.4.x, but it's per process and completely screws with the shared memory benefits. Of course, 10.5 doesn't have this issue.
How does this make a Mac safer?
It doesn't. It's really to make it easier to track whether different versions of an application are different versions of the same application.
How does it prevent malicious software developers from signing their software and making it look nice and pretty?
It doesn't. Any more than it does on Windows.
There is a trend emerging, ever so slowly... It used to be Mac users attacking Windows users... More and more I'm starting to hear Windows users attacking Mac users. Fortunately, so long as the argument is "Mac is gay," I don't really feel like Mac users need to bother responding. Linux I respect, though... because once I'm in the command line, it's just like OS X. (ducks)
Music - www.richardmac.com
"Changing the memory address layout is roughly akin to doing home security by locking different doors on different nights, but always leaving one unlocked. The would-be burglar just has to try all the doors to get in. Doing this kind of thing is trivial on a computer."
Yes, it's just like that, except you have millions of doors, and a intruder can only try to open one door per night, and the unlocked door changes randomly every night.
"People really need to stop adding these kinds of things that increase complexity and do not address the real issue, which in this case is access to the memory space of another application without some sort of credential or approval. When the real problem is addressed, this overly complex and fundamentally useless random memory address layout 'feature' will be left in to cause bugs and complexity forever."
This has nothing to do with access to the memory space of another application.
Point taken, but it hasn't been on-topic for any story that's been posted since I noticed it, so this seemed like the best chance to bring it up. Ya do what ya can.
Dewey, what part of this looks like authorities should be involved?
Good post. Privilege enforcement in hardware is going to be much harder to crack than various obfuscation schemes in software, which in the end are sort of like a spread-spectrum technique to reduce the signal level of your software deficiencies by spreading them out over the address space.
I find it odd most of the comments like yours are complaints about Mac security. Isn't "insecure" kind of an oxymoron with Macs? If you want an overly complex OS check out a Vista machine. My PCs have constant security issues and my main machine is a trainwreck from all the damage done by malware and bots inspite of running constant checks. I've never done a single thing related to security with my Mac and I've yet to have a problem. The made thei system even more secure. Shouldn't they get a applauded not blasted? Just because people are fans of an OS doesn't make it secure. Amiga had one of the most devoted fan bases ever and was arguably one of the least secure. Windows seems to be moving in the direction of locking the OS to the point where software won't run. Mac has managed to make their machines secure without such draconian measures. Shouldn't this earn them geek points not have rocks thrown at them all the time?
How does the third-party software signing work? How does this make a Mac safer? How does it prevent malicious software developers from signing their software and making it look nice and pretty?
It gives you someone to sue, duh. Knowing who to trust and verifying the certificate chain is, of course, your responsibility.
"security by locking different doors on different nights, but always leaving one unlocked." A bad analogy IMHO. It is not that you leave things unlocked, but that locking is really hard. This is a measure to cope when all else fails. Its more like taking a different path to work everyday, to make it harder for enemies to attack you. Wish all you want for enemies to not exist or to have impenitrable armor, but common sense dictates to prepare for the attack anyway.
Some of the things that Apple is doing in this pass are good and useful things. ASLR isn't one of them. It is pretty amazing to see a company adding something like this four years after the research literature has that ASLR is trivial for an attacker to beat. The question is: why add something that is so disruptive to legitimate code when it doesn't do any good?
Jonathan S. Shapiro (The EROS Guy)
I believe that all this means is that when an application screws up your Mac in some way it should be possible to trace the dodgy application back to the developer who signed it. Whether 3rd Parties have to register with Apple before they can sign applications or not, I have no idea.
Another new feature coming in Leopard is Sandboxing (systrace), which limits an application's access to the system by enforcing access policies for system calls
Folks,
Just FYI, the sandboxing in Leopard is not systrace. Systrace is vulnerable to race conditions -- see Robert Watson's paper "Exploiting Concurrency Vulnerabilities in System Call Wrappers". I asked him about this at WWDC, and he told me that Leopard's sandboxing is based on a different technology and is not vulnerable to the same attacks.
--Paul
No no, your thinking about Excel.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Whenever application changes (which might because it was upgraded or infected) OS X Tiger asks if you want to allow new version to access saved passwords (Keychain).
This question is too much like Vista's UAC making users answer "yes, whatever, just bugger off". I suppose signing helps distinguishing between harmless upgrades and real damage, allowing OS X to ask this question less often.
It's not the hardware as much as it is the application....the flat memory model is the root of all security problems on Intelish hardware...
Even the 386 had some fairly largish number of selectors that could be assigned to an application, rather than just the one with a 2GB address space. So, you could have an application get some big amount of selectors, use them for guarded arrays and so forth, and it could be much more secure than now.
This is my sig.
... or, an OS with popularity of BSD, the consistent feel of Linux, the security of a Windows, with the openness and price point of OSX. That's a pretty good description of Vista, actually."Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Yes, Linus rejected it as security through obscurity even though it has no significant cost and in general makes things safer. Its the whole theory/practice not exactly the same thing thing. Though redhat, etc. should do it on their own and it sucks they don't.
Your analogy is completely confusing. Could you please rephrase it in the form of a car analogy? Thank you.
This isn't additional software. These are features of the OS that would prevent mal-ware or viruses gaining access to the system by overwriting the known memory space of some kernel level function. By changing where things are located in memory it becomes much more difficult for this type of attack to happen. These kinds of attacks are usually the kind that are auotmated, and wouldn't require user interaction to have them happen.
You can switch them off, and save yourself over $100 all at the same time, nifty eh?
There are two types of people in the world: Those who crave closure
"the real issue, which in this case is access to the memory space of another application without some sort of credential or approval." What??? This problem was address ages ago by the people who came before Apple and even by those who came before UNIX. This is simply NOT the problem. What is the problem here is the typical buffer overflow. yes we should look for these and fix them but this randomization adds one more layer. Yes the exploit can search all of the process' RAM but that means the program must be larger
"Doing this kind of thing is trivial on a computer..."
Ah... no. Because you have basically one chance to get it right. Find a stack overflow exploit somewhere and you have to pick one address point to try. Miss, and in all likelihood the application that downloaded your trojan TIFF blows up with a stack or protection error. (To pick one example.)
So to continue your analogy the burglar tries each door by lighting a stick of dynamite. Which is something the neighbors tend to notice.
And most people (myself included) tend to think of improved security as "features". Especially if it means that I'm not wasting time running virus scans and updating virus profiles and all of the other make-work needed to keep a typical Windows system functional.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
It forgot where the memory went, mind you, but it's the thought that counts.
No kidding!!! What do you say at this point?
Geez, get a test box already.
That way you can learn, find & complain about bugs, and test, all while not affecting your production machine.
There are two types of people in the world: Those who crave closure
Address space randomization makes a lot of legitimate techniques harder.
Name one.
OS X lets you cache a vector without any hackery. This will still work.
unnecessary security dialogs.
Nope -- they're just adding more info to the existing dialog you get when launching a downloaded app for the first time.
Then you'll like this one:
AutoFS
Automatically mount and dismount network filesystems on separate threads to improve responsiveness and reliability.
For example, if you install a copy of Acrobat Reader, you still have to trust Adobe. But you don't need to trust the source that gave you that copy anymore; if the software says it is made by Adobe then it _is_ made by Adobe, not some malicious third party.
ASLR - Hmm. 32, Male, Bristol - what's the R for these days? I can't keep up with the youngsters.
Get your own free personal location tracker
The accelerated-dispatch feature is optional, so you might well expect that security-conscious developers would learn to disable it. I don't recall ever hearing of anybody writing an Objective-C based exploit before, even as a proof-of-concept (though I may have missed it). It sure sounds like it could be done. I guess in that case, you'd have to depend on other security features minimizing the damage.
-Mark
That "vulnerability" was even mentioned as implementation bug on the manual page since 2002! That was an overrated piece of FUD. http://www.openbsd.org/cgi-bin/man.cgi?query=systrace&sektion=1#BUGS Niels couldn't defend his tool because he was chair of Woot 07. Very unfair. He did ask OS developers for modifications in parameter checks for system calls, as to make that safe it should be kernel side. No matter what similar tool you use, arguments can be abused. Only kernel space checks can be 100% safe.
I've read that many solid state forms of memory (Flash, etc) have a limited lifespan in terms of the number of writes performed on an individual memory address. I also understand that this life cycle is very large, but could this be a way to balance the load on a given memory address over time? Would that then suggest that Apple will follow suit with (I forget who it was) who released a laptop with a Flash based drive instead of a spinning disk HD?
Presumably it uses a similar certificate system like SSL. You get a certificate from some CA and you are guaranteed that the website you are connecting to is the true owner of the SSL certificate. Do something with an application and you can guarantee this code comes from the true author of the program, not just something else with the same name and icon. The only thing is, you don't have to use it so it doesn't enforce any security at all.
I'm just guessing, but probably Apple will check all their own applications to make sure they are signed by Apple. They say they are all signed so no one can replace your version of Mail with their own fake version without the OS complaining(I hope).
I may be talking out of my ass, but presumably the framework knows where the addresses of functions are though a lookup table or something. This isn't any different than the current lookup table that they would use now except the function locations are now random. What this accomplishes is that if you have an exploit in Safari through a buffer overflow or something and you want to call some system framework function at a known address location because maybe it has another exploit you want to take advantage of, you can't hard code this any more. I don't see how this would really affect anything in an Cocoa application.
Wrong! We have had the silicon for almost a quarter century. The 286 and up are perfectly capable of a segmented memory model, where you specify the size of the segment down to the byte. Make a 101-byte segment and try to access the 102th element and *BOOM* the MMU raises an exception.
The 386 (which is what everyone uses today) is even better, with various stupid limits removed.
We don't do it, though, because it creates additional software complexity. Or maybe it's because old 8086 programmers complained about that chip's "fake" (i.e. stupid and well,' yeah, really fake) segmentation crap. So when the 386 came out and offered a 4GB flat model (4GB should be enough for anyone), all the OS designers went that way.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I've been running 9a559 full time on my MBP. No major problems. 99% of programs work just fine. The only thing that doesn't work that well that I use is TextExpander and Mozy Backup.
So naming an operating system in the same order as german tanks, is "gay"? And please explain how an operating system having a cheerful name is bad thing?
10.0 Cheetah - Gepard(German for Cheetah)
10.1 Puma -Puma
10.2 Jaguar -Jaguar
10.3 Panther -Panther
10.4 Tiger -Tiger
10.5 Leopard -Leopard
It might just me being a history nerd, but I think naming an operating system after some of the finest tanks in the world is kinda bad-ass...
3 degrees of separation from Vladimir Putin
Name one.
Dynamically patching executables.
they're just adding more info to the existing dialog you get when launching a downloaded app for the first time.
THAT is already an unnecessary security dialog.
So that more women buy Macs. Remember, queers get all the chicks.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Seriously? This is one of your 'real' security holes?
Yes. The problem is that there is no such thing as a "safe" file. There are "secure applications", and if there is a deliberately secured application available to display an untrusted file then it can always be used, and if there isn't then the user should never be asked... the option to open a potentially dangerous file in an application with an unknown security stance at the time of downloading shouldn't be available: you should only open it in an application that explicitly advertises itself as being prepared to handle untrusted files, or by explicitly opening it from a download manager. Original comments here and in subsequent articles.
This one comes turned off by default
One of the ways that files are treated as safe has been, since I posted the original article, been turned off by default. The same pool of a mixture of sandbox and open applications (LaunchServices) is still used for opening URIs, unpacking archives, and so on... and this has been involved in more reported vulnerabilities in OS X than just about any other single cause.
The fix that Apple has used is the same one that Microsoft has used, and it's one that has failed to solve the problem no matter how Microsoft has tweaked it in the past 10 years, or Apple in the past 3. It's a bad solution, and the real problem needs to be addressed.
Warning dialogs are not a security feature.
Mac OS X has always has prebinding.
Aha, light dawns. This is not what I thought it was then. I withdraw that part of my complaint.
I still argue that no warning dialog should be treated as an actual security feature. They don't work... Apple is going down the road towards UAC, and they're attacking the wrong end of the problem.
It's nice that Apple will be stepping out of the Nazi-era with Leopard.
(yeah, yeah...Godwin...I lose.)
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
No, I think they are after the enterprise market, or at least they're moving towards that target. iCal has been able to share calendars (with the 'Subscribe...' menu item) in the same way as Vista for ages now. "iCal server" is the grown-up solution.
Simon
Physicists get Hadrons!
See NSBlog and read the comments. Accelerated dispatch is only used on legacy PPC machines, not Intel. There's no benefit on Intel boxes.
:)
[aside]
What I found quite amazing is that the 'slow' Objective-C message-despatch (when cached) is faster than a virtual method call in C++. It makes sense when you think about it, but I've been trained to think ObjC == slow, C++ == fast. I'm glad someone did the test
Simon.
Physicists get Hadrons!
http://en.wikipedia.org/wiki/Trusted_Computing
As a gay man i'd just like to say i find nothing remotely 'gay' about that name.
"Call us when the New age is old enough to drink" Beck
Apple, stop it with your fucking bullshit.
It's called marketing, and I think you'll find that every company does it. The way you're reacting, I advise you not to get a television. A single commercial block might give you a heart attack.