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.