[MUSIC] Now that I've shown you
everything that's gone wrong, let's look at how to do things right. If you look at the slide How
to Correct Previous Problems, I mentioned a lot of these in passing, but
I'll go into a little bit more detail. For the lpr problem,
the first thing you can do is make lpr setgid to daemon,
remove it's setgid privileges. This limits the danger to the files that the group can write,
to what daemon can write in this case. So the problem's still there, but it's much better contained and the next
thing you do with lpr is you change it. So that when it goes to write a file
into the spool directly, it generates the sequence number, 002 or whatever and
then it checks to see if that file exists. If that file exists,
it doesn't override anything. That solves the problem,
even for the group. Now on the web,
there are a lot of fun things you can do. And the first question in
all of this is to ask, what can the user do to mess me up? Don’t worry about deliberate or
accidental, just whatever it is. If the program such as a web
browser requests a path, it can get two forms of paths. The first one is called
the absolute path name. And if you do /usr/local/web/data, for example, that's fixed, no matter what. The user will not be
able to go outside that. Or will they. If you use that to construct the path
name, then there's a potential problem. Let's say, you've got all your
pictures stored in user local data. User wants to see a picture, so
they supply the name of the picture here, picture.jpg. Okay, that's great. You now build a path. You get that and
you send it back to the user, done. But now, suppose the user supplies
what's in that third big bullet with a bunch of dots. Dot, dot means parent directory. And dot dot of the route directory,
by the way is also route. It's a cycle there. So if I supply that as the file name and
you don't check it, I get what's shown underneath that third big bullet which
translates to password file and substitute any confidential data that the web server
can access for that password file. And again, a little bit more subtle. Watch out for symbolic links and
web directories. because normally,
the web servers will confine access to files in a certain
directories or set of directories. But what you have to be sure
of is that the web browser or your server stays in that area. And if it's a symbolic link
within that area, it may not. Now, I grant you. In order to do this,
you have to set up your jailing. You have to setup your constraint
environment incorrectly. Problem is,
it's very easy to set it up incorrectly. That's why I'm mentioning it. If there are subdirectories, then bear in mind that you will have
need of slash in the file name. But that's okay,
because you know what should be there. What you don't want there are the dot,
dot. So if you have ../, that goes. There should be no reason for that, unless
you program specifically needs it for some reason and also look for
what are called safe path prefixes. This simply requires that all path
names begin with a certain string. In this case, safety or data. If you do that,
don't just filter for that first. Don't just look for that first part,
look for what follows. Because as you can see the attack
here is to put ../../ after that and now you're back at the root directory. What you want to do is on Linux and
set us a function chroot or jail. It changed the notion of
the root directory to a particular area that
the server has files in. If your system has it, there's a very nice
function called realpath that will take anything you give it and turn it into
a canonical or absolute path name. Get rid of all of the dots slashes and
all the dot dot slashes and all that. So that's good. And what you can do then is once you've
done that, create a whitelist of directories or a whitelist of
path names that you will allow. So then you use strn cmp or
string compare to determine whether or not that path, or
that file name should be allowed. You can do this on the client side, but make absolutely sure you
do it on the server side and the server should also check for
symbolic links or links to things outside
the controlled area. General rules are when you design your
program, design it in a way that whatever input you get or whatever parts of
the environment you need, you can check. These consistency checks will help ensure
that your program does what you expect. Examples, Heartbleed. Well, they didn't check the stated length
against the actual length of the packet and that caused the bleeding or
leaking of information. Ps, you didn't check the kernel file from
which you got the addresses to analyze and print information about where in a file
that an ordinary user could not write. DNS resolver, the get host by
added that we mentioned earlier. You need to check that all the characters
in whatever is given you are legal. And basically, its letters,
numbers, dash and dot. That should be it. And then the at problem that we
talked about, at made the assumption that only trusted programmers can put
at jobs into the queuing directory. That assumption was false and it couldn't
be validated the way at was written. So at had to be rewritten and atrun had to
be rewritten in order to allow validation.