Chromium developers 912 dangerous and critical vulnerabilities identified in stable releases of Chrome since 2015, and concluded that 70% of them were caused by unsafe memory handling (bugs when working with pointers in C/C++ code). Half of these problems (36.1%) are caused by calls to the buffer after the memory associated with it has been freed (use-after-free).
When designing Chromium, it was originally that bugs are not ruled out in the code, so a lot of emphasis was placed on the use of sandbox isolation to limit the consequences of the manifestation of vulnerabilities. At present, the possibilities of using this technology have reached the limit of their capabilities, and further division into processes is inappropriate from the point of view of resource consumption.
To maintain codebase security, Google also enforces "β, according to which any code that is added must meet no more than two of the three conditions: working with unverified input, using an unsafe programming language (C / C ++), and running with elevated privileges. It follows from this rule that the code for handling external data must either be stripped down to the minimum privileges (isolated) or be written in a secure programming language.
To further strengthen the security of the codebase, a project has been launched to prevent the occurrence of memory errors in the codebase. There are three main approaches: creating C++ libraries with functions for safe work with memory and expanding the scope of the garbage collector, using hardware protection mechanisms (Memory Tagging Extension) and writing components in languages ββthat provide safe work with memory (Java, Kotlin, JavaScript, Rust, Swift).
The work is expected to focus on two areas:
- Significant change in the C++ development process, not without a negative performance impact (additional bounds checks and garbage collection). Instead of raw pointers, it is proposed to use the type in the code , which allows you to reduce exploitable use-after-free class errors to non-security-threatening crashes, without a noticeable negative impact on performance, memory consumption, and stability.
- The use of languages ββdesigned to perform memory-safe checks at compile time (will eliminate the negative impact on performance inherent in such checks at runtime, but will lead to additional costs for organizing the interaction of code in a new language with code in C ++).
Using memory-safe libraries is the simplest, but also less efficient way. Rewriting the code in Rust is rated as the most efficient, but also very expensive way.
Source: opennet.ru