Rust is popular? Chrome is considering a “new” approach to memory security


For a long time, web browsers have been attacked by hackers. Google has tried to solve this problem with sandbox, but progress has been blocked due to performance problems. Therefore, recently, the chrome security team announced that it is considering rewriting or developing some modules of chrome using the memory security language rust.

Rust is popular? Chrome is considering a

As we all know, memory security is a problem that the global software engineering community needs to take seriously. Data show that last year, chrome engineers analyzed 912 security vulnerabilities repaired in chrome stable branches since 2015. The severity of these vulnerabilities is rated as “high” or “serious”, and more than 70% of these serious security vulnerabilities are memory security problems. In other words, pointer errors in C or C + + languages can lead to memory misunderstandings.

Chrome security team said that although the combination with black box testing technology is still Chrome’s main “defense line”, it seems to have reached the limit and can no longer rely on this strategy to resist crazy attacks.

The chrome security team believes that the existence of memory security problems is both a challenge and an opportunity for the team, because many bugs have the same root causes, which means that they can eliminate most bugs in one step.

In this regard, the chrome security team has been exploring and solving it through the following three ways:

  1. Check whether the pointer is correct at compile time to make C + + more secure.
  2. Make C + + safer by checking whether the pointer is correct at run time.
  3. Investigate the use of memory safe language in some code bases.

“Compile time check” means that security is guaranteed during chrome construction or before chrome enters the user’s device. “Runtime” means that the chrome security team checks when running chrome on the user’s device, because “runtime check” will lead to performance loss (although the correctness of the check pointer is in memory and memory)   The consumption of CPU time is minimal. If millions of pointers are added up, the impact will be exacerbated), and the performance of chrome is very important for billions of users. Many users use low-power mobile devices without much memory. Therefore, the increase of these checks will slow down the network speed.

So ideally, chrome will choose option 1 of the above three ways — making C + + safer at compile time. Unfortunately, the concept of language is not designed in this way. So chrome also has options 2 and 3 — making C + + more secure (but slower), or starting to use different languages (chrome security is experimenting with both.)

At the same time, the chrome security team also introduced its major investment in C + + security solutions, such as PTR and absl / STL enhancement mode. In each case, chrome wants to eliminate a significant portion of the exploitable security vulnerabilities, but they also expect some performance losses.

At the same time, the chrome security team will also explore whether the memory security language can be used for some parts of chrome in the future, which is (to a large extent) safer at compile time than the competitive rust language. That is, the rust compiler finds pointer errors before the code reaches the user’s device, so there is no performance loss. However, about Chrome   There are still some open questions about whether C + + and rust can work together fully. Even Chrome   Start writing a new large component in rust tomorrow, chrome   It is impossible to eliminate most security vulnerabilities in a few years. So can you keep the language boundaries clean enough so that you can write some existing components using rust? The chrome security team is unable to answer this question for the time being.

For the developer team, security and vulnerabilities are like “cat and mouse games”. With the continuous “innovation” of attackers, browsers must install new defense systems to stay ahead. Although Chrome has invested in building a more powerful multi process architecture based on sandbox and site isolation, it is sometimes impossible to prevent it.

At present, the chrome security team has begun to conduct limited, non user oriented rust experiments in the chrome source code tree. As it is still in the experimental stage, it is not used in the production version of chrome.

Reference link:


Recommended Today

On the mutation mechanism of Clickhouse (with source code analysis)

Recently studied a bit of CH code.I found an interesting word, mutation.The word Google has the meaning of mutation, but more relevant articles translate this as “revision”. The previous article analyzed background_ pool_ Size parameter.This parameter is related to the background asynchronous worker pool merge.The asynchronous merge and mutation work in Clickhouse kernel is completed […]