6 ms·

All the more reason not to rely on security properties of code written in C - I don't have time to read and understand the source of every piece of software I u

by mokus 10y ago

All the more reason not to rely on security properties of code written in C - I don't have time to read and understand the source of every piece of software I use, and popularity is completely useless as a proxy for code quality. Being written in a memory-safe language isn't a silver bullet for all problems, but it actually _is_ a silver bullet for memory corruption problems. Memory corruption problems are a bit like infant mortality in the history of the medical profession - people that live past infancy still died, but infant deaths overwhelmingly impact the historical life expectancy statistics. Let's get our industry past the dark ages so we can start to live longer and begin to tackle more interesting causes of death. EDIT: fixed very silly typo (which I'm really surprised i wasn't instantly called on - it basically made me say I wasn't willing to understand my own code. thanks for the generous reading!)

Sir_Cmpwn 10y ago
There are plenty of codebases (including large ones) written in C that have a low number of vulnerabilities, even compared to projects written in higher level languages (setting aside Rust et al because they aren't that popular yet). It requires discipline and care, but it's not impossible or even that hard if you're a skilled C programmer. OpenSSL has louder vulnerabilities than most software because it's (1) very old, (2) very bad code, and (3) relied upon by heaps of software. There are lots of things wrong with OpenSSL, and those are the reasons that it's vulnerable. We should address the real issues instead of using C as a scapegoat.
- pjmlp 10y ago
  > It requires discipline and care, but it's not impossible or even that hard if you're a skilled C programmer. I have been reading about this mythical "skilled C programmer" since I got to learn C in 1993 and eventually joined C++ ranks instead, leaving my favorite Turbo Pascal behind. Never met one to this day, but fixed lots of memory corruption issues left behind by not so skilled ones, during the days I used to work daily with C and C++ codebases.
  - nickpsecurity 10y ago
    We know they exist. Bernstein and Cutler are two probables based on reviews of their code. Thing is, these people are mentally not even human: it's like Human++ in terms of technical proficiency. So, maybe skilled C programmers only exist among the super-humans. ;)
- mokus 10y ago
  That is absolutely true and I don't disagree that it is possible to write C securely. But I would contend that the statistics you mention reflect differences in programmer attitudes and skill, and should be controlled for in any comparison. The same level of care and skill in another language will very likely lead to even fewer vulnerabilities, as long as that language doesn't have its own even worse foot-guns. The priorities of the language are just different. When I use C, I get fairly decent performance basically for free, but I have to work and maintain discipline to obtain safety, high-level abstractions, etc. I'd much rather work in a language where I get memory safety and basic type-sanity checks for free and have to work for performance. This should really be the default, as it's much more in line with the end-user's needs. When I vet software, it's extremely easy to tell whether it is performant, but it takes serious auditing in C to tell whether it is even memory-safe, let alone actually correct and relatively free of side-channels, etc. The thing about memory safety is that it can be compromised almost anywhere in your code. Your attack surface compared to what _should_ be exposed to attackers is incredibly large. If I can trust the memory-safety of a codebase I am auditing, I don't have to spend nearly as much time on it because I can focus on the parts that actually deal with the intended purpose of the code rather than having to go through every allocation and every memory access in the entire codebase with a fine-toothed comb. Why do we continue to prefer a language where it's easy to achieve the only goal that is obvious when not achieved, at the expense of requiring great care and discipline 100% of the time in order to not instantly and fully compromise the harder-to-evaluate goals that actually matter (especially in security-oriented software such as openssl)? In this case, bad buffer handling in a data structure deserializer gave attackers a free ride past man-years (perhaps man-centuries) of work writing and auditing security-critical code. Surely it'd be better if these kinds of failures were at least interesting rather than an endless parade of careless mistakes that could literally have been caught by trivial automation in the compiler. Especially when there are so many good compilers for so many good languages that already do it.
  - mokus 10y ago
    Oops, forgot to make the explicit connection to your comment - the TL;DR is really the last paragraph. OpenSSL is a beautiful case study in this. If it were written in a memory-safe language, you're right that many things would still be wrong with it - the author(s) very well may have botched "heartbleed" anyway with their custom allocator, but the parade of other buffer handling errors would not have been exploitable except potentially as denials of service. The weaknesses would have at least been interesting (and less numerous, all other things being equal).
- kbenson 10y ago
  There are plenty of freeways with speeding/puddle jumping drivers that have a low number of crashes, even compared to slower drivers (setting aside AI drivers, as they aren't that popular yet). It requires discipline and care, but it's not impossible or even that hard if you're a skilled driver at speed. Old cars have more accidents than not because they are (1) very old, (2) very poor parts, and (3) there are lots of them out there. There are lots of things wrong with old cars, and those are the reasons that they have accidents. We should address the real issues instead of using speeding drivers as a scapegoat.
  - nickpsecurity 10y ago
    I thought I was being clever. This is so well-written I can't tell if you're agreeing with C opponents, mocking them, or baiting someone like me into writing a comment like... Moving on. Wait, I'll drop the usual... http://pastebin.com/UAQaWuWG http://pastebin.com/UAQaWuWG ...then exit "like a smooth criminal."
    - kbenson 10y ago
      I think the problem is partly with unsafe equipment, and partly with people that in seeking to go just a little faster, or get a little more of a thrill, make things quite a bit less safe for all those around them. To some degree, we all do this in different parts of our lives. People tend to vastly overestimate their ability to sustain high output, if not in one area (defensive coding) then in others (driving, procrastination, etc). Some of these affect the people around you more than others. To clarify my original comment somewhat, I was talking less about general speeding of a few miles over the speed limit, and more about those people that are going significantly faster than surrounding traffic and weaving in and out of it to advance (puddle jumping). I do not enjoy having my chance of an accident increased my many orders of magnitude because of someone else's (impossible!) sense of competency, and I think that's very relevant in these discussions.
      - nickpsecurity 10y ago
        That's very interesting. I agree that effect is there. Passing down incorrect cultural knowledge about C is another I counter with my Pastebin. There's others like SPARK, Rust, and ATS countering concept that safety equals too slow or nothing low-level. Many things. Back to your analogy, it seemed to start with both types of drivers: IBM vs Burroughs; C vs Wirth languages. The puddle jumper style got pretty popular with most roads and Interstates being built between their cities. The safer drivers have to be on those roads, too, but fewer in number since "Move Fast and Break Things" wasn't popular with small town folk. Got to point that majority of traffic and causes of accidents are puddle jumpers who mostly don't see their cars and driving styles are the problem. And now we gotta find a way to re-design roads and cars to make their style less damaging while encouraging others to drive more wisely. Wow, put it in your analogy and I suddenly have less hope. ;)

by mokus 10y ago

Sir_Cmpwn 10y ago

There are plenty of codebases (including large ones) written in C that have a low number of vulnerabilities, even compared to projects written in higher level languages (setting aside Rust et al because they aren't that popular yet). It requires discipline and care, but it's not impossible or even that hard if you're a skilled C programmer. OpenSSL has louder vulnerabilities than most software because it's (1) very old, (2) very bad code, and (3) relied upon by heaps of software. There are lots of things wrong with OpenSSL, and those are the reasons that it's vulnerable. We should address the real issues instead of using C as a scapegoat.

pjmlp 10y ago
> It requires discipline and care, but it's not impossible or even that hard if you're a skilled C programmer. I have been reading about this mythical "skilled C programmer" since I got to learn C in 1993 and eventually joined C++ ranks instead, leaving my favorite Turbo Pascal behind. Never met one to this day, but fixed lots of memory corruption issues left behind by not so skilled ones, during the days I used to work daily with C and C++ codebases.
- nickpsecurity 10y ago
  We know they exist. Bernstein and Cutler are two probables based on reviews of their code. Thing is, these people are mentally not even human: it's like Human++ in terms of technical proficiency. So, maybe skilled C programmers only exist among the super-humans. ;)
mokus 10y ago
That is absolutely true and I don't disagree that it is possible to write C securely. But I would contend that the statistics you mention reflect differences in programmer attitudes and skill, and should be controlled for in any comparison. The same level of care and skill in another language will very likely lead to even fewer vulnerabilities, as long as that language doesn't have its own even worse foot-guns. The priorities of the language are just different. When I use C, I get fairly decent performance basically for free, but I have to work and maintain discipline to obtain safety, high-level abstractions, etc. I'd much rather work in a language where I get memory safety and basic type-sanity checks for free and have to work for performance. This should really be the default, as it's much more in line with the end-user's needs. When I vet software, it's extremely easy to tell whether it is performant, but it takes serious auditing in C to tell whether it is even memory-safe, let alone actually correct and relatively free of side-channels, etc. The thing about memory safety is that it can be compromised almost anywhere in your code. Your attack surface compared to what _should_ be exposed to attackers is incredibly large. If I can trust the memory-safety of a codebase I am auditing, I don't have to spend nearly as much time on it because I can focus on the parts that actually deal with the intended purpose of the code rather than having to go through every allocation and every memory access in the entire codebase with a fine-toothed comb. Why do we continue to prefer a language where it's easy to achieve the only goal that is obvious when not achieved, at the expense of requiring great care and discipline 100% of the time in order to not instantly and fully compromise the harder-to-evaluate goals that actually matter (especially in security-oriented software such as openssl)? In this case, bad buffer handling in a data structure deserializer gave attackers a free ride past man-years (perhaps man-centuries) of work writing and auditing security-critical code. Surely it'd be better if these kinds of failures were at least interesting rather than an endless parade of careless mistakes that could literally have been caught by trivial automation in the compiler. Especially when there are so many good compilers for so many good languages that already do it.
- mokus 10y ago
  Oops, forgot to make the explicit connection to your comment - the TL;DR is really the last paragraph. OpenSSL is a beautiful case study in this. If it were written in a memory-safe language, you're right that many things would still be wrong with it - the author(s) very well may have botched "heartbleed" anyway with their custom allocator, but the parade of other buffer handling errors would not have been exploitable except potentially as denials of service. The weaknesses would have at least been interesting (and less numerous, all other things being equal).
kbenson 10y ago
There are plenty of freeways with speeding/puddle jumping drivers that have a low number of crashes, even compared to slower drivers (setting aside AI drivers, as they aren't that popular yet). It requires discipline and care, but it's not impossible or even that hard if you're a skilled driver at speed. Old cars have more accidents than not because they are (1) very old, (2) very poor parts, and (3) there are lots of them out there. There are lots of things wrong with old cars, and those are the reasons that they have accidents. We should address the real issues instead of using speeding drivers as a scapegoat.
- nickpsecurity 10y ago
  I thought I was being clever. This is so well-written I can't tell if you're agreeing with C opponents, mocking them, or baiting someone like me into writing a comment like... Moving on. Wait, I'll drop the usual... http://pastebin.com/UAQaWuWG http://pastebin.com/UAQaWuWG ...then exit "like a smooth criminal."
  - kbenson 10y ago
    I think the problem is partly with unsafe equipment, and partly with people that in seeking to go just a little faster, or get a little more of a thrill, make things quite a bit less safe for all those around them. To some degree, we all do this in different parts of our lives. People tend to vastly overestimate their ability to sustain high output, if not in one area (defensive coding) then in others (driving, procrastination, etc). Some of these affect the people around you more than others. To clarify my original comment somewhat, I was talking less about general speeding of a few miles over the speed limit, and more about those people that are going significantly faster than surrounding traffic and weaving in and out of it to advance (puddle jumping). I do not enjoy having my chance of an accident increased my many orders of magnitude because of someone else's (impossible!) sense of competency, and I think that's very relevant in these discussions.
    - nickpsecurity 10y ago
      That's very interesting. I agree that effect is there. Passing down incorrect cultural knowledge about C is another I counter with my Pastebin. There's others like SPARK, Rust, and ATS countering concept that safety equals too slow or nothing low-level. Many things. Back to your analogy, it seemed to start with both types of drivers: IBM vs Burroughs; C vs Wirth languages. The puddle jumper style got pretty popular with most roads and Interstates being built between their cities. The safer drivers have to be on those roads, too, but fewer in number since "Move Fast and Break Things" wasn't popular with small town folk. Got to point that majority of traffic and causes of accidents are puddle jumpers who mostly don't see their cars and driving styles are the problem. And now we gotta find a way to re-design roads and cars to make their style less damaging while encouraging others to drive more wisely. Wow, put it in your analogy and I suddenly have less hope. ;)