Conversation
Edited 2 months ago
About vulnerability "half-life":

I still have to dig into the works referenced by the recent Google post, but the data is obviously based on known vulns.

https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

Because of this I think the conclusion shouldn't be that bugs naturally die out ("half-life"). Rather, if we have a fixed set of methods to discover vulns, we will eventually find everything _we currently can_ in a fixed code base, and we will again find some in new code.

I think Orange Tsai's latest work on Apache modules is a great demonstration of how a new approach can result in a bunch of CVE's. But the "realization" about format strings also comes to mind. How much "old" code had to be fixed because of that?

What I'd like to see is some data on memory-safe languages blocking otherwise vulnerable code paths, or vulns getting discovered during integration with safe languages.
2
5
8

@buherator The only way a vuln dies out of old age is when the compiler changes and builds safeguards around unsafe patterns or fixes them for you/demands that you fix them (but that's no longer a vuln, now it's a bug!).

Otherwise, vulns either just stay right where they are, get fixed or are deleted through rewrites (deleted... or translated into the new implem, which will be counted towards the "new stuff").

I will take the conclusions of the blog post with caution.

1
0
1
@karl Note that you just mentioned at least another way (deletion) a vuln can "disappear" :) There are probably many others (e.g. OS restricts API required for exploitation)...
1
0
0

@buherator Yes! I left that out thinking that either it's actually an environmental bug (the true issue lies in the API itself) or that if something gets incidentally fixed by changing how an API behaves under the hood, maybe such changes also open new ways to exploit the code, and it averages out.

Perhaps I should not have left that out, because APIs more often change for the better than not.

1
0
0
@karl No worries, I think compiling The Ways a Bug Can Die would be an interesting, non-trivial project by itself!
1
0
1