2 ms·
"No one bothered to look" is how most vulnerabilities work. Systems development produces code artifacts with compounding complexity; it is extraordinarily diffi
by tptacek 7mo ago
"No one bothered to look" is how most vulnerabilities work. Systems development produces code artifacts with compounding complexity; it is extraordinarily difficult to keep up with it manually, as you know. A solution to that problem is big news.
Static analyzers will find all possible copies of unbounded data into smaller buffers (especially when the size of the target buffer is easily deduced). It will then report them whether or not every path to that code clamps the input. Which is why this approach doesn't work well in the Linux kernel in 2026.
- rubendev 7mo agoWith a capable static analyzer that is not true. In many common cases they can deduce the possible ranges of values based on branching checks along the data flow path, and if that range falls within the buffer then it does not report it.
- tptacek 7mo agoBe specific. Which analyzer are you talking about and which specific targets are you saying they were successful at?
- canucker2016 7mo agoIntrinsa's PREfix static source code analyzer would model the execution of the C/C++ code to determine values which would cause a fault. IIRC they were using a C/C++ compiler front end from EDG to parse C/C++ code to a form they used for the simulation/analysis. see https://web.eecs.umich.edu/~weimerw/2006-655/reading/bush-prefix.pdf https://web.eecs.umich.edu/~weimerw/2006-655/reading/bush-pr... for more info. Microsoft bought Intrinsa several years ago.
- tptacek 7mo agoI'm sure this is very interesting work, but can you tell me what targets they've been successful surfacing exploitable vulnerabilities on, and what the experience of generating that success looked like? I'm aware of the large literature on static analysis; I've spent most of my career in vulnerability research.
- canucker2016 7mo agoPREfix wasn't designed specifically for finding exploitable bugs - it was aimed somewhere in between Purify (runtime bug detection) and being a better lint. One of the articles/papers I recall was that the big problem for PREfix when simulating the behaviour of code was the explosion in complexity if a given function had multiple paths through it (e.g. multiple if's/switch statements). PREfix had strategies to reduce the time spent in these highly complex functions. Here's a 2004 link that discusses the limitations of PREfix's simulated analysis - https://www.microsoft.com/en-us/research/wp-content/uploads/2004/05/ieee_sw_righting_software.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... The above article also talks about Microsoft's newer (for 2004) static analysis tools. There's a Netscape engineer endorsement in a CNet article when they first released PREfix. see https://www.cnet.com/tech/tech-industry/component-bugs-stamped-out/ https://www.cnet.com/tech/tech-industry/component-bugs-stamp...
- 3abiton 7mo agoBut what was the likelihood of this bug to be exploited by malicious actors?
- tptacek 7mo agoI don't understand the question.