The basic rule in any security is called economy of mechanism which is a fancy way of saying keep things simple. You've probably heard of it in your introductory
programming classes as the kiss principle
keep it simple silly. Although, usually
a much stronger pejorative is inserted for the last silly. Basically, the interaction with the environment is very complex. You need to worry about
environment variables, you need to worry
about functions that are being dynamically
loaded and so forth. You need to worry
about UIDs, GIDs, signal masks and
all the stuff that was on the previous general
observation slide. So, what you want to do
is make things simple, make the program as self-contained
as possible so it does not rely on things
in the environment, or rather any reliance for things on the environment
is minimal and checkable. The next slide shows one thing
you should avoid always, and most systems disable these now but there
are a few that don't. Setuid Shell scripts or
any script that is setuid. The problem is programming languages in the shells
are incredibly powerful. So, when you interact
with the environment, very unexpected things
can happen. The best example
that I know which was in fact use the compromise many systems is the shell SH. Now, an early versions
of the shell, would distinguish between being interactive and running a script. If it was interactive, like when you logged in, argument 0 was -SH not just SH. So, what this means is
that when the shell began, first thing it
would do is look at the first character
of it's some name, and if it was hyphen,
boom you're interactive. So, what you could do with Setuid Shell Script
when you find it, instead of firing up
the script directly, put a hyphen in
front of its name, and then fire it up, and all of a sudden you'd have
an interactive route on shell. So, avoid scripts, not just shell but Python or pretty much anything
that's not compiled. The next slide shows the attack. Etc reboot is setuid to
root as you can see from the ls results the -rws, the s means it's executable, it's setuid to the owner
and root is the owner. So, it's commands text
that means a script. So now we link it to a file
whose name begins with -x. In this case, on
this system etc and tmp are on the same file system, so we could do the link. We then just run -x,
boom, we're root. What does this mean? Well, it means that the author of the shell assumed that the user would not
change the name. In general, you
assume that the user can control the name
of the program. For the shell example, the assumption was that
the user couldn't put a dash as the particular character as the first character of
the first argument. As a result, if you saw that
the shell was interactive. In point of fact that
was a bad assumption. The second thing is when
you write your program, assume the user will enter
an invalid part of a command. So in other words, if you expect the name
plus the file name as an argument and the user only enters the name what's
going to happen? In this case, they made
the wrong decision. If you were expecting some arguments to
the shell script and the script began with hyphen, you ignore those arguments
even if they weren't present. So, don't base the user's ability to control actions of
the program on the program name. It's perfectly okay if the name of the program says
what the program will do, for example with send mail. The mail queue program
lists what's in the queue, the send mail is
the message transfer agent. Same program, just a different
name and that's fine. But in both cases, the user does not alter anything, the user is simply saying
which function he or she wants, and this is a good example of the principle of
separation of privilege. If the user wants
to alter something, makes sure that there is
a check to allow them to do so. For example, a name
and a password.