6 ms·

I would be really interested in seeing such a case where there was no extraction of a raw pointer or similar involved. Could you please point me to such a CVE?

by pvitz 4y ago

UncleMeat 4y ago
Of course there is extraction of a raw pointer or reference. But that's a perfectly normal way of writing C++. An object that owns something hands a non-owning pointer to another thing with the assumption that the owning object will outlive the thing that uses the pointer. But people make mistakes and fuck up lifetimes and then you have a UAF. If you never call .get() on a unique_ptr then you'll be okay. But that's often not a workable design.
- simplotek 4y ago
  > Of course there is extraction of a raw pointer or reference. But that's a perfectly normal way of writing C++. No, it isn't. That's flagged by default settings of most static code analysis tools, and it requires explicitly going against the whole point of explicitly assigning ownership of an object.
  - UncleMeat 4y ago
    Ownership is about lifetimes, not use. You are going to have a highly constrained design if nothing can access any pointer that it does not directly own. Which static analysis tools? Can you point me at them? Maybe a sample program demonstrating that it'll throw out up loud warnings when I pass a reference to an member owned by a unique_ptr to another function? Like, are there any static analysis tools that warn on every single string_view parameter?
    - simplotek 4y ago
      > Ownership is about lifetimes, not use. You're failing to understand that granting access to the raw pointer managed by a std::unique_ptr violates the precondition that the object owned by that smart pointer is managed exclusively by the smart pointer itself. It's very strange how you fail to get this point when you're trying to complain about C++'s supposedly memory management issues in general, and in this particular case an error sparking from violating these invariants. Failing to use a smart pointer, to the extent you even have to explicitly ignore errors from static code analyzers to make them, is not a language issue. It's a "pay attention to the big red error messages" issue. You can't have your cake and eat it too. It makes absolutely no sense to spend so much time and energy mindlessly criticising a programming language to then try to argue that making one of the most basic errors was somehow an acceptable practice when it clearly isn't.
      - UncleMeat 4y ago
        You didn't answer my question. What static analyzers? "Never pass a non-owning reference to anything ever" is ludicrous.
- pvitz 4y ago
  Google's answer to this issue seems to be... a smart pointer: https://chromium.googlesource.com/chromium/src/+/main/base/memory/raw_ptr.md https://chromium.googlesource.com/chromium/src/+/main/base/m...

I would be really interested in seeing such a case where there was no extraction of a raw pointer or similar involved. Could you please point me to such a CVE?

by pvitz 4y ago

I would be really interested in seeing such a case where there was no extraction of a raw pointer or similar involved. Could you please point me to such a CVE?

UncleMeat 4y ago

Of course there is extraction of a raw pointer or reference. But that's a perfectly normal way of writing C++. An object that owns something hands a non-owning pointer to another thing with the assumption that the owning object will outlive the thing that uses the pointer. But people make mistakes and fuck up lifetimes and then you have a UAF. If you never call .get() on a unique_ptr then you'll be okay. But that's often not a workable design.

simplotek 4y ago
> Of course there is extraction of a raw pointer or reference. But that's a perfectly normal way of writing C++. No, it isn't. That's flagged by default settings of most static code analysis tools, and it requires explicitly going against the whole point of explicitly assigning ownership of an object.
- UncleMeat 4y ago
  Ownership is about lifetimes, not use. You are going to have a highly constrained design if nothing can access any pointer that it does not directly own. Which static analysis tools? Can you point me at them? Maybe a sample program demonstrating that it'll throw out up loud warnings when I pass a reference to an member owned by a unique_ptr to another function? Like, are there any static analysis tools that warn on every single string_view parameter?
  - simplotek 4y ago
    > Ownership is about lifetimes, not use. You're failing to understand that granting access to the raw pointer managed by a std::unique_ptr violates the precondition that the object owned by that smart pointer is managed exclusively by the smart pointer itself. It's very strange how you fail to get this point when you're trying to complain about C++'s supposedly memory management issues in general, and in this particular case an error sparking from violating these invariants. Failing to use a smart pointer, to the extent you even have to explicitly ignore errors from static code analyzers to make them, is not a language issue. It's a "pay attention to the big red error messages" issue. You can't have your cake and eat it too. It makes absolutely no sense to spend so much time and energy mindlessly criticising a programming language to then try to argue that making one of the most basic errors was somehow an acceptable practice when it clearly isn't.
    - UncleMeat 4y ago
      You didn't answer my question. What static analyzers? "Never pass a non-owning reference to anything ever" is ludicrous.
pvitz 4y ago
Google's answer to this issue seems to be... a smart pointer: https://chromium.googlesource.com/chromium/src/+/main/base/memory/raw_ptr.md https://chromium.googlesource.com/chromium/src/+/main/base/m...