It should be noted that iOS/macOS is likely to be not vulnerable because for them the Dolby decoder has been compiled as any C/C++ program should be compiled by default everywhere, i.e. with bounds checking enabled.
Unfortunately, all C/C++ compilers have as the default option to omit bounds checking, but any decent compiler has options for enabling bounds checking and other run-time checks suitable for catching all the undesirable behaviors that are undefined in the C/C++ standards. The default should be to enable such options globally for any program and to disable them selectively only for the code parts where benchmarks have demonstrated that they prevent the program to reach the target performance and code analysis has concluded that the erroneous behavior cannot happen.
The claim that C/C++ are unsafe programming languages is only in small part true, because most of the unsafety is caused by the compiler options that are chosen to be default by tradition, and not intrinsically by the language. The C/C++ standards fail to define a safe behavior for many situations, but they also do not prevent a compiler to implement the safe behavior, e.g. the fact that the standard does not require mandatory bounds checking for accessing arrays and structures does not mean that a compiler should not implement such checking.
When a C/C++ program is compiled with safe compilation options, instead of the default options, then it becomes quite safe, as most errors that would be caught by a "safer" language would also be caught when running the C/C++ program.
That's a lot of words, but how is that even possible?
Pointers and arrays are basically interchangeable in C, and you have to do that constantly in any large program. Even the blog post has a malloc in it.
Once you start passing around a pointer to the middle of the array all size info is lost.
Are you talking about -fsanitize=address? It's too slow to be used in production
> When a C/C++ program is compiled with safe compilation options, instead of the default options, then it becomes quite safe, as most errors that would be caught by a "safer" language would also be caught when running the C/C++ program.
Sean Baxter has been providing quite a number of crazy examples that even if they wanted to which there is no sign they do, C++ couldn't attempt to fix without major language changes.
Bounds checking in more places by default, catching some types of initialization screw up, these are all nice enough in some sense - indeed in this particular case maybe they close the vulnerability - but they're band aids, the pig is gone dad. https://www.youtube.com/watch?v=1XIcS63jA3w