“When C, C++ and the Internet were conceived, they were mostly used by academics. Attacks on computer systems were rare, since there was not much incentive to it, so there did not have to be a focus on security and robustness. “
Quick mythbust on this. The safety and security problems were known to Ken Thompson at that time since Burroughs already had a secure architecture, Wirth was working on safer languages based on ALGOL, Thompson’s predecessor Richards of BCPL wanted an ALGOL for safety/maintainability, and Thompson himself worked on MULTICS whose kernel was in PL/0 and had security features. Thompson’s use of modified BCPL was purely due to personal preference and hardware limitations of the PDP-7 or PDP-11. They just didn’t care because they were academics as author said. Whereas, Wirth made his language (Modula-2) on a PDP-11/45 safe by default with a SYSTEM (UNSAFE) keyword to turn checks off when necessary. So, we’re in this mess because Thompson just liked BCPL, it worked on his machine, and neither he nor Ritchie cared about safety or security in programming. Apathy is still a prime cause of security problems today.
“Stack protector will be discussed in this post, other techniques will follow: ASLR, NX stack, RELRO/BIND_NOW, Fortify, RPATH/RUNPATH.”
The rest of the article, both intro and stack protector parts, are great. I especially like both the analyses and recommendations to make sure everything is working properly. C/C++ folks should probably subscribe to the next articles as three in that list I don’t see often.
It’s surprisingly better written article than expected. It walks upwards from facts and produces a chain of reasoning.
But.. The propositions to harden with flags seem quite fragile. When you leave a flag away, or if your compiler ignores it, the protections are no longer produced.
Not a nice thing really.
The article does say that you should test that the binaries produced are instrumented, and does mention that doing so is a bit tricky.