8 ms·

Software Engineering Institute Makes CERT C++ Coding Standard Freely Available

179 points by BudVVeezer 10y ago

brakmic 10y ago
http://www.cert.org/downloads/secure-coding/assets/sei-cert-cpp-coding-standard-2016-v01.pdf http://www.cert.org/downloads/secure-coding/assets/sei-cert-...
- Jare 10y ago
  Note to self: always check the thread before digging up this kind of stuff myself. Thanks!
- rezzo 10y ago
  The SEI CERT C Coding Standard previously released: http://www.sei.cmu.edu/downloads/sei-cert-c-coding-standard-2016-v01.pdf http://www.sei.cmu.edu/downloads/sei-cert-c-coding-standard-...
Cyph0n 10y ago
To anyone experienced with CERT C++: are there rules in the standard that are critical for secure code, but not easy to discover without extensive experience? For instance, I went through the I/O section, and most of the rules seem quite intuitive even to a novice C++ programmer like myself.
- wyldfire 10y ago
  I've not got experience w/CERT C++, so caveats. IMO, the major utility in releasing these guidelines publicly is that developers of clang-tidy and other open source static checkers can freely access the guides that will allow them to check for compliance. Kudos to the SEI.
- BudVVeezer 10y ago
  What's considered critical or difficult to discover is a bit subjective, but: It's easy to forget that alignment is important on some architectures (other than for performance reasons), so be careful when using placement new: https://www.securecoding.cert.org/confluence/display/cplusplus/MEM54-CPP.+Provide+placement+new+with+properly+aligned+pointers+to+sufficient+storage+capacity https://www.securecoding.cert.org/confluence/display/cpluspl... This may seem obvious, but even the C++ committee got this one wrong when they created auto_ptr (which has since been removed from the standard): https://www.securecoding.cert.org/confluence/display/cplusplus/OOP58-CPP.+Copy+operations+must+not+mutate+the+source+object https://www.securecoding.cert.org/confluence/display/cpluspl... This one is totally obvious but has a stunning number of ways you can fail to adhere to it, some of which look reasonable at first blush: https://www.securecoding.cert.org/confluence/display/cplusplus/EXP54-CPP.+Do+not+access+an+object+outside+of+its+lifetime https://www.securecoding.cert.org/confluence/display/cpluspl...
  - duneroadrunner 9y ago
    > This one is totally obvious but has a stunning number of ways you can fail to adhere to it, some of which look reasonable at first blush If memory safety is actually important to you, there's now an actual practical solution: SaferCPlusPlus[1]. A tool to automatically retrofit memory safety to existing C/C++ code is in early development (but resources are limited so it might be a while). [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
- hermitdev 9y ago
  I've not read through the CERT C++ rules (yet), but I highly recommend reading "Secure Coding in C and C++" [0]. Expectedly, there's a good discussion on bounds checking. But, nearly half the book is dedicated to integer underflow/overflow (and signed/unsigned) issues (which most devs either ignore or are oblivious to). It's not a panacea, but if you're write C/C++ without thinking about security and how things can go wrong, it can be a real eye opener. [0] https://www.amazon.com/Secure-Coding-2nd-Software-Engineering/dp/0321822137/ https://www.amazon.com/Secure-Coding-2nd-Software-Engineerin...
  - duneroadrunner 9y ago
    I haven't read the book. What's the gist of the recommendations for addressing those issues? SaferCPlusPlus addresses the signed/unsigned issue by providing compatible substitutes[1] for "int" and "size_t" that automatically handle it. And it addresses the integer underflow/overflow issue by recommending another compatible "int" substitute[2] and introducing the concept (but not yet the implementation) of "quarantined" types for untrusted input values. [1] https://github.com/duneroadrunner/SaferCPlusPlus#cint-csize_t-and-cbool https://github.com/duneroadrunner/SaferCPlusPlus#cint-csize_... [2] https://github.com/robertramey/safe_numerics https://github.com/robertramey/safe_numerics
    - hermitdev 9y ago
      A lot of it involves techniques for detecting that overflow will occur (without actually doing the computation - because in C/C++, once you've signed overflow, you're already into undefined behavior).
  - nickpsecurity 9y ago
    Just found slides of the integer stuff, too, for anyone without the book. http://www.sis.pitt.edu/jjoshi/courses/IS2620/Spring07/Lecture6.pdf http://www.sis.pitt.edu/jjoshi/courses/IS2620/Spring07/Lectu...
