CLIX Starter Kit

CLIX Main
CLIX Starter Kit
CLIX Bibliography
 

Let's try to chart out once and for all (!) how we think this program should be used. Let's start at the very beginning and try to not miss any steps.

0. Self-Hype

This is a good program that replaces system maintenance utilities such as TinkerTool, OnyX, Xupport, and *censored*tail which are only going to invoke the same Unix commands anyway. The tag says 'command line interface' but it's not that at all - it uses Unix commands but in a *GUI interface*.

And it's cheap. Really cheap. It's namely free.

Download: yes get it.

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

1. Open the Package

There are a number of HTML files inside along with the app itself and a directory called 'Command Files'. Move the whole thing to a location of your own choosing *BUT DON'T MOVE IT TO /Applications*. And why not? Because that's just stupid anyway.

Use ~/Applications and create it if you have to and always put your own software there in the future. And if some other software title protests and absolutely insists on /Applications *THEN DITCH THE SUCKER*. You can't fix stupid. Remember that.

What you're after here is putting *your* software in *your* area of the disk - something your funny friends on Windows will never have. Anything under '~' is fair game - just keep your stuff away from '/' or any area that's not yours.

[Good tip? Mask the permissions on ALL your files in ~ to exclude ALL group and other rights. Make sure no one can get in there without your express permission.]

2. Secure the App

As soon as you've moved CLIX.app to its destination then secure the binary. Just in case. Drop in to a Terminal at the path for CLIX.app/Contents/MacOS and type in the following.

$ sudo chown 0:80 CLIX; sudo chmod 0550 CLIX

This locks the file for writing and only allows root and admins to read and run it. There's no reason ever to not add further layers of protection.

3. Running the App

Just double click its application once so the system knows it's there. After that you should be able to double click any of the CLIX command files to open them.

That's the idea.

4. Finding What You Want

You don't have to use the provided commands. You can make your own. This is what distinguishes CLIX from the 'Wizards of OS X'. You'll find these commands everywhere - at Mac OS X Hints, at Rixstep, and so forth. You don't have to make small batch files and remember where you've put them all - you store your commands in CLIX files where they're always available and ready to run.

5. Sudo Alerts

Anybody at any time can ask CLIX for your password. Your password is kept in memory until such time as your computer goes to sleep or CLIX exits. These 'sudo alerts' are turned off by default but you can easily turn them on.

$ defaults write com.rixstep.CLIX SudoAlert 1

Then each time one of your commands - or something one of your commands refers to - requests sudo authentication you will get a prompt from CLIX. And you'll be able to allow use of your password once, for all subsequent requests (only for the current command) or deny completely.

6. TTY Tickets

It's really important to turn on a sudo feature called 'TTY tickets'. TTY tickets imply that a more common way of using privilege escalation is no longer possible.

The more common way of using privilege escalation - the default way - implies that once a process in the current login account has authenticated any other process in the same account can use this authentication for (by default) five minutes.

This is of course disastrous for computer security. The type of exploit that correlates to this security weakness has been described as a 'sudo piggyback hole'. Perhaps describing it as 'tailgating' would be more correct.

Whatever: there are two important 'features' of use of 'sudo' which must be turned off to make your computer secure.

And the second feature concerns that 'five minutes' mentioned above - commonly called the 'grace period'. The grace period is a matter of usability: so that the user doesn't have to resubmit a password for each and every privilege escalation.

Once TTY tickets are enabled there's smaller risk the sudo piggyback hole can be used as an attack vector but there's no reason to take any chances. So you'll want to turn off the 'grace period' as well.

This isn't easy. The good news is you only need to do this once. Here's the URL. Try to do this as you'll increase your computer security by an order of magnitude.

http://rixstep.com/2/20070601,00.shtml

7. Added Security for Free

Once you've set the grace period to zero and enabled TTY tickets there shouldn't be any way for rogue processes (trojans) to benefit by your privilege escalation - but still the same: CLIX takes things three steps further.

