The CERT C Secure Coding Standard | Hacker News Reader

The CERT C Secure Coding Standard

securecoding.cert.org

86 pointsjfe31 comments

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.

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

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?

SPARK aims for that since the 80s. http://www.spark-2014.org provides information about the current version.

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/

Also see here: http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html

The likes of Modula-2 (1978), Ada (1983), Modula-2+(1985), Modula-3 (1986), Oberon (1986).

The problem is that they were tied to OS that weren't successful in the mainstream, whereas some American startups using the original BSD code and AT&T licenses, got very successful and brought UNIX into the enterprise.

C came along of course.

Can C code be linted according to those rules?

I wonder if that kind of coding standards can be part of ISO standards.

I do some work in the static analysis industry, and it's common to see analyses based on various coding standards, including this one.

Yes, but it is above all a culture problem.

Many developers think that they don't need static analyzers.

Actually lint was part of the original UNIX, but since it took some effort to configure and not everyone agreed with the rules, it was seldom ported to other systems, and it became part of the C culture not to use it.

I think we have to thank the LLVM project that now static analyzers are welcome in C.

It can, and it is. One of the outcomes of the CERT C secure coding standard was the publication of TS 17961, which is an ISO document on C analyzability, which also went hand in hand with the Annex L (normative) section of the C standard.

Basically, the CERT rules all must be analyzable (though some require dynamic analysis instead of static analysis).

We did actually produce ISO/IEC TS 17961:2013 Information technology -- Programming languages, their environments and system software interfaces -- C secure coding rules http://www.iso.org/iso/catalogue_detail.htm?csnumber=61134

The rules specified in this Technical Specification apply to analyzers, including static analysis tools and C language compiler vendors that wish to diagnose insecure code beyond the requirements of the language standard. All rules are meant to be enforceable by static analysis.

I wrote an article putting all this in some context at: http://www.informit.com/articles/article.aspx?p=2088511

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

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.

BudVVeezer and bgtnhz have already made some of my points for me. "EXP05-C. Do not cast away a const qualification" is a recommendation largely because casting away constness isn't undefined behavior. There is a also a rule "EXP40-C. Do not modify constant objects" which defines a normative requirement not to modify constant objects which would result in undefined behavior. The intent of the exception to EXP05-C is to let authors of API constrain how objects of types they expose can be used by users without forcing the same constraints on the implementation. In C++, this can be done by making class members private and providing inline member functions. In C, the options are using opaque types (which has a performance cost because they can only be accessed by non-inline functions defined in the implementation's .c files), or making the struct pointer members const and casting the const away in inline functions. This is safe because the implementer knows that the objects the const pointers do not point to const objects (because the implementation initialized them). We're considering getting rid of the exceptions and risk assessments for recommendations because it suggests that conformance to recommendations is required.

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.

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 options than C.

I wish you were right, but C is still the only way to hit all platforms with a good product. It also still rules performance, which does matter in some cases.

Hopefully this won't still be true in 10 years. Hopefully. But I was hopeful about that 10 yers ago.

Ada is about as portable as C, given that both are implemented as gcc frontends.

For performance, the type-safe SPARK Skein implementation (http://www.adacore.com/press/spark-skein/) matches the C implementation, after the optimizer phases in the compiler were matched up. While doing the translation from C, they even uncovered a bug in the C implementation.

Anecdata, sure, but that's mostly a popularity issue.

Two use cases where C is often the only choice are OSes and micro-controllers.

There are alternatives, depending on the the processor/controller capabilities.

http://www.mikroe.com/mikropascal/

http://www.mikroe.com/mikrobasic/

http://turbo51.com/

For more beefy systems,

http://www.astrobe.com/default.htm

http://www.is2t.com/products/

http://www.atego.com/products/atego-perc-pico/

Indeed. C (and, to a limited degree C++) are natural choice(s) for embedded and low-level development.

In embedded, there may be other language choices for coding "close to the metal", but they are rarely used, time-costly to work with, and often not well-supported for all platforms. Most micro-controller vendors supply their board-support packages (BSPs) in C, and choosing some other family of (higher level than assembly) language can result in some rather high development costs with few if any benefits in terms of code space or system efficiency.

Not to mention many higher-level languages (and, at least, their compilers or interpreters) are implemented in C (or C++) - Ruby, Python, Lua, etc. Even if one works on desktop applications or web development, C has importance, very likely, at some level in the technology stack.

Those that dismiss C either misunderstand the importance and ubiquity of it as a language and/or inadvertently expose their prejudice towards development at higher levels of abstraction. In any case, C is very likely here to stay, good to know well, and good to know how to code more securely.

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.

You are missing the point. C is only for system programming which is insecure by definition.

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.

Reply on news.ycombinator.com