Hardening our sources

Posted by Enderandrew on Wed 15 Feb 2006 11:06 AM — 4 posts, 17,019 views.

USA #0
I know that we can harden our server with some nice hardened kernels, compile options with GCC, etc.

However, certain codebases list hardened code as a feature.

What can we do from a coding perspective to "harden" our sources and protect against buffer overflows, exploits, etc?
USA #1
It's hard to say. "Hardened code" might be a marketing term for "we spent a lot of time fixing bugs". :)

It could also mean that generally unsafe programming practices were avoided, or rather that safe programming practices were used.

For instance, it is generally unsafe to:
  • execute arbitrary user input
  • stick arbitrary user input into a buffer (array) without checking sizes/lengths
  • checking pointers for null values before dereferencing them
  • having code that can gracefully recover in the face of an error (e.g. not crash on a bad pfile entry), or not crash if bad online-construction commands are entered
  • making sure that players can't enter input that would confuse the game. For instance, since ~ is the string delimiter in files, do not allow ~ to be saved without escaping to e.g. player biographies


If I had to put it generally, I would say that to be "generally safe" you would check for all possible error/exception cases at all points.

But again, I think it's more of a buzzword than anything else. If somebody told me they had hardened code, I would (most of the time, depending on who it was) assume that they meant absolutely nothing more than that they applied good programming practices in general to their code.

Of course, there are tools that help generate properly hardened code. Such tools perform analysis of the program under all possible execution traces, and see if anything makes it blow up.

Interestingly enough but perhaps not surprisingly, if such tools were to be run on SMAUG, the results would be very, very bad. Considering that these tools find bugs in the OpenSSH server, where security and safety are critical, I'd imagine that SMAUG (or most code that most of us write for MUDs) doesn't stand a chance by comparison. :-)
USA #2
Thank you for the good advice.

Where might I find such a tool?
USA #3
Unfortunately I don't know of any available for public download. It's pretty cutting edge research, actually. This one in particular I was referring to is being done by some colleagues of mine for their thesis.

But, you can use something like Valgrind, which helps a lot. It'll tell you if you do things like access uninitialized data, step out of array bounds, leak memory, etc. Very useful to run your code through Valgrind every once in a while.

http://valgrind.org/