This video looks at how do you identify users
and how do you change privileges because,
as I said earlier,
those are two very common things
security-related programs do,
and they're very easy to get wrong.
Here, the question of identifying the users is,
which user do you want?
Do you want the one who's actually running the program?
That's the real UID,
that can't be changed by some systems.
So if I'm running the program and that program
changes his privileges and it spawns a sub-process,
then that third program may get
the ID of the second program and not of me.
To avoid that, look for the login ID.
That says who logged into
the environment and which of these programs are running.
It can typically not be changed.
On a couple of systems, the privilege user,
the administrator, can change them,
but those systems are actually fairly rare.
If you want to identify another user, for example,
the user whose privileges the program is running with,
just make sure that
the functions that are
called or the method that's used to
do this is something
not that an attacker cannot interfere with.
For example, if you look in a world writable file for
a name and base privileges upon that name,
then if I can write to that file,
and its world writable so I can,
then when the program starts up,
it's going to read the wrong name.
I simply put the administrator's name in there,
and suddenly, I'll have administrator privileges.
The next question is, once the program
gets this information, how does it use it?
Here's a little trick.
Typically, the user IDs
that the kernels work with are integers, not strings,
but humans need strings to understand who people are.
So what happens if two users happen to have the same UID?
For example, if root and toor both have a UID of zero,
then anyone who could log in as toor
will be treated as root.
If bishop is able to change his UID to
zero in the authentication database,
then when bishop logs in,
everything he does will be executed with
privileges of UID 0, which is root.
So the string name is not the controlling identity,
the numeric UID is.
Now, one way some programs
get this information is they look at the standard
input and see who's connected to that.
If that's a file, then they go to the standard output,
then they go to the standard error,
and on some systems,
they may go beyond that.
The question here is,
how do you know who those are connected to?
We'll get into that in a few minutes,
but here's a little activity for you.
On the Linux system,
suppose the accounts root,
toor, and mab all have the UID of zero,
and mab runs a program that gets
his UID and then gets the name associated with that UID.
Write a small program to see what happens.
On your Linux system which you control,
you can easily create user M-A-B and give it UID 0.
Do that, put it at the end of the file,
and watch what happens when you run your little program.
Now, here's a good example of
how changing privileges can mess you up.
There is a program called FTP that
allows you to download files from the server.
HTTP does the same thing,
so it's used a little bit more than FTP,
but FTP is still very widely used.
When FTP begins, it's a demon, it's a server.
So it starts up with privileges of root because it is
the access ports that no normal user can access.
But the problem is then if bishop logs in using FTP,
bishop would get root's privileges,
which you don't want.
So what happens is,
when you log in,
there is a command that
FTP sends over called user, and it would say,
user bishop, and then,
the demon would spawn
a child process and
change the privileges to those of bishop.
So anything done by
that FTP session will
have the rights of bishop and no one else.
Now, it turns out
that on many Linux systems and certainly on Unix systems,
when you change privileges,
the previous user identity is saved.
It's called the saved UID.
The reason for this is, let's say,
I need to do two things as the root user,
but once at the beginning of
the program and once at the end.
If I have the saved UID, what I do is,
I start up with root privileges
and immediately drop them.
When it comes time to do the first thing as root,
I change my identity to root.
It looks at the saved UID and says,
at one point, he was root,
so we'll go ahead and give him root.
I do my little thing as root,
and then, I drop privileges.
Towards the end, when I need to
become root again, same thing.
I say, please give me root privileges,
it looks at the saved UID and says,
yeah, he had it, and gives me root.
It turns out though, this can
be a little bit of a problem.
Anonymous FTP is a mechanism
where anyone can log into your system as anonymous,
and the privileges of anonymous
are very tightly constrained,
but some sites allow you to upload files.
So what you do is,
you write a small program to
simply switch UID to root, you then upload it.
Many FTP servers have the command called SITE
EXEC that will allow
you to execute a program you uploaded.
So in that case,
you are inside EXEC running your little program.
Your little program says,
please change the UID to root,
and the FTP demon says, well, wait a minute.
You were root once, so yes, you can do this.
All of a sudden, you have
root privileges on that FTP server.
Now, if the FTP server is put together correctly,
all you can do is damage the files in that area,
but still, it's something that should not happen.