Google's Rust belts bugs out of Android, helps kill off unsafe code substantially Google says its effort to prioritize memory-safe software development over the past six years has substantially reduced the number of memory safety vulnerabilities in its Android operating system. In a report scheduled for publication on Wednesday, Google reveals the percentage of Android vulnerabilities attributable to memory …
"...a set of software development practices that attempts to avoid the introduction of vulnerabilities through memory safe programming languages, including Rust; static analysis; and API design"
While folks bang on about Rust (or other language du jour) as the solution to most problem, simply enforcing static analysis and proper API design would be a great start for most projects!
What sort of static analysis are you thinking of? There are forms of static analysis (including such as Polyspace and Absint for C. SPARK is available for Ada) which can unearth very deep errors. Proof of Absence of RunTime Errors has been around for decades and the automated proof engines have been growing in capability all the time.
This does not mean you should throw any rubbish at the tools - you need to follow sound design and implementation principles to get the best benefit. With poor code you tend to get swamped with warnings (rather than unambiguous hard errors or green lights) which you have to work to resolve.
These tools also lead in to formal verification of code behaviours. PARTE provides an interesting stepping stone in that runtime errors are indicative of erroneous code, but you don't need to formally define the behaviour since it can be derived from the language definition (or basic maths). However, PARTE often benefits from additional code annotations that define intended constraints for the code operation - the tools verify these constraints will be met and uses the constraints to simplify subsequent proofs.
Disclosure - I used to work in static analysis.
Abstract interpretation, as used by Polyspace and Absint, can indeed catch more defects statically than "simple" static data-flow analysis. However, decidability means that abstract interpretation is still not able to detect all errors. SPARK helps by limiting the features of the language that are permitted (it defines a language subset). Subsetting is very difficult to enforce within the C and C++ communities as there is a lot of pushback from developers who don't like being told that they are not to use (often large) parts of "their" language.
Formal verification is a good idea,but only a relatively small number of programmers understand that it exists, and even less understand how to use it. There is also a concern that you can end up with a vacuous proof (you've proved something, but did you really prove that the software is correct?), <a href="https://blogs.sw.siemens.com/verificationhorizons/2017/12/06/formal-tech-tip-what-are-vacuous-proofs-why-they-are-bad-and-how-to-fix-them/>but that's another story</a>...
However, the use of tools is essential as they help to improve the confidence in a system, even when they cannot prove that it is correct.
Static analysis can catch some non obvious errors.
Good practice would be to use multiple compilers with non-naive options (different compilers detect different things), multiple static analysers (different static analyser detect different things) and use tools like valgrind (or instrumented build, e.g., a properly setup in the olden days, setting up correctly STLport options for "debug" builds, could catch a lot of issue, such as dangling pointers).
Been seeing comments like “moop moop, you can do this in C++, Rust is for babies”, “Rust is a fad, that’s what they said about swift”, “Java is also memory safe and it’s crazy”… for YEARS
Glad some solid numbers are coming out. The combination of conceptual and architectural approaches in Rust is a step change, and it’s so good for the world to improve what we do. Yes, Rust too will die one day, but I’m pleased it exists as I’m sure it will stand as a significant block in the wall of human technological evolution.
No I’m not AI, yes that paragraph is trash, no I’m not rewriting it :)
@claimed "Glad some solid numbers are coming out."
But not that solid, as they are not using actual figures for 2024*. They could have used the figures from 2023 the last year they have full figures for. But then 2023 does not look as good as there was a slight increase in the total number of memory safety vulnerabilities over 2022.
Now I am not knocking their significant achievement in reducing memory safety vulnerabilities. Just it is annoying that they did not stick to complete full year figures for the report.
* "Note that the data for 2024 is extrapolated to the full year (represented as 36, but currently at 27 after the September security bulletin)."
"Just it is annoying that they did not stick to complete full year figures for the report."
And yet they also say:
"Instead of focusing on the interventions applied (mitigations, fuzzing), or attempting to use past performance to predict future security" (my italics).
Fucking gootards, talking out of both sides of their mouth, as usual. I hates 'em, I does.
Percent of "vulnerabilities" caused by memory safety bugs.
Quoting the cited blog article: "The percent of vulnerabilities caused by memory safety issues continues to correlate closely with the development language that’s used for new code. Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop."
The 70% figure has been published many times, by many software security types. It isn't hard to find.
This one (cited by the predecessor article to the one cited in this article) is an example, and it cites a dozen other reports: https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
