7 ms·

No need to panic, nobody is coming to take your precious pointer arithmetic away. If you want to write unsafe code, go ahead. But we also have to acknowledge th

by gizmo 11y ago

No need to panic, nobody is coming to take your precious pointer arithmetic away. If you want to write unsafe code, go ahead. But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. We're talking about classes of security bugs that just don't exist in managed languages. Bugs that can't happen in languages like Rust either because it forces programmers to indicate ownership and lifetime of memory. There's always a trade-off between performance and security, but with better tooling support the price for secure code will be very low. Right now security is bad because we look at security as a feature. As something that is added to a project, instead of as something that guides the entire design. Your suggestion that static analysis can fix this is wildly optimistic, because C/C++ code for a modern browser uses memory pools, pointer arithmetic, just-in-time compilation, and shared memory between object instances, threads and processes and so on. It's hugely complex, and correctness can't be verified with some sort of static analyzer or with added runtime checks.

monochr 11y ago
>But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. You can't write safe code in any Turing complete language. That's the whole point of Turing completeness. The only reason why memory attacks are as common as they are is because C like languages are the most popular ones. If we replaced everything written with C to a "safe" language like, I don't know Haskell?, we'd have just as many zero day exploits of the monads within programs.
- chriswarbo 11y ago
  > If we replaced everything written with C to a "safe" language like, I don't know Haskell?, we'd have just as many zero day exploits of the monads within programs. I disagree. There will always be security issues, due to (ab)uses that developers didn't consider, but there can be different probabilities. Requiring developers to learn about language gotchas, remember those gotchas when coding, and jump through hoops to avoid them, just stacks the odds against us.
- gizmo 11y ago
  There is a huge difference between a program that computes the wrong answer and one that corrupts memory, hijacks a shell, and installs a rootkit. Javascript is turing complete but it's trivial to write a (slow) javascript interpreter in Python that allows anybody to run any javascript program without any risk to their machine. No memory attacks possible. To privilege escalation possible. No unchecked stack overflows. The system would be sandboxed and secure. It will just work or fail gracefully. It's only when we increase the complexity of our runtimes a thousand fold and when we cut corners to squeeze out higher performance that all the nasty vulnerabilities start to creep in.
  - JoeAltmaier 11y ago
    For pure Java perhaps. But native code is inevitable, and it has no such protection. So in practice Java is not a lot of protection.
    - piva00 11y ago
      I didn't understand how Java relates to his comment about JavaScript + Python.
      - JoeAltmaier 11y ago
        Sorry, its because I'm an idiot. Anyway, secure languages use native code, and that's still a problem.
  - sklogic 11y ago
    It must be really slow in order to avoid attacks like this one: https://github.com/IAIK/rowhammerjs https://github.com/IAIK/rowhammerjs
- sklogic 11y ago
  > You can't write safe code in any Turing complete language. Correct. But, a lot of code is written in Turing complete languages which does not really require any Turing completeness at all. And some code should be implemented in non-Turing-complete, verifiable languages.
  - iofj 11y ago
    Of course you can. You can, for instance, include an automatically verified proof that your code terminates for finite inputs. This is in fact where the newest academic languages are going. In dependantly typed languages bounds checks are only done in theory. you have to include a proof that your indexes are within bounds, and the compiler verifies that proof. If it checks out, it compiles. If not, back you go. Far safer than java/go and the like and far faster than c++. These languages tend to allow pointer arithmetic too, for beating it in speed is almost impossible.
- Nelson69 11y ago
  You cannot write safe code in any Turing complete language? That's a bold assertion that I don't believe is true. Surely you can use formal methods to develop software and maybe even prove it's correctness and security, it's costly in multiple ways but the language of implementation doesn't prevent you from doing this. It is possible to write secure code. If we replaced everything in C with Haskell, we'd have an entirely different problem. The attack surface wouldn't involve buffer overflows and stack smashing, it would involve various DoS attacks. Those might be easier to address though.
