I haven’t blogged in awhile due to extreme business (such as midterm exams in school), but I thought it would be funny to demonstrate how important security coding is in some schools.
In my operating systems class, we are into the topic of multithreading and other concurrency issues. So the professor has given us an assignment, to make a sample web server multithreaded. The code was actually from a former professor, and included a few security checks, such as this one:
// Check that filename does not start with a "..", "/", "\", or have a ":" in
// the second position indicating a disk identifier (e.g., "c:").
// - This is a security check to prevent grabbing any file on the server
if (((file_name[1] == '.') && (file_name[2] == '.')) ||
(file_name[1] == '/') || (file_name[1] == '\\') ||
(file_name[2] == ':'))
{
Notice the bolded line, where a check is done to make sure that the filename doesn’t begin with “..”. Gee, I wonder what could possibly break that check?
Approximately 40 seconds later I had broken the security of that web server, with a filename of “./../../../../../../../config.sys”. To make matters worse, the server incorrectly rejects requests to files with names like “..hidden-easter-egg.txt”.
So a tip to all of you coders out there trying to check for this sort of thing:
- You have got to search for ‘/../’, if that exists anywhere in this string, someone may be trying to evade your security.
- Also, you have to make sure the filename doesn’t begin with ‘../’. This sequence could be OK later in the filename, which is why you can’t just check for that.
- If you allow alternate path separators (such as ), convert them all to the canonical path separator before performing this test to make the comparison easy.
- Also, if you perform any un-escaping of the filename (mandated by HTTP, but not included in the sample server), you must un-escape the filename first as well. But don’t un-escape it twice by accident!
- There may be other things I have forgotten. ALWAYS use your common sense, and when you are coding something meant to be secure, or even half-secure, think with the worst-case scenario in mind, and then TEST IT against your program. I am not a ‘security guy’, but this flaw was obvious even to me. I can hardly believe none of the previous students in this class hadn’t noticed it.
In happier news, I’m working on a replacement for JuK’s filerenamer dialog. It will kick some serious ass once it’s done, hopefully allowing a user to have a reasonably powerful renamer without all of those annoying string replacement tokens to deal with.