The concern regarding Memory Safety-related vulnerabilities is not new; faults resulting from the lack of adherence in memory read and write operations have long been highlighted in the literature. Buffer overflows, buffer overheads, race-conditions, invalid page faults, initialization errors are types of faults of this nature. In addition to being a problem addressed in Software Engineering, specifically in the discipline of Verification, Validation, and Testing, cybersecurity engineers emphasize that the presence of these faults constitutes vulnerabilities and can be exploited by malicious actors in cyber attacks. The architecture of computers allows code and data to occupy the same memory, and this aspect is considered one of the main reasons for this problem.
Concerned with reducing cyber attacks and measuring cybersecurity, the White House has published a technical report (link) regarding Memory Safety vulnerabilities that has garnered significant attention. Memory Safety vulnerabilities can be mitigated through the choice of technology used in software development. For example, if a software’s requirements prioritize security and performance, it is recommended that the chosen technology has aspects that meet those requirements. However, this choice may involve a trade-off. From the perspective of programming languages, there is not a large set of languages considered Memory Safe. The Java language is included in this set, where the virtual machine controls memory usage, but this same machine degrades computational performance when compared to compiled languages that do not use a virtual machine, such as C or C++.
The C and C++ languages, introduced in the 1970s and 1980s respectively, are used to develop applications that run on “anything” (from smartphones to spacecraft). These languages allow for great flexibility and performance, enabling the programmer to directly manipulate memory, which is great, but… The role that these languages play in the development and strengthening of the modern world must be acknowledged, but they are still Memory Unsafe, despite updates and modernization efforts.
Regarding the trade-off choice mentioned earlier, there are expectations for the Rust programming language to combine performance and Memory Safety, but I haven’t researched enough to confirm. Nonetheless, the choice requires a thorough assessment of the requirements and context of the application to be developed. Is there a choice that fits “everything”?