Does remote code execution due to use after free fall in the category of "properly working" and "exploding in your face at runtime"? I would think it does, and C++ is vulnerable to that like few other languages are.
Does remote code execution due to use after free fall in the category of "properly working" and "exploding in your face at runtime"? I would think it does, and C++ is vulnerable to that like few other languages are.
That was mostly put in there as a transition from C. Modern C++ users shouldn't be using new / free at all, since shared_ptr (and weak_ptr, its counterpart) and unique_ptr basically cover all the use cases.
std::vector<std::string> v;
v.push_back("Hello");
for (auto&& s: v) {
v.clear();
std::cout << s; // use after free in modern C++
}
There is no reasonable way for a compiler to precisely check for use after free in C++ short of changing the language, and this can be easily proven.In any case, a std::vector<shared_ptr<std::string> > would actually avoid the issue in this particular case.
Use after free... is more about use of raw pointers IMO. I wouldn't describe that code to be a "use after free" at all. In most languages, you are simply not allowed to change the container at all. Iterator invalidation is a hard issue in any language.
shared_ptr is also not memory safe when combined with references, which you need to use to call methods on the shared_ptr'd object or to pass those objects to most functions.
Foo f;
DoSomething(std::move(f));
// can still use f here.So again, unless Foo f was composed of "raw pointers", even that kind of code is safe from "use after free" vulnerabilities.
Not exactly. Use after free, while indeed problematic, is not what I would consider proper code, and I think you're well aware of that :]