a) Just in case you haven't been careful and just in case there's an authentication still in the system and because CLIX wants to know each and every time you're going to be prompted for your password: before running any command CLIX destroys all sudo authentication data. It's wiped out. No command requiring sudo will get through for you without you (your program) being prompted for a password.

b) Just in case you haven't been careful CLIX will essentially perform the same task immediately after completing your command. This is completed asynchronously to save you time.

c) When you're about to exit CLIX or when your computer is about to go to sleep CLIX destroys ALL privilege escalation information: even if you have a grace period and have run an escalated command in Terminal you'll find you're going to need to submit your password again.

Then there's the $PATH hijacking issue.

8. $PATH Hijacking

$PATH is a series of locations on your hard drive. Commonly it's a combination of the following standard 'Unix' locations. Go to a Terminal command line and run the following command.

$ echo $PATH

Now run the same command from within CLIX. Are the results identical?

[No they're not! Read on to understand why.]

For both commands you should get the following directories but in different order.

/bin
/sbin
/usr/bin
/usr/sbin

The Unix 'commands' (programs) in those locations are locked down really tight: the files are protected by root and equally importantly their parent directories are as well.

Thus:

- There's no way anyone less than root can modify files in these locations.
- There's no way anyone less than root can replace files in these locations.

They simply can't be touched. [And their parent directories can't be touched either but that's a rather esoteric topic we'll leave for now.]

But the $PATH variable is unfortunately another matter. $PATH is a shell variable. The first value of this variable comes from a read-only area of the OS kernel. But through system startup this value can change. And after login there are two things that can further change it.

Our friend Georg built a clever 'proof of concept' in Unix scripting alone that shows how patently easy it is to completely take control of a target machine by fiddling with this $PATH value.

How bad is the damage? Use a little imagination. Drop yourself down through the rabbit hole. Imagine you're invoking 'sudo' but a rogue's placed a different 'sudo' earlier in your $PATH variable. You just gave your password away, didn't you?

[This is exactly what Georg's proof of concept does. It's worth taking a look at.]

There are two ways of corrupting the $PATH value so your commands go to the wrong files - something you don't want. The attack vectors are within the Unix shell bash and through an Apple facility - neither of which you should ever entertain.

Normally a rogue cannot corrupt this variable for other processes - it's got to do with the way Unix treats its shells 'concentrically'. Leave it for now.

Here are three articles worthy of a good read on the subject of $PATH hijacking.

http://rixstep.com/2/20070201,00.shtml
http://rixstep.com/2/20070204,00.shtml
http://rixstep.com/2/20070320,00.shtml

But what can CLIX do about this? That's obvious: CLIX restores the original value of $PATH from that read-only area of the OS kernel before running your commands.

This is why the output from the command 'echo $PATH' will be different on CLIX - you're getting back (CLIX is exclusively using) the impervious kernel's read-only version of $PATH. *This version cannot be corrupted by rogue processes.*

9. Other Precautions

There are other precautions you should take - above and beyond use of any particular program. They're listed at the third article linked above. Briefly:

√ Don't 'sudo' execute a script unless you can guarantee the contents of the script. This is basically the same principle as checking the integrity of modules that are going to be run with privilege escalation.

√ Watch out for sudo calls in scripts. Same thing basically.

√ Make sure your Terminal is invoking a second login when you use it. This is very critical. Your Terminal settings are in an unprotected file in your user area; they can be modified to effect 'ordinary' shell sessions - something you generally don't want. And why not? Because sessions like this can be hijacked a lot easier.

Read the rest of that article and follow the recommendations there given. Don't forget: some of the suggestions apply to procedures when not using CLIX - and thus do not need to be performed by you the CLIX user.

Further reading.

TTY Tickets
http://rixstep.com/2/20050521,00.shtml

Closing the sudo piggyback hole.

The Zero Time Stamp Timeout
http://rixstep.com/2/20051119,02.shtml

When only 100% protection is good enough.

 

Copyright © Rixstep. All rights reserved.