Source |
GoogleSec |
Identifiant |
8587335 |
Date de publication |
2024-09-25 12:59:41 (vue: 2024-09-28 14:16:59) |
Titre |
Éliminer les vulnérabilités de sécurité mémoire à la source Eliminating Memory Safety Vulnerabilities at the Source |
Texte |
Posted by Jeff Vander Stoep - Android team, and Alex Rebert - Security Foundations
Memory safety vulnerabilities remain a pervasive threat to software security. At Google, we believe the path to eliminating this class of vulnerabilities at scale and building high-assurance software lies in Safe Coding, a secure-by-design approach that prioritizes transitioning to memory-safe languages.
This post demonstrates why focusing on Safe Coding for new code quickly and counterintuitively reduces the overall security risk of a codebase, finally breaking through the stubbornly high plateau of memory safety vulnerabilities and starting an exponential decline, all while being scalable and cost-effective.
We\'ll also share updated data on how the percentage of memory safety vulnerabilities in Android dropped from 76% to 24% over 6 years as development shifted to memory safe languages.
Counterintuitive results
Consider a growing codebase primarily written in memory-unsafe languages, experiencing a constant influx of memory safety vulnerabilities. What happens if we gradually transition to memory-safe languages for new features, while leaving existing code mostly untouched except for bug fixes?
We can simulate the results. After some years, the code base has the following makeup1 as new memory unsafe development slows down, and new memory safe development starts to take over:
In the final year of our simulation, despite the growth in memory-unsafe code, the number of memory safety vulnerabilities drops significantly, a seemingly counterintuitive result not seen with other strategies:
This reduction might seem paradoxical: how is this possible when the quantity of new memory unsafe code actually grew?
The math
The answer lies in an important observation: vulnerabilities decay exponentially. They have a half-life. The distribution of vulnerability lifetime follows an exponential distribution given an average vulnerability lifetime λ:
|
Notes |
★★★
|
Envoyé |
Oui |
Condensat |
000 1st 2019 2021 2022 2023 2024 2nd 3rd Lambda;:a ability about above absolute accelerating acceptable accidentally accounted achieve achieves achieving acknowledgements across action actually addition address adopting adrian advancements advantage affordably after against age agencies albeit alex alexopoulos alice align all alleviating allowing allows along already also analysis android answer answers anticipate api appear applied applying approach approaches are arms around assertions assessed asset associated assurance attackers attempting autocxx average away bar base based baseline battery battle become becomes been before began being believe below benefit bergstrom better beyond big board break breaking bug bugs building built bulletin business businesses but by: c++ can canaries cannot capability cat cause caused challenges change changes chart checked christoph chromium cisa class classes clear closely code code: codebase coding combat come comes coming committed commoditized commoditizing complexity comprehensive concept confirmed confirms conflict: consider consisted consistent constant constantly continue continued continues continuing continuous contributing control convenient correctness correlate cost costs counterintuitive counterintuitively coverage crafting creating creative crubit crucially currently cycle data decade decades decay decision decline decrease decreased defenders definitive demonstrated demonstrates density deployment design despite detecting detection detection: develop developer developers developing development diminish directly discovery disparate distribution does doesn doing domain don doubles down drive driven drop dropped dropping3 drops due each earlier ecosystem ecosystems effective effectively effectiveness efficient efforts eliminating emergency emilia empirical encapsulated end endless enforces entire especially establishes even ever every evidenced evident evolution evolving example except execution existing expansion expect expectations experiencing exploit exploited exploits exponential exponentially extend extensively extrapolated faster feasible features feedback fighting final finally finding findings first fix fixes fixing flow focus focused focusing following following: follows foss found foundation foundations fourth frequent frequently from full function fundamental further future fuzz fuzzed fuzzing game generalizes generation generation: generations generator get gets getting given google goregaokar government gradually grant grew growing growth half happen happens has have having helpful here high higher highlighted hindsight how however hunting impacting important impose improve improved improves improving incidents includes including incorporating increase increased increasing increasingly incremental incur incurs industry infinitely influx inherent initial initially instance instead insufficient integrity interoperability interventions introducing invariants invest investments issues its jeff journey just kasper kern known kotlin language languages large lars latencies leading leads learned leaving left less lessons level leverage leverages libfuzzer lies life lifetime lifetimes lifetimes2 like likely line live long looking losing low lower lowered made mainly majority make makeup1 making maliciously managing manish manner manufacturers many math matures measurement memory methods metrics might mitigating mitigation mitigations mitigations: modern modified months more mostly mouse much necessitating need new next norm not note noted notes now number numbers numerous observation observation: observed off offers often old older once one ongoing only organizations other over over: overall overhead overwhelmingly own paired paradigm paradoxical: parallel past patching path percent percentage performance pervasive phenomenon picture pioneered plateau platform positive possible post posted potentially practical practice practices precisely predict pressure preventing prevention previous primarily primary principles prioritize prioritizes prioritizing proactive proac |
Tags |
Tool
Vulnerability
Threat
Studies
Patching
Mobile
Prediction
Cloud
Conference
|
Stories |
|
Move |
|