
Ways to deal with bookmarks in compilers
In my last article , The Black Swan Theory and the Fundamental Vulnerability of Automated Systems, I described software bookmarks that are added to open source programs by the binary version of the compiler, while new versions of the compiler compiled by this compiler will also be created with bookmarks.
In this article, I proposed a reference solution and several recommendations to reduce the likelihood of this threat.
Instead of introducing
Reference solution
The solution is quite obvious and consists in creating a reference compiler. And even not so much in creating a compiler, but in creating open specifications and methods for developing a reference version of this compiler, which can be performed in several independent implementations. Only in this case, when separately compiling an application program with several implementations of the “trusted” compiler, if the binary modules are identical, it will be possible to talk about the absence of virus code in the received “reference” compilers and, accordingly, the absence of bookmarks in the resulting program.
Undoubtedly, one should not forget about the implementation of attacks through the hardware of the computer; to increase the degree of trust, it is necessary to use the hardware developed in accordance with the principles of Open Hardware.
Threat Reduction Recommendations
Creating a reference compiler will take time and effort of the development team, but the problem is now and there is no trusted compiler. So it is necessary to take measures to reduce the likelihood of these threats.
Speaking about creating a compiler, we are talking not only about the phase of generating object files, but also about such components as a preprocessor, linker, etc. A separate native implementation of the preprocessor and linker, taking into account all other recommendations (including their implementation in other languages), can affect the implementation of the threat.
Assumptions to reduce the likelihood of implementing software bookmarks, assumptions are based on a threat model.
* NDV- undocumented features.
Reducing the manifestations of NDV in compiled programs is possible when combining the presented methods together with dynamic software testing.
Afterword
The very threat of Bookmarks in Compilers resembles conspiracy theory and is paranoid, but theoretically feasible. In the comments, objective criticism and recommendations are welcome.
In this article, I proposed a reference solution and several recommendations to reduce the likelihood of this threat.
Instead of introducing
Enter narrow gates, for the gates are wide and the path leading to the fiery hell is spacious. (Gospel of Matthew).
Reference solution
The solution is quite obvious and consists in creating a reference compiler. And even not so much in creating a compiler, but in creating open specifications and methods for developing a reference version of this compiler, which can be performed in several independent implementations. Only in this case, when separately compiling an application program with several implementations of the “trusted” compiler, if the binary modules are identical, it will be possible to talk about the absence of virus code in the received “reference” compilers and, accordingly, the absence of bookmarks in the resulting program.
Undoubtedly, one should not forget about the implementation of attacks through the hardware of the computer; to increase the degree of trust, it is necessary to use the hardware developed in accordance with the principles of Open Hardware.
Threat Reduction Recommendations
Creating a reference compiler will take time and effort of the development team, but the problem is now and there is no trusted compiler. So it is necessary to take measures to reduce the likelihood of these threats.
Speaking about creating a compiler, we are talking not only about the phase of generating object files, but also about such components as a preprocessor, linker, etc. A separate native implementation of the preprocessor and linker, taking into account all other recommendations (including their implementation in other languages), can affect the implementation of the threat.
Assumptions to reduce the likelihood of implementing software bookmarks, assumptions are based on a threat model.
The threat | Decision |
The NDV compiler recognizes the source code of the target program and adds the virus code. | Obfuscation of the source code of the compiled program without loss of functionality. |
New bookmarks were added to the new binary versions of compilers with NDV. | Using the earliest binary versions of compilers, then part of the NDV may not be relevant. |
A compiler with NDV adds virus code to the platform on which it was compiled. (Arm, x86) | Cross compilation. Compilation of programs for x86 on Arm and vice versa. |
A compiler with NDV uses third-party libraries and software to implement part of the bookmarks. | Compilation on an isolated system with the minimum necessary set of programs and utilities. |
A compiler with NDV provides attacks on systems isolated from external data and activates NDV on any events (memory overflow, unknown errors, connection of specialized devices, the onset of a certain time, etc.) | Simulation of events and launch of the tested software under given conditions (including during compilation). |
Reducing the manifestations of NDV in compiled programs is possible when combining the presented methods together with dynamic software testing.
Afterword
The very threat of Bookmarks in Compilers resembles conspiracy theory and is paranoid, but theoretically feasible. In the comments, objective criticism and recommendations are welcome.