4 ms·
> trained in writing secure C code The hubris here is astonishing. After this many decades, hasn't the entire industry adequately demonstrated that that almost
by prodigal_erik 17y ago
> trained in writing secure C code
The hubris here is astonishing. After this many decades, hasn't the entire industry adequately demonstrated that that almost all programs have mistakes and that most mistakes in C become security flaws? I've contracted there, I've sprinkled some proprietary buffer annotations around their legacy code, and I'm still not convinced that's enough to make unchecked pointers a reasonable way to write apps.
- tptacek 17y agoWe might just as productively argue about politics or religion, but I'll sum my response up by saying that roughly 60% of the apps we assess (assessing app security being my day job, and what the company I cofounded does) have no C in them, and those apps are not "more secure" than the apps with C code. Should "you" write C code? No. You don't have to. You will screw it up in amusing and horrible ways. But don't suggest Microsoft should rewrite Office in Haskell. All that would happen if they did is that we'd learn how to exploit insecure Haskell idioms real fast.
- prodigal_erik 17y agoI get that I could write my security model incorrectly in any language. My objection to C is that unchecked pointers can be used to arbitrarily corrupt parts of the program that would otherwise work correctly. But it sounds like you've found that removing these infamous classes of vulnerabilities doesn't actually help--can you explain why that is?
- tptacek 17y agoBecause there are many other infamous classes of vulnerabilities, many of which are abetted by high-level languages. You don't find a lot of "remote file inclusion"-style flaws in C code, for instance.