A Closer Look At Apple Leopard Security

Last week we discussed some of the security features coming in Leopard. This article goes into more depth on OS X 10.5 security — probably as much technical detail as we're going to get until the folks who know come out from under their NDAs on Friday. The writer argues that Apple's new Time Machine automatic backup should be considered a security feature. "Overall, Mac OS X 10.5 Leopard is perhaps the most significant update in the history of Mac OS X — perhaps in the history of Apple — from a security standpoint. It marks a shift from basing Macintosh security on hard outside walls to building more resiliency and survivability into the core operating system."

Comments

Significance

[Mikey-San]

"Overall, Mac OS X 10.5 Leopard is perhaps the most significant update in the history of Mac OS X -- perhaps in the history of Apple

Maybe in the history of Mac OS X, but definitely not the history of Apple itself. I'd say that would be, oh, the shift to Unix.

Re:Significance

[noewun]

Well a lot of people considered Moving from OS 9 to OS X a downgrade.

It wasn't a lot of people. It was a vocal minority, the same minority which swore up and down that they'd never touch Apple again after the Intel switch and who spend hours debating the tiniest "flaws" in OS X's GUI. In other words, people for whom computers are an obsession or a fetish.

The the rest of us--people for whom computers are tools used to make money--OS X, and the features it brought, were long overdue. The switch was entirely worth it if only for the addition of a modern memory susbsyetem to an Apple OS. No more preemptive multitasking and having to specify how much memory each application got.

Re:Security

[jellomizer]

Well Linux and Apple people like seeing Microsoft with security holes. How many articles about microsoft security problems are tagged "HAHA". Windows People like seeing Apple and Linux security holes because then they don't feel as bad about choosing Windows. Linux people are not normally to happy to see Apple Security holes because it usually means Linux has a simular problem and vice versa.

It is basicly a case if one can say I am more secure then you then I win.

Re:Security Conserns of Time Machiene?

[99BottlesOfBeerInMyF]

What would happen if you had an important file you temprarly drop it in a public location then move it out. once the person downloaded it.

If it is an important file, why would you drop it in a public location in the first place, instead of just transferring it directly to that user or putting it in a password protected location or them? The scenario you envision is already a security problem because you're posting private data in public temporarily. I'd argue the right solution, is not to do that at all.

Re:Security

[NatasRevol]

It's simply http://en.wikipedia.org/wiki/Schadenfreude.

Re:It's to bad that 10.5 is not comeing out for al

[AntEater]

"Mac OS X has the "it just works" reputation because of the limited number of hardware configurations on which it runs."

I've heard this for years but I still haven't seen ANY hardware sample where Windows "just works". I'd put more value on the fact that Apple based the core of their OS on a unix-like system not the registry/spaghetti mess that has been windows for the past decade plus. I'm sure that eliminating poorly written drivers from the mix does help prevent some of the problems that plague windows but it's not the whole story by a long shot.

Besides, with that argument, Linux should be even more unstable because very few of it's hardware drivers are written by the device manufacturers - many are reverse engineered.

Re:Code randomization a bad idea

[bucky0]

ASLR works using the dynamic linker. For the vast majority of programs (I can't think of any counter examples off the top of my head), the dynamic linker works transparently to match up in-program function calls with their proper library addresses. If ASLR adds bugs to the implementation, it must be because of a faulty linker, which can be debugged out.

Virus writers will write something that searches around for the right place to patch
It's not quite that simple. Virus writers have a practical limit of how much code they can squish into a buffer overflow (which reduces the effectiveness of a NOP slide) Not only that, protected memory operating systems will bomb out if you start randomly poking at memory addresses. Since the addresses are randomized, you don't really know where to start looking which means it becomes a probability game of how many valid addresses the code your looking for could be at compared to the total address space.

Developers will think buffer overflows are now OK, and write worse code.
Developers have known about buffer overflows for years, and people still use sprintf over snprintf. I doubt anyone who is doing any serious coding will look at ASLR and say, "Hurray! We can forget about string validation!"

Re:What about the insecure default settings?

[SuperKendall]

Trying to protect non-encrypted data from an attacker with physical access is a fools errand.