8 ms·

The CERT C Secure Coding Standard

86 points by jfe 12y ago

pjmlp 12y ago
Should be compulsory reading for any developer. Not only C, but the other CERT standards as well.
- tormeh 12y ago
  Having a CERT standard seems to speak poorly of a language. I'm a little surprised Java has one.
  - pjmlp 12y ago
    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.
jokoon 12y ago
Can C code be linted according to those rules? I wonder if that kind of coding standards can be part of ISO standards.
- EliRivers 12y ago
  I do some work in the static analysis industry, and it's common to see analyses based on various coding standards, including this one.
- pjmlp 12y ago
  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.
- BudVVeezer 12y ago
  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).
- rcseacord 12y ago
  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 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 http://www.informit.com/articles/article.aspx?p=2088511
azurezyq 12y ago
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?
- pgeorgi 12y ago
  SPARK aims for that since the 80s. http://www.spark-2014.org http://www.spark-2014.org provides information about the current version.
- borplk 12y ago
  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.
  - hga 12y ago
    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/ http://muen.codelabs.ch/
- borplk 12y ago
  Also see here: http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html
- pjmlp 12y ago
  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.
skrebbel 12y ago
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.
- api 12y ago
  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.
  - pgeorgi 12y 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/ 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.
- JulianMorrison 12y ago
  Two use cases where C is often the only choice are OSes and micro-controllers.
  - pjmlp 12y ago
    There are alternatives, depending on the the processor/controller capabilities. http://www.mikroe.com/mikropascal/ http://www.mikroe.com/mikropascal/ http://www.mikroe.com/mikrobasic/ http://www.mikroe.com/mikrobasic/ http://turbo51.com/ http://turbo51.com/ For more beefy systems, http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm http://www.is2t.com/products/ http://www.is2t.com/products/ http://www.atego.com/products/atego-perc-pico/ http://www.atego.com/products/atego-perc-pico/
mkpankov 12y ago
I investigated this Standard once. See https://www.securecoding.cert.org/confluence/display/seccode/EXP05-C.+Do+not+cast+away+a+const+qualification 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".
- bgtnhz 12y ago
  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 12y ago
  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/Rules+versus+Recommendations https://www.securecoding.cert.org/confluence/display/seccode...
- rcseacord 12y ago
  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.
khaki54 12y ago
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/PRE07-C.+Avoid+using+repeated+question+marks https://www.securecoding.cert.org/confluence/display/seccode...
- jacquesm 12y ago
  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.
c0rtex 12y ago
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/presentation/holzmann 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 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/VOID+Automated+Detection+Tools https://www.securecoding.cert.org/confluence/display/seccode...

86 points by jfe 12y ago

pjmlp 12y ago

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

tormeh 12y ago
Having a CERT standard seems to speak poorly of a language. I'm a little surprised Java has one.
- pjmlp 12y ago
  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.

jokoon 12y ago

Can C code be linted according to those rules? I wonder if that kind of coding standards can be part of ISO standards.

EliRivers 12y ago
I do some work in the static analysis industry, and it's common to see analyses based on various coding standards, including this one.
pjmlp 12y ago
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.
BudVVeezer 12y ago
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).
rcseacord 12y ago
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 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 http://www.informit.com/articles/article.aspx?p=2088511

azurezyq 12y ago

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?

pgeorgi 12y ago
SPARK aims for that since the 80s. http://www.spark-2014.org http://www.spark-2014.org provides information about the current version.
borplk 12y ago
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.
- hga 12y ago
  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/ http://muen.codelabs.ch/
borplk 12y ago
Also see here: http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html
pjmlp 12y ago
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.

skrebbel 12y ago

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.

api 12y ago
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.
- pgeorgi 12y 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/ 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.
JulianMorrison 12y ago
Two use cases where C is often the only choice are OSes and micro-controllers.
- pjmlp 12y ago
  There are alternatives, depending on the the processor/controller capabilities. http://www.mikroe.com/mikropascal/ http://www.mikroe.com/mikropascal/ http://www.mikroe.com/mikrobasic/ http://www.mikroe.com/mikrobasic/ http://turbo51.com/ http://turbo51.com/ For more beefy systems, http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm http://www.is2t.com/products/ http://www.is2t.com/products/ http://www.atego.com/products/atego-perc-pico/ http://www.atego.com/products/atego-perc-pico/

mkpankov 12y ago

I investigated this Standard once. See https://www.securecoding.cert.org/confluence/display/seccode/EXP05-C.+Do+not+cast+away+a+const+qualification 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".

bgtnhz 12y ago
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 12y ago
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/Rules+versus+Recommendations https://www.securecoding.cert.org/confluence/display/seccode...
rcseacord 12y ago
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.

khaki54 12y ago

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/PRE07-C.+Avoid+using+repeated+question+marks https://www.securecoding.cert.org/confluence/display/seccode...

jacquesm 12y ago
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.

c0rtex 12y ago

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/presentation/holzmann 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 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/VOID+Automated+Detection+Tools https://www.securecoding.cert.org/confluence/display/seccode...