- temac 9y ago
  I'm currently working on a system that had no locking order defined (and no any other proper way to prevent or handle deadlocks) -- and looking at the face of my colleagues when I announced that, a good proportion (maybe even the majority) never heard about that kind of stuff before (and they typically have been programming for >5 years) It disturbed me a little because this is the kind of stuff you learn in school, and they all have been there. Maybe they did not paid enough attention. Given the kind of programs we are writing, I could be rejecting candidates who don't cite deadlocks has a classic problem, and give a locking order as a classic solution to avoid them, even if they are right out of school. All of that to say: IMO "novice" or "experienced" C++ programmer very often bear the risk of not really predicting the ability to write correct and maintainable code, because for the experienced ones, they can very well never have had any serious approach or mentors to get them to a decent mindset, while at the same time a smart and motivated novice can quickly figure out more and more of what matters, given some predispositions, a proper mentor, and/or a project inducing that. If you find some of the CERT rules basic, you will quickly find most of them in that case. However, they are still useful to be used as a checklist, or for programmers who don't care enough about programming, or simply have been busy implementing piles of features in some kind of spaghetti code (and fixing 10% of the resulting bugs during 75% of their time) during a decade, etc.
  - daemin 9y ago
    I get the feeling this comes out of the divide between people treating programming like a craft, and those treating it just as a means to get something working. Those that treat it like a craft aim to understand what they are doing, how to do things better. Those that treat it like "just a job" or a means to an end don't want to know or learn anything beyond what is immediately required to do the task. An example could be using "git push --force" if git push returns with errors
- koja86 9y ago
  I think it is pretty basic but with nice explanations, examples, it's pretty complete and it is free so you can basically hand it to someone willing to learn these things. Some recommendations seem little bit like "don't make mistakes" but still I like it.
a3n 10y ago
And C: http://www.cert.org/news/article.cfm?assetid=465486&article=182&year=2016 http://www.cert.org/news/article.cfm?assetid=465486&article=...
mavam 10y ago
It would be great to see such elaborate guidelines to be accompanied with an integration into a linting tool, such as clang-tidy.
- EliRivers 10y ago
  There are integrations of this and various other coding standards into some commercial tools; I don't recall seeing them in any free tools yet.
- BudVVeezer 9y ago
  Some of these rules are currently in clang-tidy, but the coverage is by no means comprehensive. Patches always welcome. :-)
- hermitdev 9y ago
  I thought there was a checker (based on clang) included by the CPP Core Guidelines [0], but I'm not seeing it there currently. Must have been external. I know I saw a tool that provided partial support, at least for GSL [1] (MS's library support of the the CPP Core Guidelines). [0] https://github.com/isocpp/CppCoreGuidelines https://github.com/isocpp/CppCoreGuidelines [1] https://github.com/microsoft/gsl/ https://github.com/microsoft/gsl/
  - geokon 9y ago
    Maybe I'm misunderstanding your reply, but the GSL is the checker. It adds header constructs that create compile time errors based on bad practices. The whole point is that there is no need for an external tool.
    - stinos 9y ago
      the GSL is the checker Well it's a bunch of headers declaring useful types and functions. If you don't use them the compiler won't complain and nothing is checked. I think the OP means something like static analysis. I found a note in my C++14/17 TODO list where I typed 'clang-tidy might be able to give warnings for pre-c++14 constructs etc, see https://reviews.llvm.org/diffusion/L/browse/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/' https://reviews.llvm.org/diffusion/L/browse/clang-tools-extr.... Don't have time now to figure out what that is, but it's probably what the OP is after.
