One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 8598282 |
| Date de publication | 2024-10-15 13:44:17 (vue: 2024-10-15 18:17:26) |
| Titre | Plus sûr avec Google: Faire progresser la sécurité de la mémoire Safer with Google: Advancing Memory Safety |
| Texte | Posted by Alex Rebert, Security Foundations, and Chandler Carruth, Jen Engel, Andy Qin, Core Developers Error-prone interactions between software and memory1 are widely understood to create safety issues in software. It is estimated that about 70% of severe vulnerabilities2 in memory-unsafe codebases are due to memory safety bugs. Malicious actors exploit these vulnerabilities and continue to create real-world harm. In 2023, Google\'s threat intelligence teams conducted an industry-wide study and observed a close to all-time high number of vulnerabilities exploited in the wild. Our internal analysis estimates that 75% of CVEs used in zero-day exploits are memory safety vulnerabilities. At Google, we have been mindful of these issues for over two decades, and are on a journey to continue advancing the state of memory safety in the software we consume and produce. Our Secure by Design commitment emphasizes integrating security considerations, including robust memory safety practices, throughout the entire software development lifecycle. This proactive approach fosters a safer and more trustworthy digital environment for everyone. This post builds upon our previously reported Perspective on Memory Safety, and introduces our strategic approach to memory safety. Our journey so far Google\'s journey with memory safety is deeply intertwined with the evolution of the software industry itself. In our early days, we recognized the importance of balancing performance with safety. This led to the early adoption of memory-safe languages like Java and Python, and the creation of Go. Today these languages comprise a large portion of our code, providing memory safety among other benefits. Meanwhile, the rest of our code is predominantly written in C++, previously the optimal choice for high-performance demands. We recognized the inherent risks associated with memory-unsafe languages and developed tools like sanitizers, which detect memory safety bugs dynamically, and fuzzers like AFL and libfuzzer, which proactively test the robustness and security of a software application by repeatedly feeding unexpected inputs. By open-sourcing these tools, we\'ve empowered developers worldwide to reduce the likelihood of memory safety vulnerabilities in C and C++ codebases. Taking this commitment a step further, we provide continuous fuzzing to open-source projects through OSS-Fuzz, which helped get over 8800 vulnerabilities identified and subsequently fixed across 850 projects. Today, with the emergence of high-performance memory-safe languages like Rust, coupled with a deeper understanding of the limitations of purely detection-based approaches, we are focused primarily on preventing the introduction of security vulnerabilities at scale. Going forward: Google\'s two-pronged approach Google\'s long-term strategy for tackling memory safety challenges is multifaceted, recognizing the need to address both existing codebases and future development, while maintaining the pace of business. |
| Notes | ★★★ |
| Envoyé | Oui |
| Condensat | 01730 1145/3651621 ↩ 1972 2008 2019 2023 2024 220 52–60 850 8800 about accelerate achieve acm across actively actors adam addition address adopting adoption advancing afl after against ahead air alex all allocated already also among amount analysis anderson android andy anticipate appealing application applications approach approaches architecture are aspects associated balancing barth based bedford been before being believe benefits beta between beyond billions borrow both boundaries: bounds broader browser bug bugs builds business c++ can cannot capabilities capability carbon carruth cases centered challenges chandler checking cheri choice chrome chromium classes close code codebase codebases coding3 collection command commitment committed common commun communities community component components comprise computer computing conducted conducting considerations consistently consume containment continue continuing4 continuous controls core corporate corresponding coupled create creation critical cross currently cves day days decades decrease decreased deep deeper deeply demands demonstrating deploying design details detect detection detection: developed developer developers development device devices digital discovered discussed division dominant down dramatically drastically drive driven drop dropping due during dynamically earlier early ecosystem ecosystems edu/projects/history/papers/ande72 edu/websec/chromium/chromium effectively effectiveness efficacy effortless electronic eliminated eliminating embedded embodying embrace embraced emergence emerging emphasizes empowered end engel enhanced enhancing entire environment environments error errors esd especially estimated estimates even everyone evolution example existing expand expanded experience exploit exploited exploits exploring extension far features feeding field finer firmware first fixed focused focuses force foreseeable forward forward: fosters foundations free from further future fuzz fuzzers fuzzing garbage get given going google google: gradually grained graphic graphics growth guided hanscom hardened hardening: hardware harm has have heap helped high https://doi https://seclab https://www identified identifying ignore immediate impact implementations importance important improve included includes including incorporates: increasing increasingly individual industry infrastructure inherent innovation innovative inputs instead instructions integrate integrating intelligence interactions internal interoperability intertwined introduced introduces introduction investing investment isolation issues itself java jen journey june kern kotlin lacking language languages large leading led level libfuzzer library lifecycle like likelihood limitations limiting linked long looking low made maintaining make making malicious mature means meanwhile memory memory1 memorysafety migration mindful miracleptr mitigated mitigations mobile more most msls mte muls multifaceted naptime necessary need needs network new next notes now number objective observed oct one ongoing open opportunity optimal org/10 org/docs/memory oss other out over overhead own pace particularly past path pdf pdf ↩ performance perspective phasing pillar planning platforms portion positive post posted potential practices predominantly preventative preventing previously primarily principles privilege privileged proactive proactively process processes produce products program progressively projected projects promising prone pronged protect protections provide providing publications purely python qin quickly ramp real reality rebert recognize recognized recognizing reduce reducing reduction related release remain remained remaining repeatedly report reported representing requires research residual resources responsibility rest result results retrofitting reward rewriting risc risk risks robust robustness roll rolling runs rust safe safer safety safety/#how same sandbox sandboxing sanitizers scale scripting seamless second sections secure security semiconductor server services severe seve |
| Tags | Tool Vulnerability Threat Studies Mobile Technical |
| 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.