Gammon Forum : Programming : General : Hardening our sources

Entire forum ➜ Programming ➜ General ➜ Hardening our sources

Hardening our sources

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by

Enderandrew USA (37 posts) Bio

Date

Wed 15 Feb 2006 11:06 AM (UTC)

Message

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?

"Nihilism makes me smile."

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #1 on Wed 15 Feb 2006 11:19 AM (UTC)

Message

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. :-)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Enderandrew USA (37 posts) Bio

Date

Reply #2 on Wed 15 Feb 2006 02:45 PM (UTC)

Message

Thank you for the good advice.

Where might I find such a tool?

"Nihilism makes me smile."

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #3 on Wed 15 Feb 2006 08:10 PM (UTC)

Message

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/

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

15,008 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top