carlosrg 11y ago
> But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. Wrong. You can write perfectly safe code in C++. You seem to have this ridiculous idea that pointer arithmetic is mandatory on C++. "Pointer arithmetic" is not a feature of C++. It's a feature of how computers work. C++ allows you to do it if you want. Memory pools are not a C++ feature, memory pools are part of how a modern computer and OS works. You know, memory doesn't appear magically in your program. > Rust forces programmers to indicate ownership and lifetime of memory So like C++ with unique_ptr, shared_ptr, and RAII? Also I wanted to say that some of you keep mixing C and C++, calling them "C/C++". They're two different languages.
- pjmlp 11y ago
  I like C++ and dislike its C foundation. Always written C++ taking advantage of the language features that allow for safer code and bring it closer to Ada linage than C. Never saw anyone else doing the same in the enterprise codebases I worked on. My team at CERN was the only exception.
  - JoeAltmaier 11y ago
    You can even write C++ without linking the runtime, to avoid all that unsafe legacy code. For drivers and such. Done it many times.
    - pjmlp 11y ago
      Yes, that is why I find it good that both Mac OS X and Windows allow for kernel code in C++ as a kind of "worse is better" improvement over plain C. However C++ with teams that haven't drink the safety kool aid, becomes C with a C++ compiler quite fast. Hence why nowadays I tend to only use it occasionally in side projects.
- deleted 11y ago
  [deleted]
- steveklabnik 11y ago
  > So like C++ with unique_ptr, shared_ptr, and RAII? It is like that, but with stronger guarantees and less overhead.
andresmanz 11y ago
> But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. Then you've picked the wrong profession. You write that like it was a fact, while it's obviously nothing more than a lack of skill (and maybe knowledge) on your side. If I chose a language primarily because it's 'safe', that would mean that either I'm pretty bad at writing safe code, or that I'm just unnecessarily lazy.
- dbaupp 11y ago
  Maybe a single developer personally can write C/C++ code that is probably pretty safe (keeping in mind that most personal/small projects never get a proper security analysis/penetration test, so one may have a biased perception), but as soon as you have several people with non-trivial components that interact, it is quite to introduce serious problems accidentally. The evidence is unfortunately against C/C++: even the biggest tech companies in the world developing applications for which security is a critical feature (operating systems, web browsers) still regularly have bugs caused by memory safety issues, and they're almost certainly throwing every tool and a lot of CPU time at the problem.
- pjmlp 11y ago
  Assuming you work alone maybe yes. However most of us work in teams. C and C++ have long proven that with average skills teams, the end result is lurking buffer exploits, dangling pointers, corrupted memory somewhere in the code base, that usually take days to sort out.

by gizmo 11y ago

monochr 11y ago

>But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. You can't write safe code in any Turing complete language. That's the whole point of Turing completeness. The only reason why memory attacks are as common as they are is because C like languages are the most popular ones. If we replaced everything written with C to a "safe" language like, I don't know Haskell?, we'd have just as many zero day exploits of the monads within programs.

chriswarbo 11y ago
> If we replaced everything written with C to a "safe" language like, I don't know Haskell?, we'd have just as many zero day exploits of the monads within programs. I disagree. There will always be security issues, due to (ab)uses that developers didn't consider, but there can be different probabilities. Requiring developers to learn about language gotchas, remember those gotchas when coding, and jump through hoops to avoid them, just stacks the odds against us.
gizmo 11y ago
There is a huge difference between a program that computes the wrong answer and one that corrupts memory, hijacks a shell, and installs a rootkit. Javascript is turing complete but it's trivial to write a (slow) javascript interpreter in Python that allows anybody to run any javascript program without any risk to their machine. No memory attacks possible. To privilege escalation possible. No unchecked stack overflows. The system would be sandboxed and secure. It will just work or fail gracefully. It's only when we increase the complexity of our runtimes a thousand fold and when we cut corners to squeeze out higher performance that all the nasty vulnerabilities start to creep in.
- JoeAltmaier 11y ago
  For pure Java perhaps. But native code is inevitable, and it has no such protection. So in practice Java is not a lot of protection.
  - piva00 11y ago
    I didn't understand how Java relates to his comment about JavaScript + Python.
    - JoeAltmaier 11y ago
      Sorry, its because I'm an idiot. Anyway, secure languages use native code, and that's still a problem.
