3 ms·

You can't get security vulnerabilities due to use-after-free if you use indices. Don't use unsafe for this.

pjmlp 8y ago
Sure you can. If my index 2 now contains the contents of lets say index 5, due to array rearrangement after deletion of the element at 2, whatever happens with data[idx].is_data_valid() is not what the developer would be expecting.
- Munksgaard 8y ago
  Easily solved with generational indexes as described in https://www.youtube.com/watch?v=aKLntZcp27M https://www.youtube.com/watch?v=aKLntZcp27M
  - pjmlp 8y ago
    I have seen that talk. To me it feels a bit like a workaround for something that cannot be validated by the borrow checker, because it is something that developers have to go the extra mile to implement, or get a third party library, which someone has to validate that actually works as expected. In a way, it isn't much different than expecting C and C++ developers to use static analysis for lifetime validations. Meaning, using a tool outside of the core language for added safety.
    - kibwen 8y ago
      > To me it feels a bit like a workaround for something that cannot be validated by the borrow checker Is it so hard to believe that references are not the correct abstraction for 100% of use cases? Reaching for something other than references when references are the wrong tool for the job is not working around the borrow checker; it's choosing the right abstraction for the right task. Being hung up on the borrow checker is missing the forest for the trees. > get a third party library, which someone has to validate that actually works as expected. How is this different from using any third-party library, ever? > Meaning, using a tool outside of the core language for added safety. Rust explicitly supports users defining their own smart pointer types to provide pointer-like abstractions with custom semantics; using tools outside of the core language for added safety (for whatever definition of "safety" one wants) is completely expected and encouraged.
      - pjmlp 8y ago
        The point being, that for developers focused on managed languages, C++ takes the role of the unsafe layer. Meaning Java/C++, .NET + (C++/CLI | C++/WinRT), Node.js + C++, Swift / Objective-C++. So with C++ improving its safety history, usually with ideas taken from Rust, Rust ergonomics and tooling need to have a better story than C++'s to replace it on the above stacks.
        kibwen 8y ago
        Interesting, because in my experience people use Java/C, Node/C, Swift/Objective-C, Python/C, Ruby/C... rarely do I encounter anyone using C++ as an extension language (I encounter Rust being used more often than C++, in fact, but perhaps that's an artifact of the circles I'm in). As for C++ adding more static analysis, its lifetime analysis is a nice-to-have, but doesn't compare to Rust's borrow checker. You simply can't tack on a sound borrow checker to C++, because the language wasn't designed to accommodate one, and trying to impose the concomitant rules regarding mutability, aliasing, and single-ownership would break every C++ program ever written. For anyone who prioritizes sound static analysis WRT lifetime verification, C++ isn't a competitor to Rust. And there are plenty of people for whom that isn't the case, and they will continue to use C++, and that's not a problem. Rust exists to provide an alternative systems language for people who favor memory safety, and it's pretty good at that. :)
        pjmlp 8y ago
        I guess you spend more time in UNIX platforms? As for being an alternative systems language for people who favor memory safety, I fully agree, my point is that it still needs to improve its productivity and eco-system. At CppCon 2018 Embedded Development panel, one theme was that only now companies are slowly willing to migrate from C to C++11(!), with a language that allows for a progressive rewrite from C while keeping the existing toolchains. Another productivity example, with .NET I can get the safety I advocate, while C++/CLI/CX/WinRT allow for a seamless interoperability story with native code. So even if the lifetime analysis is a subset of what Rust is capable of, mixed debugging and seamless CLR/COM/UWP integration are more attractive than rewriting that code in Rust, without having VS integration and WIP integration with Windows APIs. I think Rust on its current state, is more indicated for GC free scenarios with either CLI or headless execution.
    - nicoburns 8y ago
      Requiring a library is only really a big deal in the C/C++ world though. Everywhere else it's trivial, and most projects will depend on some foundational libraries. That's pretty different to static analysis tools which most likely won't always work.
    - pcwalton 8y ago
      Nobody is asking for generational indices to be added to the core language. There would be zero benefit. We have a package manager for a reason. Maybe we could uplift them to the nursery, but again, generational indices are nowhere near the top 10 crates on crates.io.
- pcwalton 8y ago
  That is not use-after-free in the way that the security community typically uses the term. This kind of problem is an order of magnitude less likely to lead to RCE.

