One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 8591388 |
| Date de publication | 2024-10-03 12:03:16 (vue: 2024-10-03 17:17:07) |
| Titre | Évaluation des atténuations et des vulnérabilités dans Chrome Evaluating Mitigations & Vulnerabilities in Chrome |
| Texte | Posted by Alex Gough, Chrome Security Team The Chrome Security Team is constantly striving to make it safer to browse the web. We invest in mechanisms to make classes of security bugs impossible, mitigations that make it more difficult to exploit a security bug, and sandboxing to reduce the capability exposed by an isolated security issue. When choosing where to invest it is helpful to consider how bad actors find and exploit vulnerabilities. In this post we discuss several axes along which to evaluate the potential harm to users from exploits, and how they apply to the Chrome browser. Historically the Chrome Security Team has made major investments and driven the web to be safer. We pioneered browser sandboxing, site isolation and the migration to an encrypted web. Today we\'re investing in Rust for memory safety, hardening our existing C++ code-base, and improving detection with GWP-asan and lightweight use-after-free (UAF) detection. Considerations of user-harm and attack utility shape our vulnerability severity guidelines and payouts for bugs reported through our Vulnerability Rewards Program. In the longer-term the Chrome Security Team advocates for operating system improvements like less-capable lightweight processes, less-privileged GPU and NPU containers, improved application isolation, and support for hardware-based isolation, memory safety and flow control enforcement. When contemplating a particular security change it is easy to fall into a trap of security nihilism. It is tempting to reject changes that do not make exploitation impossible but only make it more difficult. However, the scale we are operating at can still make incremental improvements worthwhile. Over time, and over the population that uses Chrome and browsers based on Chromium, these improvements add up and impose real costs on attackers. Threat Model for Code Execution Our primary security goal is to make it safe to click on links, so people can feel confident browsing to pages they haven\'t visited before. This document focuses on vulnerabilities and exploits that can lead to code execution, but the approach can be applied when mitigating other risks. Attackers usually have some ultimate goal that can be achieved by executing their code outside of Chrome\'s sandboxed or restricted processes. Attackers seek information or capabilities that we do not intend to be available to websites or extensions in the sandboxed renderer process. This might include executing code as the user or with system privileges, reading the memory of other processes, accessing credentials or opening local files. In this post we focus on attackers that start with JavaScript or the ability to send packets to Chrome and end up with something useful. We restrict discussion to memory-safety issues as they are a focus of current hardening efforts. User Harm ⇔ Attacker Utility Chrome Security can scalably reduce risks to users by reducing attackers\' freedom of movement. Anything that makes some class of attackers\' ultimate goals more difficult, or (better) impossible, has value. People using Chrome have multiple, diverse adversaries. We should avoid thinking only ab |
| Notes | ★★ |
| Envoyé | Oui |
| Condensat | 2024 ability about above access accessing achieve achieved achieving acknowledge action actions activities actor actors add adjacent adobe advanced adversaries adversary advocates affects after against aggregate alert alerting alex all allocated allow allows along already although always amenable analysis analyzing another any anything api apis application applied apply approach arbitrary architecture are area argue arrow artifacts asan ask attack attacker attackers attacks attempt attention attractive attributes: automatically availability available avoid away axes bad base based baseline basis because become before behind being beneficial best better both bounds browse browser browsers browsing budget bug bugs business but bypass c++ calls can capabilities capability capable cases category caught cause causing certain chain chains chance change changed changes changing cheapest cheese choose choosing chosen chrome chromium cisa class classes clearly click close closed closer coarsely code codebase codec collect combined community compile complex components conclusion confidence confident configurations confusion consider considerations constantly containers contemplating context contexts control conversely cookies corruption costs could counter couple coupled crash crashes created credentials critical crops cross cryptography current cycle data day days debug decisions deep defenders defense defensive delivered delivery deploying deprecation desired detectable detected detection develop device devote different differing difficult discover discovered discovery discuss discussion disrupted diverse document does domain dowd down download downloaded drawn driven easier easily easy economic economics effective effects effort efforts either emitting enable encouraging encrypted end ends enforcement engine engineer environment environments escalate escalation escape escaping evaluate evaluating even events every everywhere example examples execute executing execution existing exists expected expert expertise exploit exploitable exploitation exploited exploiting exploits exploring exposed expressing extension extensions extra fall fast faster feasible features feel fewer files finally find finding finds fingerprint fit fixed fixes flash flow focus focuses focussing follow following found fraction fractionally frame free freedom from front fuzz fuzzing get goal goals good gough gov gpu graft graphs grooming group groups guidelines gwp happen happens hardening harder hardware harm has have haven having helpful helps high higher hinder historically hit how however http identification iframes ignores illustrates immediate implement important impose impossible improved improvements improving incident include increases increasing incremental infinite info information initial install instead integrate integrated integrating integration intend interaction interface internal intervention interventions introduce introduced introduction intuitive invest investing investments involves isolated isolation isosceles issue issues its javascript jit kernel kits know knowledge known last latent later lateral launch launched layered lead leaks lend less level libraries library life lightweight like likely limited linear links linux lived local logs long longer look low lower machine made main maintaining maintenance major make makes making malicious manifest manipulate manipulation manual many mark markets may meaningfully mechanically mechanism mechanisms meet memory mesh metrics might migration mimics mindset minimal mitigating mitigation mitigations model modeled models modern modifying money more most move movement much multi multiple must need needed needs neglects network nihilism not note npu obtain occur offered often once one ones ongoing only onto open opening operate operating operations order other others otherwise out outlined outside over overwriting packets page pages particular party patched paths payouts pdf peng people per perceive perform performing performs perhaps persistent person piercing pioneered pipeline platform platfo |
| Tags | Tool Vulnerability Threat Legislation |
| Stories | |
| 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.