StarDestroyer.Net BBS

I've started studying C programming and I intend to do some interesting stuff with it. But some of that interesting stuff might lead to security problems if I don't program them to be secure.

I'm very much a beginner at software security so ideally I'd like a thorough introduction on it. For what it's worth, I'm taking a look at a CompTIA Security+ exam study guide.

Jesus. No Certs. No Certs. No Certs.

Ok, this is going to be a ramble.

Writing secure C code is easy. Don't write C code.
Ok, I had to get that out of the way. But still, C is a very specific language for (today) specific tasks. What are you trying to use C for?

Now we're past that, let's talk business. All this is very much basics and when I end up teaching this stuff, we do it over a week worth of lessons, but the basics.
Writing secure C code comes down to 3 things. All easy to state, none of them easy to implement.

1) When manipulating strings/buffers, always verify precisely what your function does in edge cases. Sample Q: strncpy, a nice "secure" string manipulation. Is there a null terminator or not, if the string "just precisely" fits into the destination buffer?
2) memory. Clean up your goddamn memory. Know your goto cleanup pattern and use it well. Valgrind is your friend.
Or basically, if you're allocating memory, type it well, never cast it and always clean it up at one place.
3) You can do great things in C. Terrible, but great. avoid them. Do *not* abuse the language. At all. Do not play tricks like casting signed and unsigned integers into the same memory. Do not treat memory both as a string and a data buffer. just don't. Just...don't.

Generally, understanding software security is a really really wide issue. I'll give the high level then elaborate just a tiny bit.

Software security is a meaningless concept, let's split this up into Software Vulnerabilities, Application vulnerabilities and security.

Software vulnerabilities - Errors in the design, implementation or configuration of software. This can bug in the code itself (MS08-67), bugs in the design (MS Task Sched privEsc) or bad configuration (just...about any MongoDB instance in the world).

Application Vulnerabilities - System level flaws. For example, the horrible clusterfuck called Android. DNS in 2006. Or to be more specific, lets look at stealing passwords in Windows. There's no vulnerability, it's just complicated software with side affects that lets me(as an attacker) steal passwords using the right trick.

Security - This is the big issue. For example, the recent "backdoor" in Whatsapp. A real vuln or just smart design? Depends on the threat model. Powershell running by default, again, question of policy and threat model. Using SSL without certificate pinning, etc. etc.
Security is the question of how software is used. Your program might be bug ridden but not a security issue because no one adversial can use it to attack.



If you're interested in security, I highly recommend Silence on the Wire and Tangled Web to understand what I mean. If you're interested in writing good code, security is not the way.



P.S.
Take a look at this list of banned functions and ask yourself, why are they evil.

Thank you. I was planning on doing some stuff on Linux. As for unsigned stuff, I've already committed myself to avoiding them whenever possible as my learning resources said it's easy to make very bad mistakes with them.

SolarpunkFan wrote:Thank you. I was planning on doing some stuff on Linux. As for unsigned stuff, I've already committed myself to avoiding them whenever possible as my learning resources said it's easy to make very bad mistakes with them.

The other way around!
Data is unsigned untill specifically said otherwise. No ints. No chars (except when talking about characters).
C 99 gives you well defined integer sizes, such as uint32_t.

Oh.

As you can tell I still have a lot of learning to do.