The Digital Standard is an ambitious, community-led effort to build a framework to test and rate products and services on the basis of privacy, security, and data practices.
Creative Commons Attribution 4.0 International
128
stars
46
forks
source link
Add Memory Safety to Known Exploit Resistance #185
Security > Build Quality > Best Build Practices > Known Exploit Resistance > Memory Safety
Criteria: The product does not process input using software that is memory unsafe.
Indicators: The software is memory-safe and protected against buffer overflows, stack overflows, heap overflows, dangling pointers, type confusion, use after free, double free, use of uninitialized memory, and other memory access software bugs and vulnerabilities.
Procedure: Identify software being used and whether it is memory-safe. For example, C and C++ allow arbitrary pointer arithmetic with pointers implemented as direct memory addresses with no provision for bounds checking.
Reasoning: Roughly 60-70 percent of browser and kernel bugs are memory unsafety, which can be significantly mitigated by using memory safe languages. While companies using memory unsafe languages (C and C++) can sanitize their inputs, this is a losing battle, since it requires them to perfectly allocate, write, read and deallocate memory. This is why at least 65% of bugs found in C/C++ code bases are due to memory unsafety. Memory safe languages like Python, Ruby, etc. do allow memory unsafe extensions, but because the core language doesn’t have memory unsafety, the incidence of memory unsafe issues is much lower. And while it’s possible to create memory unsafe blocks in newer, more efficient languages like Rust, Go, or Swift, the risk is still more minimal and it’s easier to find, audit, and minimize.
A recent Google blog post says “Memory safety bugs in C and C++ continue to be the most-difficult-to-address source of incorrectness. We invest a great deal of effort and resources into detecting, fixing, and mitigating this class of bugs, and these efforts are effective in preventing a large number of bugs from making it into Android releases. Yet in spite of these efforts, memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android’s high severity security vulnerabilities.” That is why Google is not only working on improving detection of memory bugs but ramping up efforts to prevent them in the first place.
Fish in a Barrel on Twitter: "Thanks to Google's detailed technical data we can provide total memory unsafety statistics for public 0days by year: 2014 5/11 45% 2015 22/28 79% 2016 22/25 88% 2017 17/22 77% 2018 12/12 100% 2019 9/10 90% Total 87/108 81% #memoryunsafety"
Security > Build Quality > Best Build Practices > Known Exploit Resistance > Memory Safety
Criteria: The product does not process input using software that is memory unsafe.
Indicators: The software is memory-safe and protected against buffer overflows, stack overflows, heap overflows, dangling pointers, type confusion, use after free, double free, use of uninitialized memory, and other memory access software bugs and vulnerabilities.
Procedure: Identify software being used and whether it is memory-safe. For example, C and C++ allow arbitrary pointer arithmetic with pointers implemented as direct memory addresses with no provision for bounds checking.
Reasoning: Roughly 60-70 percent of browser and kernel bugs are memory unsafety, which can be significantly mitigated by using memory safe languages. While companies using memory unsafe languages (C and C++) can sanitize their inputs, this is a losing battle, since it requires them to perfectly allocate, write, read and deallocate memory. This is why at least 65% of bugs found in C/C++ code bases are due to memory unsafety. Memory safe languages like Python, Ruby, etc. do allow memory unsafe extensions, but because the core language doesn’t have memory unsafety, the incidence of memory unsafe issues is much lower. And while it’s possible to create memory unsafe blocks in newer, more efficient languages like Rust, Go, or Swift, the risk is still more minimal and it’s easier to find, audit, and minimize.
A recent Google blog post says “Memory safety bugs in C and C++ continue to be the most-difficult-to-address source of incorrectness. We invest a great deal of effort and resources into detecting, fixing, and mitigating this class of bugs, and these efforts are effective in preventing a large number of bugs from making it into Android releases. Yet in spite of these efforts, memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android’s high severity security vulnerabilities.” That is why Google is not only working on improving detection of memory bugs but ramping up efforts to prevent them in the first place.
References: