9 ms·

From a security perspective, C is inadequate. This is the biggest issue facing our use of the language currently.

by willtim 10y ago

jstewartmobile 10y ago
From a security perspective, if you think C is inadequate, try taking a look at the instruction set docs for one of Intel or AMD's semi-modern chips. ;-)
- yxhuvud 10y ago
  That is not an excuse. Defence in depth is a thing.
  - jstewartmobile 10y ago
    If you're building on a sinkhole, I don't see how having really nice floors helps.
    - platz 10y ago
      I don't see how the chip's 'sinkhole' enabled bugs like heartbleed, which was industry-scale, which absolutely could've been prevented by having a really nice floor.
    - jstewartmobile 10y ago
      You can fix heartbleed--even in C. You can't fix TPM hacks, rowhammer, etc. without buying a new machine. That's not even getting into the potential of the missteps in the RMM / MMU / SMP / virt systems that exasperate even Torvalds and deRaadt.
      - sitkack 10y ago
        You are making an all or none fallacy. While those things do exist, we can't use them as an excuse to prevent the common case.
        jstewartmobile 10y ago
        I'm not making any kind of fallacy here. The chipset is the foundation. Even with perfect programs written in perfect languages, the Mossad can still get whatever they want without breaking a sweat thanks to the silicon. If we were going to set priorities for making things "better," the foundation would be the reasonable place to start. We'd probably be happy with Algol if we were running it on B5000-style hardware.
        joncampbelldev 10y ago
        It sounds like you mean that stopping the vast numbers of lesser attackers other than Mossad is so much less important that its worth ignoring. Most people's day to day experience of vulnerabilities is someone getting access to their password or (for the techies) their private server. Stupid actions aside (like leaving a database open to the internet), it'd be nice if things like heartbleed weren't so prolific. Perhaps when we're living in a dystopian facist state we will wish we started out by fixing the hardware vulns, but until then it'd be nice if, for example, a person who has setup ssl correctly can assume it won't leak data all over the place.
        jstewartmobile 10y ago
        Never said to ignore anything. I'm just outlining priorities. With things like rowhammer, you don't have to be Mossad to exploit it, and you can't apt-get or windows update your way around it. From your own examples, better languages can only do so much.
    - MaulingMonkey 10y ago
      No point in building elsewhere if any earthquake will cause the structure to collapse, killing everyone inside, even on more solid ground. I'd love for chip design to be the weak point for once. Let's make it happen.
- nickpsecurity 10y ago
  Cornell did that. They saw horrible things. Then, they fixed the root cause: https://www.cs.cornell.edu/talc/ https://www.cs.cornell.edu/talc/ Did something similar with C in Popcorn: a safe, C dialect that compiles to TALC. Gotta wonder what things would be like if more groups took such an approach to the problems they've found in C, UNIX, etc. Well, it was a nice vision at least. :)
  - emmelaich 10y ago
    I followed the web search links to Cyclone, Popcorn's successor and ended up at http://www.eecs.harvard.edu/~greg/cyclone/ http://www.eecs.harvard.edu/~greg/cyclone/ which is a 404. Which suggests how popular these safe C's are, regrettably.
    - nickpsecurity 10y ago
      Yep. How it always goes. Fortunately, Cyclones region and dynamic safety helped inspire Rust's scheme. It went somewhere even if not for C programmers in general. Far as also-rans, there's Microsoft's Vault, FLINT's C0 used in Verisoft for whole-system verification, and Clay that's mainly applied by Lea Wittie in stuff like device drivers. https://web.archive.org/web/20080219014100/http://research.microsoft.com/vault/ https://web.archive.org/web/20080219014100/http://research.m... http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.468.2032&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.468... http://www.verisoft.de/VerisoftRepository.html http://www.verisoft.de/VerisoftRepository.html http://www.eg.bucknell.edu/~lwittie/research/Clay.pdf http://www.eg.bucknell.edu/~lwittie/research/Clay.pdf http://www.eg.bucknell.edu/~lwittie/research.html http://www.eg.bucknell.edu/~lwittie/research.html