deleted 10y ago
[deleted]
_pmf_ 9y ago
Pretty sane and modern when compared to other so called safety standards like MISRA that are in fact rules to satisfy proprietary legacy compilers.
deleted 9y ago
[deleted]
sargun 9y ago
I was really hoping the Wikipedia article on Roller Coasters was better. I wanted to write a piece of prose paralleling roller coasters and programming languages, but unfortunately, I have such little info to go on (https://en.wikipedia.org/wiki/Roller_coaster https://en.wikipedia.org/wiki/Roller_coaster). I feel like roller coasters started because people wanted to go fast, and this crazy death contraption was the only way how. Subsequently, ride operators, in order to avoid the death of their patrons, advised them not to stick their limbs outside of the car. Unfortunately, this mechanism only reduced injuries, but far from eliminated them. Not only do accidents occur because of the actions of the riders themselves, but ride operators can pose introduce risk not only by malice, but negligence. In extremely rare cases, riders can be injured by compiler failures. Roller coaster operators soon learned that these contraptions were fundamentally unsafe, and the only way to induce safety was if the systems which drove the coaster had safety as a fundamental concern. Therefore they introduced these things like "PLCs" -- a type of computer to make sure the operators could only do so much to endanger the riders. In addition, by following the basic rules of physics at build time of the coaster they further increased safety. Since people have stopped building coasters that relied on the rider's healthy sense of caution, and the operator's awareness of safety, they've become one of the safest ways to enjoy oneself. Or at least this is how I was hoping the story went.

179 points by BudVVeezer 10y ago

http://www.cert.org/downloads/secure-coding/assets/sei-cert-cpp-coding-standard-2016-v01.pdf http://www.cert.org/downloads/secure-coding/assets/sei-cert-...

Jare 10y ago
Note to self: always check the thread before digging up this kind of stuff myself. Thanks!
rezzo 10y ago
The SEI CERT C Coding Standard previously released: http://www.sei.cmu.edu/downloads/sei-cert-c-coding-standard-2016-v01.pdf http://www.sei.cmu.edu/downloads/sei-cert-c-coding-standard-...

Cyph0n 10y ago

To anyone experienced with CERT C++: are there rules in the standard that are critical for secure code, but not easy to discover without extensive experience? For instance, I went through the I/O section, and most of the rules seem quite intuitive even to a novice C++ programmer like myself.

wyldfire 10y ago
I've not got experience w/CERT C++, so caveats. IMO, the major utility in releasing these guidelines publicly is that developers of clang-tidy and other open source static checkers can freely access the guides that will allow them to check for compliance. Kudos to the SEI.
BudVVeezer 10y ago
What's considered critical or difficult to discover is a bit subjective, but: It's easy to forget that alignment is important on some architectures (other than for performance reasons), so be careful when using placement new: https://www.securecoding.cert.org/confluence/display/cplusplus/MEM54-CPP.+Provide+placement+new+with+properly+aligned+pointers+to+sufficient+storage+capacity https://www.securecoding.cert.org/confluence/display/cpluspl... This may seem obvious, but even the C++ committee got this one wrong when they created auto_ptr (which has since been removed from the standard): https://www.securecoding.cert.org/confluence/display/cplusplus/OOP58-CPP.+Copy+operations+must+not+mutate+the+source+object https://www.securecoding.cert.org/confluence/display/cpluspl... This one is totally obvious but has a stunning number of ways you can fail to adhere to it, some of which look reasonable at first blush: https://www.securecoding.cert.org/confluence/display/cplusplus/EXP54-CPP.+Do+not+access+an+object+outside+of+its+lifetime https://www.securecoding.cert.org/confluence/display/cpluspl...
- duneroadrunner 9y ago
  > This one is totally obvious but has a stunning number of ways you can fail to adhere to it, some of which look reasonable at first blush If memory safety is actually important to you, there's now an actual practical solution: SaferCPlusPlus[1]. A tool to automatically retrofit memory safety to existing C/C++ code is in early development (but resources are limited so it might be a while). [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
hermitdev 9y ago
I've not read through the CERT C++ rules (yet), but I highly recommend reading "Secure Coding in C and C++" [0]. Expectedly, there's a good discussion on bounds checking. But, nearly half the book is dedicated to integer underflow/overflow (and signed/unsigned) issues (which most devs either ignore or are oblivious to). It's not a panacea, but if you're write C/C++ without thinking about security and how things can go wrong, it can be a real eye opener. [0] https://www.amazon.com/Secure-Coding-2nd-Software-Engineering/dp/0321822137/ https://www.amazon.com/Secure-Coding-2nd-Software-Engineerin...
- duneroadrunner 9y ago
  I haven't read the book. What's the gist of the recommendations for addressing those issues? SaferCPlusPlus addresses the signed/unsigned issue by providing compatible substitutes[1] for "int" and "size_t" that automatically handle it. And it addresses the integer underflow/overflow issue by recommending another compatible "int" substitute[2] and introducing the concept (but not yet the implementation) of "quarantined" types for untrusted input values. [1] https://github.com/duneroadrunner/SaferCPlusPlus#cint-csize_t-and-cbool https://github.com/duneroadrunner/SaferCPlusPlus#cint-csize_... [2] https://github.com/robertramey/safe_numerics https://github.com/robertramey/safe_numerics
  - hermitdev 9y ago
    A lot of it involves techniques for detecting that overflow will occur (without actually doing the computation - because in C/C++, once you've signed overflow, you're already into undefined behavior).
- nickpsecurity 9y ago
  Just found slides of the integer stuff, too, for anyone without the book. http://www.sis.pitt.edu/jjoshi/courses/IS2620/Spring07/Lecture6.pdf http://www.sis.pitt.edu/jjoshi/courses/IS2620/Spring07/Lectu...
temac 9y ago
I'm currently working on a system that had no locking order defined (and no any other proper way to prevent or handle deadlocks) -- and looking at the face of my colleagues when I announced that, a good proportion (maybe even the majority) never heard about that kind of stuff before (and they typically have been programming for >5 years) It disturbed me a little because this is the kind of stuff you learn in school, and they all have been there. Maybe they did not paid enough attention. Given the kind of programs we are writing, I could be rejecting candidates who don't cite deadlocks has a classic problem, and give a locking order as a classic solution to avoid them, even if they are right out of school. All of that to say: IMO "novice" or "experienced" C++ programmer very often bear the risk of not really predicting the ability to write correct and maintainable code, because for the experienced ones, they can very well never have had any serious approach or mentors to get them to a decent mindset, while at the same time a smart and motivated novice can quickly figure out more and more of what matters, given some predispositions, a proper mentor, and/or a project inducing that. If you find some of the CERT rules basic, you will quickly find most of them in that case. However, they are still useful to be used as a checklist, or for programmers who don't care enough about programming, or simply have been busy implementing piles of features in some kind of spaghetti code (and fixing 10% of the resulting bugs during 75% of their time) during a decade, etc.
- daemin 9y ago
  I get the feeling this comes out of the divide between people treating programming like a craft, and those treating it just as a means to get something working. Those that treat it like a craft aim to understand what they are doing, how to do things better. Those that treat it like "just a job" or a means to an end don't want to know or learn anything beyond what is immediately required to do the task. An example could be using "git push --force" if git push returns with errors
koja86 9y ago
I think it is pretty basic but with nice explanations, examples, it's pretty complete and it is free so you can basically hand it to someone willing to learn these things. Some recommendations seem little bit like "don't make mistakes" but still I like it.

a3n 10y ago

And C: http://www.cert.org/news/article.cfm?assetid=465486&article=182&year=2016 http://www.cert.org/news/article.cfm?assetid=465486&article=...

mavam 10y ago

It would be great to see such elaborate guidelines to be accompanied with an integration into a linting tool, such as clang-tidy.

EliRivers 10y ago
There are integrations of this and various other coding standards into some commercial tools; I don't recall seeing them in any free tools yet.
BudVVeezer 9y ago
Some of these rules are currently in clang-tidy, but the coverage is by no means comprehensive. Patches always welcome. :-)
hermitdev 9y ago
I thought there was a checker (based on clang) included by the CPP Core Guidelines [0], but I'm not seeing it there currently. Must have been external. I know I saw a tool that provided partial support, at least for GSL [1] (MS's library support of the the CPP Core Guidelines). [0] https://github.com/isocpp/CppCoreGuidelines https://github.com/isocpp/CppCoreGuidelines [1] https://github.com/microsoft/gsl/ https://github.com/microsoft/gsl/
- geokon 9y ago
  Maybe I'm misunderstanding your reply, but the GSL is the checker. It adds header constructs that create compile time errors based on bad practices. The whole point is that there is no need for an external tool.
  - stinos 9y ago
    the GSL is the checker Well it's a bunch of headers declaring useful types and functions. If you don't use them the compiler won't complain and nothing is checked. I think the OP means something like static analysis. I found a note in my C++14/17 TODO list where I typed 'clang-tidy might be able to give warnings for pre-c++14 constructs etc, see https://reviews.llvm.org/diffusion/L/browse/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/' https://reviews.llvm.org/diffusion/L/browse/clang-tools-extr.... Don't have time now to figure out what that is, but it's probably what the OP is after.

