|Home » Learning Curve
Of Sticky Bits & Preferences
So what can you do with a vulnerable directory?
The SLIPOC hole is a dicey one: it's not a programming error and it's not easily fixed. The question is: is there a workaround?
The short answer is 'no'; the long answer isn't so much different as it's just longer.
The Long Answer
Recap: there can be a file put in /Library/Preferences that can wreak havoc on your system. The file is com.apple.systemloginitems.plist and it contains applications that are to be launched by your system at the time you log in - but logically before your login takes place.
They run as root - with no authentication required.
A typical 'malicious' use of this feature would be as follows.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
Files in /Library/Preferences are free to come and go as they please: the directory is owned by root:admin and marked 0775 - any 'admin' process can rename, add, or remove files.
And that's dangerous. In fact it's so dangerous all the talk of Windows' 140,000 viruses matters nought as one simple hack-free exploit on Mac OS X - all known versions including the coming Snow Leopard - completely levels the field.
Taking Security Seriously
The Apple mantra, worn thin over the years, that they 'take security seriously' has no bearing here. The hole's been open through all major releases of Mac OS X - if going back as far as 'Jaguar' 10.2 in August 2002 is far back enough - and it's been brought to the attention of Apple security people time and again.
And always summarily dismissed.
And this isn't the first example either. The 'Opener' hole was also wide open dating just as far back and wasn't fixed until 29 April 2005. That hole was also summarily dismissed.
The Core Issue
Again: this isn't a programming error - it's a design flaw. So what's wrong? Simple.
The entire /Library hive is currently an attempt to get system configuration files to peacefully coexist with ordinary user configuration files. Users - and their applications - need to use this hive from time to time; at the same time Apple have set up things so their own system files are here.
There's no easy way to preserve the needed flexibility for the one without jeopardising the safety of the other.
Take /etc as a 'Unix' example: the files here are very sensitive, used exclusively by the system itself, and are locked down hard.
But it's not just a matter of locking down the files - one must also lock down the directories that contain them.
This is an issue easily lost: writing permissions on a file do not give you the ability to rename it or delete it. Those permissions pertain solely to the directory containing the file.
It's perfectly possible to have a file that cannot be renamed yet can be written to; it's also possible for that matter to have a file that can be renamed (or removed) but that cannot be written to.
Attempting to lock com.apple.systemloginitems.plist for writing doesn't stop the wayward process from removing it and replacing it with a 'better' one.
This is an issue easily lost on the casual user. It's the key to the difficulties with 'SLIPOC'.
The Sticky Bit
The sticky bit is an extra file permission bit. It's called the sticky bit because it was originally used to mark executables that shouldn't be swapped out but were to 'stick' in memory. The bit isn't used for this anymore - but it's since come to be used for directories where it means something entirely different.
Today the sticky bit offers a level of protection for directories so only the owner can add, rename, or remove files from it.
STICKY(8) BSD System Manager's Manual STICKY(8)
sticky -- sticky text and append-only directories
A special file mode, called the sticky bit (mode S_ISVTX), is used to
indicate special treatment for shareable executable files and directo-
ries. See chmod(2) or the file /usr/include/sys/stat.h for an explana-
tion of file modes.
STICKY TEXT EXECUTABLE FILES
The sticky bit has no effect on executable files. All optimization on
whether text images remain resident in memory is handled by the kernel's
virtual memory system.
A directory whose `sticky bit' is set becomes an append-only directory,
or, more accurately, a directory in which the deletion of files is
restricted. A file in a sticky directory may only be removed or renamed
by a user if the user has write permission for the directory and the user
is the owner of the file, the owner of the directory, or the super-user.
This feature is usefully applied to directories such as /tmp which must
be publicly writable but should deny users the license to arbitrarily
delete or rename each others' files.
Any user may create a sticky directory. See chmod(1) for details about
modifying file modes.
Neither open(2) nor mkdir(2) will create a file with the sticky bit set.
A sticky command appeared in Version 32V AT&T UNIX.
4th Berkeley Distribution June 5, 1993 4th Berkeley Distribution
Apple responded to the threat of the Opener hole by putting a sticky bit on /Library - this to prevent tampering with StartupItems. Prior to this fix (29 April 2005 - 'Tiger') StartupItems couldn't be locked down adequately - the Opener script could just remove the old one (perhaps locked for writing) and replace it with its own.
The key to the Opener hole was what was in StartupItems - so the misery goes a long way down (or up as you might see it). Trying to protect the files in StartupItems was futile; trying to protect StartupItems itself was also futile; the only way was to protect the parent of StartupItems - /Library itself.
One Down, One to Go
The 'SLIPOC' hole is similar - but adds a level of complexity that patching the Opener hole could avoid. For now one is confronted with the need to lock down an otherwise frequently used (and needed) subdirectory - Preferences. A lot of applications use this directory, as does the system itself.
Attempting to get these disparate files to peacefully coexist is impossible in the long run; the only reasonable solution is to take the 'system' files out of there and put them where they should have gone in the first place - buried nice and cozy inside /System/Library.
/System/Library is safe because it's locked down properly; because its parent directory is locked down properly; and because the grandparent - root itself - is locked down properly - with a sticky bit.
There's no way a non-root process can tamper with /System/Library. Consequently there would be no way a non-root process could tamper with /System/Library/Preferences either.
That's the long term solution - the day Apple live up to their mantra. So what can you do until then?
Setting the permissions on com.apple.systemloginitems.plist doesn't help; using a sticky bit somewhere along that path could conflict with ordinary user land applications; the situation is further exacerbated by the new low level implementation of Unix file system APIs that continually destroy files rather than opening them and truncating them.
Keep an eye on your Leopard inodes and you'll understand: ordinary APIs to 'update' files no longer do that on Leopard - and this change in functionality is today buried deep inside what used to be legacy Unix code. There's no way you can change this behaviour without gutting the system itself - this is something Apple have to do.
And they don't exactly seem to be in a hurry.
So what do you do if you have data storage or other system administration responsibilities? You can't exactly guarantee data safety anymore - not with this hole glaring everyone but Apple in the face. You want to keep your customers? You have to try something.
About the only remaining possibility - and it's an ugly band-aid to say the least - is to use 'system flags'.
CHFLAGS(1) BSD General Commands Manual CHFLAGS(1)
chflags -- change file flags
chflags [-R [-H | -L | -P]] flags file ...
The chflags utility modifies the file flags of the listed files as speci-
fied by the flags operand.
The options are as follows:
-H If the -R option is specified, symbolic links on the command line
are followed. (Symbolic links encountered in the tree traversal
are not followed.)
-L If the -R option is specified, all symbolic links are followed.
-P If the -R option is specified, no symbolic links are followed.
This is the default.
-R Change the file flags for the file hierarchies rooted in the
files instead of just the files themselves.
The flags are specified as an octal number or a comma separated list of
keywords. The following keywords are currently defined:
arch set the archived flag (super-user only)
opaque set the opaque flag (owner or super-user only)
nodump set the nodump flag (owner or super-user only)
sappnd set the system append-only flag (super-user only)
schg set the system immutable flag (super-user only)
sunlnk set the system undeletable flag (super-user only)
uappnd set the user append-only flag (owner or super-user only)
uchg set the user immutable flag (owner or super-user only)
uunlnk set the user undeletable flag (owner or super-user only)
archived, sappend, schange, simmutable, uappend, uchange,
uimmutable, sunlink, uunlink
aliases for the above
Putting the letters ``no'' before an option causes the flag to be turned
off. For example:
nouchg the immutable bit should be cleared
Symbolic links do not have flags, so unless the -H or -L option is set,
chflags on a symbolic link always succeeds and has no effect. The -H, -L
and -P options are ignored unless the -R option is specified. In addi-
tion, these options override each other and the command's actions are
determined by the last one specified.
You can use "ls -lo" to see the flags of existing files.
The chflags utility exits 0 on success, and >0 if an error occurs.
ls(1), chflags(2), stat(2), fts(3), symlink(7)
The chflags command first appeared in 4.4BSD.
BSD May 2, 1995 BSD
That's a lot of manpage gibberish so it's best to summarise. As of 2 May 1995 it's been possible to further protect individual files from a number of forms of tampering - some protections being so complete as to require 'single user mode' to remove.
So it's possible - at least theoretically - to lock com.apple.systemloginitems.plist with one or more of these flags to prevent tampering. The file should also be set to root:wheel and preferably marked 0400.
But whether this works is another matter - and it's not a long term solution. The long term solution is to get the critical system files out of there and put them somewhere else where they can be adequately protected by the 'rock solid foundation'.
Some people suggest another workaround: not running the 'admin' account unless absolutely necessary. This works of course - until you need to use the admin account. And that can be more often than you realise. But that too is not a long term solution: the 'admin' account is supposed to be safe; currently with the 'SLIPOC' hole wide open it's not. And that's just not right either.
Oh what a tangled web we weave when first we practice to place proprietary system files in our unprotected root library folder.
- Sir Walter Scott
Learning Curve: A Suggestion
Learning Curve: Rooting 10.5.4
Industry Watch: Get Root on 10.5.4
Industry Watch: You're Root, Dude!
Industry Watch: You're Toast, Dude?
Learning Curve: The First Real Malware?
Industry Watch: ARDAgent - Here to Stay?
Learning Curve: Apple Redefine 'Epic FAIL'?
Red Hat Diaries: Innocents in the Enterprise
Hotspots: SLIPOC – Root Exploit of Mac OS X
Learning Curve: ARDAgent on Snow Leopard
Industry Watch: It's Not New It Starts with 10.2
The Technological: Walking into an Apple Store
Digg: Get Root on 10.5.4 - It's Not Exactly Difficult
Apple Developer Connection: AppleScript Overview
Industry Watch: Huge, Crazy, Ridiculous OS X Security Hole
Digg: Stupid Simple Root Exploit Remains in Mac OS X 10.5.5
Apple Developer Connection: Apple Events Programming Guide
Hotspots: Stupid Simple Root Exploit Remains in Mac OS X 10.5.5
Rixstep/7: Stupid Simple Root Exploit Remains in Mac OS X 10.5.5
Developers Workshop: Hackers Handbook I
Developers Workshop: Hackers Handbook II
Developers Workshop: Hackers Handbook III
Developers Workshop: Hackers Handbook IV