> The UDC is integrated into a variety of hardware and platforms, including Android, iOS, Windows and media streaming devices. It is shipped to most OEMs as a binary ‘blob’ with limited symbols, which is then statically linked into a shared library.
Does that suggest this is a vulnerability on other platforms as well?
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.
> 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
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
I believe GP is talking about -fbounds-safety [0, 1]. From my understanding this will cause the compiler to emit an error if it can't figure out how to bounds check a pointer access at either compile time or run time. You then need to either add appropriate annotations to provide the missing information or otherwise restructure the code to satisfy the compiler.
As implemented in the most popular compilers "-fsanitize=address" is indeed slow.
However, for the majority of the code of a program, enabling this and all the other sanitize options will have a negligible effect on the useful performance.
Like I have said, sanitize options should be disabled in performance-critical sections, which have been identified as such by profiling, not by guessing, but only after examining those sections thoroughly, to be certain that the undefined behavior cannot be triggered.
Currently, the sanitize options are significantly slower than they should be in an optimized implementation, because there is a vicious circle. The application developers do not enable such options for production because they believe that they are slow and the compiler developers do not make the effort to improve their speed, because they believe that the application developers will not enable them in production code anyway.
However, these problems are not inherent to the language or compiler, they are caused by a bad historical tradition of neglecting the correctness of a program whenever cheating can improve the performance in the best case (which will be the only one demonstrated to potential customers), even if that makes the worst case catastrophic.
Even Rust is not immune to bad traditions, e.g. by disabling overflow checking in release builds, as opposed to debug builds.
They probably should've worked harder to avoid the name "Dolby Unified Decoder", or DUD for short.
> The UDC is integrated into a variety of hardware and platforms, including Android, iOS, Windows and media streaming devices. It is shipped to most OEMs as a binary ‘blob’ with limited symbols, which is then statically linked into a shared library.
Does that suggest this is a vulnerability on other platforms as well?
The article claims iOS/macOS is likely not vulnerable. I'm not sure about Windows.
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.
> 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
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
I believe GP is talking about -fbounds-safety [0, 1]. From my understanding this will cause the compiler to emit an error if it can't figure out how to bounds check a pointer access at either compile time or run time. You then need to either add appropriate annotations to provide the missing information or otherwise restructure the code to satisfy the compiler.
[0]: https://clang.llvm.org/docs/BoundsSafety.html
[1]: https://clang.llvm.org/docs/BoundsSafetyAdoptionGuide.html
Indeed, this is the option used for compiling the Dolby decoder on the unaffected systems.
As implemented in the most popular compilers "-fsanitize=address" is indeed slow.
However, for the majority of the code of a program, enabling this and all the other sanitize options will have a negligible effect on the useful performance.
Like I have said, sanitize options should be disabled in performance-critical sections, which have been identified as such by profiling, not by guessing, but only after examining those sections thoroughly, to be certain that the undefined behavior cannot be triggered.
Currently, the sanitize options are significantly slower than they should be in an optimized implementation, because there is a vicious circle. The application developers do not enable such options for production because they believe that they are slow and the compiler developers do not make the effort to improve their speed, because they believe that the application developers will not enable them in production code anyway.
However, these problems are not inherent to the language or compiler, they are caused by a bad historical tradition of neglecting the correctness of a program whenever cheating can improve the performance in the best case (which will be the only one demonstrated to potential customers), even if that makes the worst case catastrophic.
Even Rust is not immune to bad traditions, e.g. by disabling overflow checking in release builds, as opposed to debug builds.