deleted 10y ago

[deleted]

_pmf_ 9y ago

Pretty sane and modern when compared to other so called safety standards like MISRA that are in fact rules to satisfy proprietary legacy compilers.

deleted 9y ago

[deleted]

sargun 9y ago

I was really hoping the Wikipedia article on Roller Coasters was better. I wanted to write a piece of prose paralleling roller coasters and programming languages, but unfortunately, I have such little info to go on (https://en.wikipedia.org/wiki/Roller_coaster https://en.wikipedia.org/wiki/Roller_coaster). I feel like roller coasters started because people wanted to go fast, and this crazy death contraption was the only way how. Subsequently, ride operators, in order to avoid the death of their patrons, advised them not to stick their limbs outside of the car. Unfortunately, this mechanism only reduced injuries, but far from eliminated them. Not only do accidents occur because of the actions of the riders themselves, but ride operators can pose introduce risk not only by malice, but negligence. In extremely rare cases, riders can be injured by compiler failures. Roller coaster operators soon learned that these contraptions were fundamentally unsafe, and the only way to induce safety was if the systems which drove the coaster had safety as a fundamental concern. Therefore they introduced these things like "PLCs" -- a type of computer to make sure the operators could only do so much to endanger the riders. In addition, by following the basic rules of physics at build time of the coaster they further increased safety. Since people have stopped building coasters that relied on the rider's healthy sense of caution, and the operator's awareness of safety, they've become one of the safest ways to enjoy oneself. Or at least this is how I was hoping the story went.