One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 8368444 |
| Date de publication | 2023-08-10 12:01:36 (vue: 2023-08-10 17:06:42) |
| Titre | Rendre le chrome plus sécurisé en apportant une épingle clé sur Android Making Chrome more secure by bringing Key Pinning to Android |
| Texte | Posted by David Adrian, Joe DeBlasio and Carlos Joan Rafael Ibarra Lopez, Chrome Security
Chrome 106 added support for enforcing key pins on Android by default, bringing Android to parity with Chrome on desktop platforms. But what is key pinning anyway?
One of the reasons Chrome implements key pinning is the “rule of two”. This rule is part of Chrome\'s holistic secure development process. It says that when you are writing code for Chrome, you can pick no more than two of: code written in an unsafe language, processing untrustworthy inputs, and running without a sandbox. This blog post explains how key pinning and the rule of two are related.
The Rule of Two
Chrome is primarily written in the C and C++ languages, which are vulnerable to memory safety bugs. Mistakes with pointers in these languages can lead to memory being misinterpreted. Chrome invests in an ever-stronger multi-process architecture built on sandboxing and site isolation to help defend against memory safety problems. Android-specific features can be written in Java or Kotlin. These languages are memory-safe in the common case. Similarly, we\'re working on adding support to write Chrome code in Rust, which is also memory-safe.
Much of Chrome is sandboxed, but the sandbox still requires a core high-privilege “broker” process to coordinate communication and launch sandboxed processes. In Chrome, the broker is the browser process. 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.
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. Conversely, if an attacker achieves RCE in a sandboxed process, such as a renderer, the attacker\'s capabilities are extremely limited. The attacker cannot reach outside of the sandbox unless they can additionally exploit the sandbox itself.
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 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.
Trustworthy inputs are defined extremely strictly: A “trustworthy source” means that Chrome can prove that the data comes from Google. Effectively, this means that in situations where the browser process needs access to data from e |
| Envoyé | Oui |
| Condensat | 106 2011 2022 3rd ability able access accessing achieve achieves actions add added adding additional additionally adrian after against age all allowed allowing allows also always android any anyway architecture are asymmetric attacker attackers attacks authenticate authenticated authentication authority authority; automatic because been before behind being benefits between beyond binary blocking blog bootstrapping born both bring bringing brittle broker browser browsers bug bugs build building built but c++ call came can cannot capabilities carlos cas case cases certain certificate certificates certification chance change changes chrome client code comes common communicate communicating communication comparing compiled comply component compromise compromised configuration connects consider considered constantly contains contents continuing control conversely coordinate coordinates core could craft cryptographically cryptography current data date david deblasio default defend defense defined deprecated desktop detects determined development device devices did different diginotar directly discover disrupt distribute distributing does domain drastically dynamic dynamically effectively enabled enabling enforce enforced enforcement enforcing engineers ensure entire entirely entity even ever excited execution expected explains exploit exploits external extremely failing fallback false feature features feed filled finch flashy flow framework from from: full further get give google handle happen happened hard has have haven having help high higher historically holistic how however hpkp https ibarra identity impersonate implementation implements important improved includes including individual information input inputs installs intended invests invisible ipc isn isolation issuance issue issued itself java joan joe just keep key kotlin language languages last latest launch lead like limit limitation limited limiting limits line list locking log lopez lot make making malicious manage managers many map means meant mechanism mechanisms memory messages misinterpreted mismatch mistakes modern more more: moved much multi must necessarily need needs new not now of: old omaha one only open operated operator original other out outside over package parity parse part parties party permanently pick pin pinned pinning pins pinset platforms pointers positive possible post posted potentially presenting prevent primarily privilege problems process processes processing program properties protect protection protects prove provide public push rafael rarely rather rce reach read real reasons receive recently reduces reflective related relative released relying remote remove removes renderer requires requiring rest restart risk risks rollout root rule running rust safe safety same sandbox sandboxed sandboxing says scenes secure security seemingly seen sent september server servers services set sets ship shipped sign similarly since site sites situations slow software some something source sources source” specific steps store strictly: stronger such support sure take talk than then there these third time timestamp tool tools transparency trick trust trusted trustworthy truth two two” unless unnecessarily unsafe untrustworthy update updated updater updates updating use used users using valid valves variations vendor verifies verify version versions victim vouched vouching vulnerable want wasn ways web website weeks well what when whenever where whether which who whom why wild: without working worth would write writing written “backup” “broker” “rule “trustworthy |
| Tags | Tool |
| Stories | |
| Notes | ★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.