Secure programming

Programming is a complex task, and it’s even more complex when you add security to the equation, there are lots of manuals on the Internet, and books on amazon that deal with secure programming, mostly they either geared to web developers or C programmers. What has prompted me to write this is the fact that I’ve been tasked with working on a application that will be used to performance test a system, now this little tool needs to simulate 1,000,000 transactions, everything is OK until I see the code.

The first thing out of my mouth was WTF! I’m not very good at this programming stuff I’ll admit it up front, but what I saw was disturbing. I can not show you the code, because well I’m bound by NDA’s. Nn a few hours of reading I found out the following:

  • Authentication routine is completely and utterly useless.
  • There are several exploitable buffer overflow.
  • Memory leaks, that make Niagara falls look like a dry pond.
  • String format vulnerabilities.
  • Among many others.

In short this a good example of how not to code! All the above issues could have been solved with simple common sense tips:

  • In a routine, always check that the parameters passed, are what you are expecting, do this before anything else. Most Java programmers that I know suffer from this.
  • Make sure that the buffer being passed to your method is of the correct/expected size before doing a strcpy() or strncpy(). Here is a little well known fact, strncpy() is safer than strcpy(), but it’s not safe from misuse, so double check the size/length of the destination where strings are being copied, specially if they’re passed as a parameter to a method, typo’s, miscalculation can make your code vulnerable to a buffer overflow, or in a better case corrupt your stack.
  • Don’t malloc a static variable inside a method, that is going to return said variable, just don’t! ….. alright I’ll explain the reason is very simple, you cannot free the variable, because you need to return it, so the caller of the method needs to take that responsibility, in some cases it might be the only way to go, and you document it, so you don’t forget to free() it, but if it’s not imperative don’t do it!
  • Do not down cast, casting a long to a short might seem exciting, but there are some things that you shouldn’t want to do, or find out why you shouldn’t do it. If you know what you are doing, then you do not need to downcast, if you don’t know what you are doing then I suggest: You walk away from your keyboard slowly.
  • For the love of God, I know you are smarter than me, I admit it, but please, please, just because you got an A on your algorithm class, does not mean you can take a MD5 Hash, slice it in sequence of 8 bits, compress it to a 8 char string using a pad, and expect it to be secure. If you are spending the CPU cycles generating the MD5 hash for pits sake, use the damn hash!!! While established you are smarter than me, chances are you are not smarter than Bruce Schneider or Donald Knuth. Slicing a hash using the above method as a password encryption mechanism, is a open invitation for deep anal probing by the l33t in this internet world. If you don’t know why it is insecure, think about it for a bit, you’ll get it, believe me If I found it you’ll understand it.

There is another trend that annoys me greatly, it has nothing to do with security, it’s just most programmers, do not put their name and date on the code they’ve just written. I can forgive not putting your name specially if you are not proud of the code, or if it’s company policy, but the date of creation and date of modification? It is quite useful specially when you have to track down a change.

It’s been a while since I blogged, but hey I’m sure I was not missed.


About this entry