Sure you can. If my index 2 now contains the contents of lets say index 5, due to array rearrangement after deletion of the element at 2, whatever happens with data[idx].is_data_valid() is not what the developer would be expecting.

Munksgaard 8y ago
Easily solved with generational indexes as described in https://www.youtube.com/watch?v=aKLntZcp27M https://www.youtube.com/watch?v=aKLntZcp27M
- pjmlp 8y ago
  I have seen that talk. To me it feels a bit like a workaround for something that cannot be validated by the borrow checker, because it is something that developers have to go the extra mile to implement, or get a third party library, which someone has to validate that actually works as expected. In a way, it isn't much different than expecting C and C++ developers to use static analysis for lifetime validations. Meaning, using a tool outside of the core language for added safety.
  - kibwen 8y ago
    > To me it feels a bit like a workaround for something that cannot be validated by the borrow checker Is it so hard to believe that references are not the correct abstraction for 100% of use cases? Reaching for something other than references when references are the wrong tool for the job is not working around the borrow checker; it's choosing the right abstraction for the right task. Being hung up on the borrow checker is missing the forest for the trees. > get a third party library, which someone has to validate that actually works as expected. How is this different from using any third-party library, ever? > Meaning, using a tool outside of the core language for added safety. Rust explicitly supports users defining their own smart pointer types to provide pointer-like abstractions with custom semantics; using tools outside of the core language for added safety (for whatever definition of "safety" one wants) is completely expected and encouraged.
    - pjmlp 8y ago
      The point being, that for developers focused on managed languages, C++ takes the role of the unsafe layer. Meaning Java/C++, .NET + (C++/CLI | C++/WinRT), Node.js + C++, Swift / Objective-C++. So with C++ improving its safety history, usually with ideas taken from Rust, Rust ergonomics and tooling need to have a better story than C++'s to replace it on the above stacks.
      - kibwen 8y ago
        Interesting, because in my experience people use Java/C, Node/C, Swift/Objective-C, Python/C, Ruby/C... rarely do I encounter anyone using C++ as an extension language (I encounter Rust being used more often than C++, in fact, but perhaps that's an artifact of the circles I'm in). As for C++ adding more static analysis, its lifetime analysis is a nice-to-have, but doesn't compare to Rust's borrow checker. You simply can't tack on a sound borrow checker to C++, because the language wasn't designed to accommodate one, and trying to impose the concomitant rules regarding mutability, aliasing, and single-ownership would break every C++ program ever written. For anyone who prioritizes sound static analysis WRT lifetime verification, C++ isn't a competitor to Rust. And there are plenty of people for whom that isn't the case, and they will continue to use C++, and that's not a problem. Rust exists to provide an alternative systems language for people who favor memory safety, and it's pretty good at that. :)
        pjmlp 8y ago
        I guess you spend more time in UNIX platforms? As for being an alternative systems language for people who favor memory safety, I fully agree, my point is that it still needs to improve its productivity and eco-system. At CppCon 2018 Embedded Development panel, one theme was that only now companies are slowly willing to migrate from C to C++11(!), with a language that allows for a progressive rewrite from C while keeping the existing toolchains. Another productivity example, with .NET I can get the safety I advocate, while C++/CLI/CX/WinRT allow for a seamless interoperability story with native code. So even if the lifetime analysis is a subset of what Rust is capable of, mixed debugging and seamless CLR/COM/UWP integration are more attractive than rewriting that code in Rust, without having VS integration and WIP integration with Windows APIs. I think Rust on its current state, is more indicated for GC free scenarios with either CLI or headless execution.
  - nicoburns 8y ago
    Requiring a library is only really a big deal in the C/C++ world though. Everywhere else it's trivial, and most projects will depend on some foundational libraries. That's pretty different to static analysis tools which most likely won't always work.
  - pcwalton 8y ago
    Nobody is asking for generational indices to be added to the core language. There would be zero benefit. We have a package manager for a reason. Maybe we could uplift them to the nursery, but again, generational indices are nowhere near the top 10 crates on crates.io.
pcwalton 8y ago
That is not use-after-free in the way that the security community typically uses the term. This kind of problem is an order of magnitude less likely to lead to RCE.