Rooting 10.5.4

This wasn't exactly news.

Get It Try It

Rooting Apple's Leopard 10.5.4 isn't exactly rocket science. The design flaw has been there for years. It just keeps shifting shapes is all.

Do It Pre-Fab

If you've read the first article in this series but either don't know how to go about creating the POC or just don't want to be bothered: here's a shortcut.

ftp://rixstep.com/SLIHack.tar.bz2

That's 3425 bytes. 3 KB. Good things come in small packages.

Unzip SLIHack.tar.bz2, build the app, move it to /Users/Shared, move the 'plist' to its location - and reboot.

Where's the Flaw?

The flaw is a design flaw. And it's been around for years. The flaw lies in the fact Apple recognise things in /Library that are going to influence processes owned by root. That's a Very Bad Thing™.

It's a very bad thing because it's almost impossible to lock /Library down without destroying the little good it can do.

It's a very bad thing because matters which concern root shouldn't be exposed to the rest of the system. They should be locked down and accessible only by root.

But /Library has a hodgepodge of stuff - some of it's innocuous, some of it's not - and it's all supposed to live and coexist in the same cozy folders.

It doesn't work.

What's Gone Before

The Opener hole - called a 'crater' by the author of Opener - made it totally easy to root any OS X box. All you needed there was knowledge of how to set up a 'startup item'. There was no authorisation needed. Just craft your system bomb - and copy it into the right directory. No hacking required. No resistance encountered. Then wait for reboot and the box is yours.

The input managers hole was another big one. This site and especially Kevin Finisterre nagged Apple for years about it. And Apple as is their wont refused to look into the matter and curtly retorted 'works as designed' over and over again.

But nothing like this works as designed unless your objective is to create the leakiest operating system in history.

Plugging the Hole

You can protect yourself from 'SLIHack' and related attacks. And you should. As this is an embarrassing design flaw and not a coding error odds are it will take Apple quite some time to come up with a good solution.

Then too they seem bent on keeping the current design and so can't be expected to part with it easily. So what you might get from them instead of a good solution is more 'band-aid code' that can break in another way in no time flat.

And in that case you're just as well or better off rolling your own fix.

• You have to protect the 'plist' file. The easiest way would be to lock down /Library to prevent renaming, addition, or removal of files. But it's not easy to know what side effects this will bring.

• You can create the 'plist' file yourself and then protect it. You might protect it by giving it a slew of user and system flags like 'no unlink' and 'immutable' - naturally both for yourself and the system.

• To do the above you either need the kind of tools Rixstep have or you need to get down to a command line and hack it out yourself. Your precious Finder won't even show you an executable bit today - don't expect it to deal with the eleven extra Unix file flags. Try 'man chflags' and take it from there.

See Also
Industry Watch: Get Root on 10.5.4

Kudos to the crew at MacShadows for keeping on top of this one and at least trying to get Apple to relent.