Annatar 10y ago
From a security perspective, C is inadequate. The implication here being that Rust is adequate, I take it? Let us not circle around the issue! You could assert the same for assembler, and yet, assembler is the ultimate programming - the last stop: highest performance, maximum control, no safety. When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security? I could think of no language more adequate to push the electronics to their limit, and beyond, as Commodore 64 teaches us over and over again, even in 2016. All I want to say is that your argument rings hollow. Yes, C has no safety. If my code has a hole, it will be noone's fault but my own. And that's the way I like it: it is far more preferable to an ultracomplex programming language like Rust. And finally, a Zen koan: I was troubleshooting some code today, which I wrote in AWK. Now the code transformed the data exactly as I had coded it, and the code was 100% correct, the transformed data was exactly as expected, yet no output was coming out. Everything which was in the program was 100% correct. The problem wasn't in that which was in the program, but that which was not: there was no clause to output the transformed data. There is enlightment to be had from this tale, specifically about security, and even more specifically about Rust the programming language and its compiler.
- naasking 10y ago
  > When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security? All the time. Virtually no one would recommend writing any serious software in assembler. The only software written in assembler is high performance numerical code and certain hardware-specific kernel device drivers. > If my code has a hole, it will be noone's fault but my own. And who's going to hold you accountable for that hole that just leaked 100,000 credit card numbers? No one, that's who. The institutional bias against safety and the insulation programmers enjoy from the consequences of their code are the only reason attitudes like yours persist, and the trivial security bugs that inevitably follow. > And that's the way I like it: it is far more preferable to an ultracomplex programming language like Rust. Rust the language is not ultracomplex. Don't confuse the language with the compiler.
  - pekk 10y ago
emmelaich 10y ago
From a speed and control perspective, nothing else is adequate. The best we can hope for in the medium term (20 years?) is to have C as a target / intermediate / escape (ie. FFI) language.

From a security perspective, C is inadequate. This is the biggest issue facing our use of the language currently.

by willtim 10y ago

From a security perspective, C is inadequate. This is the biggest issue facing our use of the language currently.

From a security perspective, if you think C is inadequate, try taking a look at the instruction set docs for one of Intel or AMD's semi-modern chips. ;-)

yxhuvud 10y ago
That is not an excuse. Defence in depth is a thing.
- jstewartmobile 10y ago
  If you're building on a sinkhole, I don't see how having really nice floors helps.
  - platz 10y ago
    I don't see how the chip's 'sinkhole' enabled bugs like heartbleed, which was industry-scale, which absolutely could've been prevented by having a really nice floor.
  - jstewartmobile 10y ago
    You can fix heartbleed--even in C. You can't fix TPM hacks, rowhammer, etc. without buying a new machine. That's not even getting into the potential of the missteps in the RMM / MMU / SMP / virt systems that exasperate even Torvalds and deRaadt.
    - sitkack 10y ago
      You are making an all or none fallacy. While those things do exist, we can't use them as an excuse to prevent the common case.
      - jstewartmobile 10y ago
        I'm not making any kind of fallacy here. The chipset is the foundation. Even with perfect programs written in perfect languages, the Mossad can still get whatever they want without breaking a sweat thanks to the silicon. If we were going to set priorities for making things "better," the foundation would be the reasonable place to start. We'd probably be happy with Algol if we were running it on B5000-style hardware.
        joncampbelldev 10y ago
        It sounds like you mean that stopping the vast numbers of lesser attackers other than Mossad is so much less important that its worth ignoring. Most people's day to day experience of vulnerabilities is someone getting access to their password or (for the techies) their private server. Stupid actions aside (like leaving a database open to the internet), it'd be nice if things like heartbleed weren't so prolific. Perhaps when we're living in a dystopian facist state we will wish we started out by fixing the hardware vulns, but until then it'd be nice if, for example, a person who has setup ssl correctly can assume it won't leak data all over the place.
        jstewartmobile 10y ago
        Never said to ignore anything. I'm just outlining priorities. With things like rowhammer, you don't have to be Mossad to exploit it, and you can't apt-get or windows update your way around it. From your own examples, better languages can only do so much.
  - MaulingMonkey 10y ago
    No point in building elsewhere if any earthquake will cause the structure to collapse, killing everyone inside, even on more solid ground. I'd love for chip design to be the weak point for once. Let's make it happen.
