For features like this, that communication can be considered trustworthy if it comes from a pinned HTTPS server. Certain features, such as Sign-In and the Discover Feed, need to communicate with Google. However, Chrome is a feature-filled browser with many different use cases, and many different features beyond just updating itself. These services both use asymmetric cryptography to authenticate their data, and the public key used to verify data sent by these services is shipped in Chrome. The component updater and the variations framework are services specific to Chrome used to ship data-only updates and configuration information. We can cryptographically prove that data came from Google servers if that data comes from: Effectively, this means that in situations where the browser process needs access to data from external sources, it must be read from Google servers. Trustworthy inputs are defined extremely strictly: A “trustworthy source” means that Chrome can prove that the data comes from Google. The relative risks between sandboxed processes and the browser process are why the browser process is only allowed to parse trustworthy inputs and specific IPC messages. Without sandboxing, which limits the actions an attacker can take, and without memory safety, which removes the ability of a bug to disrupt the intended control flow of the program, the rule of two requires that the browser process does not handle untrustworthy inputs. The attacker cannot reach outside of the sandbox unless they can additionally exploit the sandbox itself. Conversely, if an attacker achieves RCE in a sandboxed process, such as a renderer, the attacker's capabilities are extremely limited.
GOOGLE CHROME PORTABLE ARCHIVE FULL
If an attacker is able to craft a malicious input to the browser process that exploits a bug and allows the attacker to achieve remote code execution (RCE) in the browser process, that would effectively give the attacker full control of the victim’s Chrome browser and potentially the rest of the device. The browser process is the source of truth that allows the rest of Chrome to be sandboxed and coordinates communication between the rest of the processes. In Chrome, the broker is the browser process. Much of Chrome is sandboxed, but the sandbox still requires a core high-privilege “broker” process to coordinate communication and launch sandboxed processes. Similarly, we’re working on adding support to write Chrome code in Rust, which is also memory-safe. These languages are memory-safe in the common case. Android-specific features can be written in Java or Kotlin. Chrome invests in an ever-stronger multi-process architecture built on sandboxing and site isolation to help defend against memory safety problems. Mistakes with pointers in these languages can lead to memory being misinterpreted. Chrome is primarily written in the C and C++ languages, which are vulnerable to memory safety bugs.
0 kommentar(er)
