4 ms·

I am not sure if the comparison is correct. Basically, they are looking at the Android code base and calculate 1 vulnerability / kLoc for C++. This doesn't tell

by pvitz 4y ago

I am not sure if the comparison is correct. Basically, they are looking at the Android code base and calculate 1 vulnerability / kLoc for C++. This doesn't tell us anything about the distribution over time. It could be that Google limited itself to certain C++ features in the beginning of Android and had or has a lot of vulnerabilities from this era, whereas newer code using smart pointers etc. doesn't suffer from this issues (as much). It would be more interesting to compare only the code of C++ and Rust written in the same timeframe. My expectation is that C++ wouldn't look as bad as stated in the article.

UncleMeat 4y ago
People have investigated this too. Smart pointers, even the ones created specifically for Chromium, have not eliminated these problems. You can happily find CVEs whose root cause is a UAF on an object managed by unique_ptr in the Chromium codebase.
- 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...
simplotek 4y ago
> It would be more interesting to compare only the code of C++ and Rust written in the same timeframe. My expectation is that C++ wouldn't look as bad as stated in the article. I agree. The article reads like it started with w conclusion and cherry-picked data to fit that.

by pvitz 4y ago

UncleMeat 4y ago

People have investigated this too. Smart pointers, even the ones created specifically for Chromium, have not eliminated these problems. You can happily find CVEs whose root cause is a UAF on an object managed by unique_ptr in the Chromium codebase.

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...

simplotek 4y ago

> It would be more interesting to compare only the code of C++ and Rust written in the same timeframe. My expectation is that C++ wouldn't look as bad as stated in the article. I agree. The article reads like it started with w conclusion and cherry-picked data to fit that.