Run your program with the least permissions possible.
Listen to the full episode to learn how this applies to your application and what role the filesystem has. We’re not talking about imaginary mind control beams anymore. This is real and something you need to be aware of when writing your code. All it takes is a simple link in the filesystem for an attacker to exploit. You can also read the full transcript below.
Transcript
You have a choice of how you want to run your program. And by that, I mean which user account will be associated with the running application and what permissions will it have?
It’s usually a good idea to run with as little permissions as possible. Because an attacker has a goal in mind and doesn’t care how that goal is accomplished. As long as the attacker gets the desired outcome, then any available method to achieve that is open for use.
Think of it like this. Imagine that an attacker has a secret mind control weapon that can be used to to take over one employee at your company. Do you think the target will be the junior assistant office manager? Or the company president?
Now maybe the attacker doesn’t have an opportunity to use the mind control on the president and has no choice but to choose somebody else. If the junior assistant office manager falls under the control of the attacker, then any documents that person has access to will now be available to the attacker. And anything that was not granted to the office manager will remain unavailable to the attacker.
The same thing applies to your application. Only we’re no longer talking about an imaginary mind control weapon. This is real. You must consider what will happen if an attacker manages to take over your application. Anything that your application can do will be available for the attacker.
Now, you might wonder, so what? We’re not talking about people with unlimited ability to do things. We’re talking about an application with code that has already been written. A computer can only do what the code tells it to do. And since you didn’t write anything bad into your application, then so what if an attacker gains control. What’s the worst they could do?
After all, you didn’t write anything into your application that tells it how to send documents to a foreign country.
There’s at least three things to consider. First, what might seem like a perfectly normal feature in your application could actually be far worse when put to use in creative ways you never intended. Maybe your application doesn’t know how to send documents overseas. But it might know how to open documents and save them someplace else. Someplace that an attacker already has access to and can then download them and send the document anywhere.
Second, you don’t know what intent the attacker really has. Your application might not be the ultimate goal but is just one step in a larger scheme. What might seem harmless by itself could be damaging when used together with other attacks.
And third, along the same lines as the unknown intent. Maybe the attacker isn’t interested in stealing anything. Maybe the goal is to just add extra work to the computer so that it slows down to the point that it becomes unusable. If your application happens to be running on an important server which is handling the logins of all the company employees, then bringing that server down could cause everybody to be unable to login to their computers. This is called a denial of service attack.
Once your application is under the control of an attacker, you’ll be glad that it has as few permissions as possible. Because anything your application can do will now be available to the attacker.
I’ve mentioned already that an attacker can use code that you programmed into your application to do things unintended. But nobody puts code into their application that turns over control to an attacker. And since computers can only do what’s been programmed into applications, then how does an attacker take over control?
At least I’m assuming that you don’t write code yourself into your application that let’s somebody type in a secret code and then turn over full control. Well, maybe that’s not so far fetched as it might seem. Some applications really will have the code already inside that allows somebody to take over and start giving orders. This is called a back door and was probably created to allow authorized users to take over in case there’s a problem.
You’ve probably noticed that elevators have extra controls for firefighters to use during emergencies. Using the proper key, a firefighter can take over the elevator and tell it to go to any floor.
If your application has such a feature, then you really need to pay attention. Back to the elevator. If that elevator doesn’t have the ability to stop at the top floor even for a firefighter during an emergency, then somebody pretending to be a firefighter will also not be able to get to the top floor.
Okay, what about when your application has no secret backdoors? How can an attacker get your application to do things that you never wrote the code for in the first place?
The answer to that is by providing input to your application. This input is specially designed to trick your application into doing things unexpected. There’s a couple things this input can do. The most serious vulnerability is if your application can be tricked into thinking that the input is code that should be run. Once an attacker is able to get your application to run code provided by the attacker, then it’s game over for your application.
A slightly less serious but still dangerous attack is to use the input to get your own code to do things it was programmed to do.
In this case, the attacker isn’t really taking over your application. But that’s beside the point. The attacker doesn’t care who wrote the code. As long as the attacker can use some code to accomplish their goals, then that’s what they’re going to do. In fact, you might even make it easier for an attacker because it can be difficult to inject code into an application.
An example of this and how this relates to filesystems is linking. Let’s say that your application regularly cleans up temporary files. It creates these files for it’s own purposes and you’ve written code that will sometimes delete all the files in your temporary working folder. The user of your application is completely unaware that the application is doing any of this. These are not user created files. They were created by your application so your application should be the one to remove them. Seems reasonable, right?
Let’s say that an attacker really wants to delete important documents someplace else on your computer. Someplace that the attacker does not have access to. But maybe your user does.
If the attacker is able to place a filesystem link to the real target files inside the temporary working folder, then your application might think it’s deleting its own files when it’s really deleting those important documents.
Now you can’t really control what permissions a person has when running your application. Unless you’re writing a service application. These are programs that run in the background on a computer. And they can be setup to run with user accounts that are very powerful. This is what you need to be careful of. Don’t run your application with more permissions than necessary because it might be fooled into using its normal functions to do things far beyond what was intended.