Monday, October 6, 2008

Secure Programming

I write most of my code in C and occasionally C++. I know Perl, (or Java), would be better in many cases but all my programming classes, (the school kind), require C so that's what I'm banging out most of the time. Add to that the fact that most password cracking programs are written in C/C++, (JtR written in C), (L0phCrack written in C), (rcrack written in C++), (Access Data's PRTK's cracking engine is written in C), so C tends to be my language of choice.

Well, today I came smack up against the fact that the strnstr() function isn't widely supported across platforms. Yes, I know the "n" functions aren't much better than the other string functions. Heck, I've had more than enough segfaults even when I thought I was using them correctly. At the same time though, they are "easy" to use and supported everywhere, (with the exception of strnstr). I know about the "l" functions, but once again they are mainly used on OpenBSD and aren't available on many flavors of *nix. The other option everone seems to mention is that I could just write my own string handling classes, but that's just asking for trouble. Finally, I could ditch straight C and use the C++ string class but a lot of my code still needs to be ANSI C combatable so that doesn't work. What we really need is a library that meets the following requirements:
  1. Portable - (Ideally it should work across all ANSI C compatible compilers)
  2. Secure - (otherwise we would just use the string.h library)
  3. Flexible - (It needs to be able to handle the tasks I need it to do)
  4. Well Known - (If people don't know about it, they aren't going to use it)

That gets to the core of my problem. Why is it that Microsoft is the only group that has released a secure string handling library, "strsafe.h", that is actually good? With the exception of option #1 above, it meets all the requirements. It's a rhetorical question, but why aren't "secure" versions added to string.h, (or at least the GLibc library)? It's no wonder programmers are still making the same mistakes they were 20 years ago if they haven't been given the tools to write better code.

For my part as a side project I'm going to see if there is a port of "strsafe.h" to the Linux environment. BTW, if you are programming in a Windows environment, you would be crazy not to use "strsafe.h". It's easy to make the transition, and it's even fairly straightforward to update most legacy code since there's a one to one correspondence between most of the string.h and strsafe.h functions.

If I can't find that port though, my options boil down to finding a library on sourceforge or writing my own. Unfortunatly, that fails option #4, and probably option #2 since writing secure code is HARD. Even the best programmers often miss weird cases, so I generally don't trust something until a lot of people have had the chance to bang away at it.

The ironic thing is that for the programs I'm writing, security isn't a requirement. That being said, I've found that trying to write secure code generally makes my programs more robust, and it's good experience. Also, it's hard for me to give people heck when I'm still using strcpy...

If anyone knows of a better solution I would love to hear it. On that note though, if you are programming in C/C++ I have to recommend the following link..

http://msdn.microsoft.com/en-us/library/bb288454.aspx

No comments: