Live data from Hacker News

The CERT C Secure Coding Standard

securecoding.cert.org

21–30 of 32 posts

Re: The CERT C Secure Coding Standard

#21

I investigated this Standard once. See https://www.securecoding.cert.org/confluence/display/seccode... and exception EXP05-EX3 in particular. Exception promotes non-standard-compliant (undefined) behavior because it "usually works".

If you are investigating the CERT coding standards, I would recommend focusing on the rules more than the recommendations. The rules are normative and give excellent advice on how to write secure code. The recommendations are generally more about code quality than likely security defects.

More information on the distinction can be found at: https://www.securecoding.cert.org/confluence/display/seccode...

Re: The CERT C Secure Coding Standard

#22
post #6

I'm well aware this is full-on "middlebrow dismissal", but still, I feel that in 2015 this standard isn't complete without a chapter saying just don't. somewhere. I understand why a standard like this is necessary, but really it's like a CERT Safe Highway Cycling Standard or a CERT Healthy Smoking Standard. If security is an important enough goal to want to apply this entire standard in detail, maybe there are better…

Some people like programming in C.

Some people like smoking meth. That's a rather incomplete argument for why it is a good idea.

C/C++ is likely fine for e.g. games programming where speed is of maximum importance and security/verifiability is not.

However in 2015 I would not write nor recommend others write new system services (e.g. DNS, DHCP, web servers, etc) in C or even C++. They're insecure by design and as history has shown us, they cannot be made secure.

That all being said, as there is a massive code base of pre-existing code it is often impractical to not continue these projects in C/C++. It would require tens of years of work to do so. However if an OpenSSL replacement was written in a more secure language with verification being a priority from the ground up, I'd be all over that like a cat on tuna.

Re: The CERT C Secure Coding Standard

#24
Some of these are pretty interesting though. For instance, "avoid using repeated question marks". How is this a problem? Well you can pretty easily turn something as harmless as a comment into something that absorbs the next line of code. Good luck debugging that one. https://www.securecoding.cert.org/confluence/display/seccode...

Re: The CERT C Secure Coding Standard

#25

I investigated this Standard once. See https://www.securecoding.cert.org/confluence/display/seccode... and exception EXP05-EX3 in particular. Exception promotes non-standard-compliant (undefined) behavior because it "usually works".

Casting const away is never undefined. However modifying objects defined with const is. If the object was never defined with the const qualifier, then there is no problem with the casting.

Re: The CERT C Secure Coding Standard

#26
post #7
post #4

Actually it's hard to obey them all. And C makes it so easy to create pitfalls. Is there a language specially designed for secure programming?

Ada and SPARK power many safety critical things like airplanes fighter jets space rockets railways and so on. I've been recently trying to learn Ada and it's a beauty. Many people have misconceptions or think it's obsolete so they miss out.

As I understand it having looked into Ada and SPARK (an Ada subset), there are no good free runtimes for them, i.e. ones to do serious projects with, vs. learning and open source development. That came from my investigation of this kernel: http://muen.codelabs.ch/

Re: The CERT C Secure Coding Standard

#27
post #23
post #2

Should be compulsory reading for any developer. Not only C, but the other CERT standards as well.

Having a CERT standard seems to speak poorly of a language. I'm a little surprised Java has one.

Perl and Python are also getting one.

Java luckily doesn't suffer from use after free, out of bounds, stack corruption, return oriented programming, dangling pointers.

A memory safe language is still open to parameter validation, races to data access in external resources, validation of external data, incorrect use of security certificates, configuration exploits and many more.

Getting rid of C style bugs is only the tip of the iceberg in security.

Re: The CERT C Secure Coding Standard

#28
You might also be interested in the MISRA C coding standard, which is geared towards reliability and safety rather than security. The MISRA C standard is fairly strict and mostly (but not entirely) machine checkable.

There was a Usenix talk on developing code for Mars rovers in which Gerard Holzmann pointed out that for large projects coding standards are much more effective when you have automated compliance checking. https://www.usenix.org/conference/hotdep12/workshop-program/...

I note that there is a tool for checking the CERT rules called Rosecheckers: http://www.cert.org/secure-coding/tools/rosecheckers.cfm? It looks like it might be incomplete and/or outdated.

And the CERT pages include a reference to a deleted summary of other automated checkers such as Coverity and Klockwork: https://www.securecoding.cert.org/confluence/display/seccode...

Re: The CERT C Secure Coding Standard

#29
post #24

Some of these are pretty interesting though. For instance, "avoid using repeated question marks". How is this a problem? Well you can pretty easily turn something as harmless as a comment into something that absorbs the next line of code. Good luck debugging that one. https://www.securecoding.cert.org/confluence/display/seccode...

I've been programming C for 3 decades+ and that would have so bitten me, I had no idea about that. Luckily I avoid double question marks in code comments anyway (question marks in comment are more like mental notes to yourself during the phase where you try to make sense of some codebase, if things work out they should disappear anyway).

Learn a new thing every day.

Re: The CERT C Secure Coding Standard

#30
post #6

I'm well aware this is full-on "middlebrow dismissal", but still, I feel that in 2015 this standard isn't complete without a chapter saying just don't. somewhere. I understand why a standard like this is necessary, but really it's like a CERT Safe Highway Cycling Standard or a CERT Healthy Smoking Standard. If security is an important enough goal to want to apply this entire standard in detail, maybe there are better…

Precious few languages have their runtime written in that language, quite a few of them are written in C and so are most mainstream OS's. C is here to stay for a while. Figure another 25 years or so.
Post reply on HN