nickpsecurity 10y ago
Cornell did that. They saw horrible things. Then, they fixed the root cause: https://www.cs.cornell.edu/talc/ https://www.cs.cornell.edu/talc/ Did something similar with C in Popcorn: a safe, C dialect that compiles to TALC. Gotta wonder what things would be like if more groups took such an approach to the problems they've found in C, UNIX, etc. Well, it was a nice vision at least. :)
- emmelaich 10y ago
  I followed the web search links to Cyclone, Popcorn's successor and ended up at http://www.eecs.harvard.edu/~greg/cyclone/ http://www.eecs.harvard.edu/~greg/cyclone/ which is a 404. Which suggests how popular these safe C's are, regrettably.
  - nickpsecurity 10y ago
    Yep. How it always goes. Fortunately, Cyclones region and dynamic safety helped inspire Rust's scheme. It went somewhere even if not for C programmers in general. Far as also-rans, there's Microsoft's Vault, FLINT's C0 used in Verisoft for whole-system verification, and Clay that's mainly applied by Lea Wittie in stuff like device drivers. https://web.archive.org/web/20080219014100/http://research.microsoft.com/vault/ https://web.archive.org/web/20080219014100/http://research.m... http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.468.2032&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.468... http://www.verisoft.de/VerisoftRepository.html http://www.verisoft.de/VerisoftRepository.html http://www.eg.bucknell.edu/~lwittie/research/Clay.pdf http://www.eg.bucknell.edu/~lwittie/research/Clay.pdf http://www.eg.bucknell.edu/~lwittie/research.html http://www.eg.bucknell.edu/~lwittie/research.html

Annatar 10y ago

From a security perspective, C is inadequate. The implication here being that Rust is adequate, I take it? Let us not circle around the issue! You could assert the same for assembler, and yet, assembler is the ultimate programming - the last stop: highest performance, maximum control, no safety. When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security? I could think of no language more adequate to push the electronics to their limit, and beyond, as Commodore 64 teaches us over and over again, even in 2016. All I want to say is that your argument rings hollow. Yes, C has no safety. If my code has a hole, it will be noone's fault but my own. And that's the way I like it: it is far more preferable to an ultracomplex programming language like Rust. And finally, a Zen koan: I was troubleshooting some code today, which I wrote in AWK. Now the code transformed the data exactly as I had coded it, and the code was 100% correct, the transformed data was exactly as expected, yet no output was coming out. Everything which was in the program was 100% correct. The problem wasn't in that which was in the program, but that which was not: there was no clause to output the transformed data. There is enlightment to be had from this tale, specifically about security, and even more specifically about Rust the programming language and its compiler.

naasking 10y ago
> When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security? All the time. Virtually no one would recommend writing any serious software in assembler. The only software written in assembler is high performance numerical code and certain hardware-specific kernel device drivers. > If my code has a hole, it will be noone's fault but my own. And who's going to hold you accountable for that hole that just leaked 100,000 credit card numbers? No one, that's who. The institutional bias against safety and the insulation programmers enjoy from the consequences of their code are the only reason attitudes like yours persist, and the trivial security bugs that inevitably follow. > And that's the way I like it: it is far more preferable to an ultracomplex programming language like Rust. Rust the language is not ultracomplex. Don't confuse the language with the compiler.
- pekk 10y ago

emmelaich 10y ago

From a speed and control perspective, nothing else is adequate. The best we can hope for in the medium term (20 years?) is to have C as a target / intermediate / escape (ie. FFI) language.