- sklogic 11y ago
  It must be really slow in order to avoid attacks like this one: https://github.com/IAIK/rowhammerjs https://github.com/IAIK/rowhammerjs
sklogic 11y ago
> You can't write safe code in any Turing complete language. Correct. But, a lot of code is written in Turing complete languages which does not really require any Turing completeness at all. And some code should be implemented in non-Turing-complete, verifiable languages.
- iofj 11y ago
  Of course you can. You can, for instance, include an automatically verified proof that your code terminates for finite inputs. This is in fact where the newest academic languages are going. In dependantly typed languages bounds checks are only done in theory. you have to include a proof that your indexes are within bounds, and the compiler verifies that proof. If it checks out, it compiles. If not, back you go. Far safer than java/go and the like and far faster than c++. These languages tend to allow pointer arithmetic too, for beating it in speed is almost impossible.
Nelson69 11y ago
You cannot write safe code in any Turing complete language? That's a bold assertion that I don't believe is true. Surely you can use formal methods to develop software and maybe even prove it's correctness and security, it's costly in multiple ways but the language of implementation doesn't prevent you from doing this. It is possible to write secure code. If we replaced everything in C with Haskell, we'd have an entirely different problem. The attack surface wouldn't involve buffer overflows and stack smashing, it would involve various DoS attacks. Those might be easier to address though.

carlosrg 11y ago

> But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. Wrong. You can write perfectly safe code in C++. You seem to have this ridiculous idea that pointer arithmetic is mandatory on C++. "Pointer arithmetic" is not a feature of C++. It's a feature of how computers work. C++ allows you to do it if you want. Memory pools are not a C++ feature, memory pools are part of how a modern computer and OS works. You know, memory doesn't appear magically in your program. > Rust forces programmers to indicate ownership and lifetime of memory So like C++ with unique_ptr, shared_ptr, and RAII? Also I wanted to say that some of you keep mixing C and C++, calling them "C/C++". They're two different languages.

pjmlp 11y ago
I like C++ and dislike its C foundation. Always written C++ taking advantage of the language features that allow for safer code and bring it closer to Ada linage than C. Never saw anyone else doing the same in the enterprise codebases I worked on. My team at CERN was the only exception.
- JoeAltmaier 11y ago
  You can even write C++ without linking the runtime, to avoid all that unsafe legacy code. For drivers and such. Done it many times.
  - pjmlp 11y ago
    Yes, that is why I find it good that both Mac OS X and Windows allow for kernel code in C++ as a kind of "worse is better" improvement over plain C. However C++ with teams that haven't drink the safety kool aid, becomes C with a C++ compiler quite fast. Hence why nowadays I tend to only use it occasionally in side projects.
deleted 11y ago
[deleted]
steveklabnik 11y ago
> So like C++ with unique_ptr, shared_ptr, and RAII? It is like that, but with stronger guarantees and less overhead.

andresmanz 11y ago

> But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. Then you've picked the wrong profession. You write that like it was a fact, while it's obviously nothing more than a lack of skill (and maybe knowledge) on your side. If I chose a language primarily because it's 'safe', that would mean that either I'm pretty bad at writing safe code, or that I'm just unnecessarily lazy.

dbaupp 11y ago
Maybe a single developer personally can write C/C++ code that is probably pretty safe (keeping in mind that most personal/small projects never get a proper security analysis/penetration test, so one may have a biased perception), but as soon as you have several people with non-trivial components that interact, it is quite to introduce serious problems accidentally. The evidence is unfortunately against C/C++: even the biggest tech companies in the world developing applications for which security is a critical feature (operating systems, web browsers) still regularly have bugs caused by memory safety issues, and they're almost certainly throwing every tool and a lot of CPU time at the problem.
pjmlp 11y ago
Assuming you work alone maybe yes. However most of us work in teams. C and C++ have long proven that with average skills teams, the end result is lurking buffer exploits, dangling pointers, corrupted memory somewhere in the code base, that usually take days to sort out.