3 ms·

One of the best explanations ever written is the now classic "Cult of the Dead Cow issue #351 - The Tao of Windows [NT|95|98] Buffer Overflow" @ http://www.cult

One of the best explanations ever written is the now classic "Cult of the Dead Cow issue #351 - The Tao of Windows [NT|95|98] Buffer Overflow" @ http://www.cultdeadcow.com/cDc_files/cDc-351/ http://www.cultdeadcow.com/cDc_files/cDc-351/

drzaiusapelord 11y ago
>but if you don't have automatic bounds checking like Java, I guarantee you that those 'A's are going somewhere unfortunate. 20 years later and we're still using C++. I hope Rust takes off. The status quo today is terrible.
- dmix 11y ago
  Also of note is the lack of investment in exploit mitigation at the operating system and compiler level. C++ and C are not going away from our systems any time soon. Yet exploit mitigation technology still remains on the sidelines of the security world while bug squashing, AV, and IDS are flush with cash.
  - drzaiusapelord 11y ago
    How realistic is a compiler-level change that is 100% transparent and reverse compatible with existing codebases? I suspect this is a tough nut to crack without making fundamental changes to the language and perhaps invalidating past codebases. You might as well move to a different language then. I suspect we'll have a Rust compiler that compiles fast applications with a very minor performance hit before this happens to aging languages like C/C++.
    - dllthomas 11y ago
      The question is not just when we will have the tech, though. It is also when the tech will have an impact. A perfect Rust compiler only improves the safety of new (or rewritten) code.
      - pyre 11y ago
        I daresay that some codebases might rely on overflowing behaviour even if they don't know it. I've worked with a codebase where assumptions about unused RAM were that it was always zeroed out. Moving to a different platform (Linux) changed those assumptions, and there was lots of weird behaviour in the codebase because of that. I'll bet there are lots of legacy codebases that would actively resist using such a compiler technology for C/C++ because of unknown behaviours happening in their codebase (and because there is no test suite, or just poor test coverage).
        dmix 11y ago
        Legacy codebases like that tend to run on outdated operating systems, so addressing issues with buffer overflows in the software would probably do little to improve the security of the systems as a whole.
        dllthomas 11y ago
        Certainly, though usually that winds up perceived as brittleness moving between compiler versions in general. Ideally, the tech we are discussing could help make it easier to understand those unknown behaviors. But even if not, and even if this accounts for 60% of existing C/C++ codebases, improving the remaining 40% is a huge win that would take tremendously more time to reimplement in Rust. This is not to say that I am not also very excited about Rust.
- deleted 11y ago
  [deleted]
- steveklabnik 11y ago
  It's also important that you can also avoid the bounds checks safely in Rust, as well. For example, if you're iterating over elements, you don't pay the cost of the bounds check on each element, because you can know statically that it's safe.

drzaiusapelord 11y ago

>but if you don't have automatic bounds checking like Java, I guarantee you that those 'A's are going somewhere unfortunate. 20 years later and we're still using C++. I hope Rust takes off. The status quo today is terrible.

dmix 11y ago
Also of note is the lack of investment in exploit mitigation at the operating system and compiler level. C++ and C are not going away from our systems any time soon. Yet exploit mitigation technology still remains on the sidelines of the security world while bug squashing, AV, and IDS are flush with cash.
- drzaiusapelord 11y ago
  How realistic is a compiler-level change that is 100% transparent and reverse compatible with existing codebases? I suspect this is a tough nut to crack without making fundamental changes to the language and perhaps invalidating past codebases. You might as well move to a different language then. I suspect we'll have a Rust compiler that compiles fast applications with a very minor performance hit before this happens to aging languages like C/C++.
  - dllthomas 11y ago
    The question is not just when we will have the tech, though. It is also when the tech will have an impact. A perfect Rust compiler only improves the safety of new (or rewritten) code.
    - pyre 11y ago
      I daresay that some codebases might rely on overflowing behaviour even if they don't know it. I've worked with a codebase where assumptions about unused RAM were that it was always zeroed out. Moving to a different platform (Linux) changed those assumptions, and there was lots of weird behaviour in the codebase because of that. I'll bet there are lots of legacy codebases that would actively resist using such a compiler technology for C/C++ because of unknown behaviours happening in their codebase (and because there is no test suite, or just poor test coverage).
      - dmix 11y ago
        Legacy codebases like that tend to run on outdated operating systems, so addressing issues with buffer overflows in the software would probably do little to improve the security of the systems as a whole.
      - dllthomas 11y ago
        Certainly, though usually that winds up perceived as brittleness moving between compiler versions in general. Ideally, the tech we are discussing could help make it easier to understand those unknown behaviors. But even if not, and even if this accounts for 60% of existing C/C++ codebases, improving the remaining 40% is a huge win that would take tremendously more time to reimplement in Rust. This is not to say that I am not also very excited about Rust.
deleted 11y ago
[deleted]
steveklabnik 11y ago
It's also important that you can also avoid the bounds checks safely in Rust, as well. For example, if you're iterating over elements, you don't pay the cost of the bounds check on each element, because you can know statically that it's safe.