[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.