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