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.