4 ms·

C: >Programs written in the language often have security bugs arising from the language’s lack of memory safety. How often? “Have things changed now?: an emp

C: >Programs written in the language often have security bugs arising from the language’s lack of memory safety. How often? “Have things changed now?: an empirical study of bug characteristics in modern open source software” suggests that 8.8-17.2% of security bugs are caused by memory bugs. How many of these can be caught by better testing? I think the effects of memory bugs on security are often overstated.

beart 7y ago
If I could eliminate 17% of the bugs in a future code base by choosing to use a different language, I would need a strong reason not to.
- madmax96 7y ago
  The strong reason is given in the linked article. C is better supported, more stable, has more developers, and is better understood. Meanwhile many of these bugs could be caught by testing, which you should be doing anyway. You can also survive the effects of the bugs with other tools like stackguard with extremely low overhead, while still having the vast benefits of C described in the original article.
  - pjmlp 7y ago
    We have been hearing that matra for 40 years now, thankfully companies are finally getting wiser.
tomesco 7y ago
>I think the effects of memory bugs on security are often overstated. How often?
liamdiprose 7y ago
> Speaking at the BlueHat security conference in Israel last week, Microsoft security engineer Matt Miller said that over the last 12 years, around 70 percent of all Microsoft patches were fixes for memory safety bugs. https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
- madmax96 7y ago
  It seems like the Windows ecosystem hasn’t benefited from the improvements made by the research community. For example, Valgrind doesn’t run on Windows. Cross platform applications (like the ones studied in the referenced paper) don’t have nearly the same level of memory problems. I think that presenting the 70% figure as inherent to developing in C/C++ is misleading because of this. In fact, a brand new project could probably reach 0 (or very close to it) memory bugs in C++ by following modern testing practices and using the variety of dynamic and static analyzers that exist today.
  - pjmlp 7y ago
    You mean like Linux? https://www.youtube.com/playlist?list=PLbzoR-pLrL6rF8E5yyknJzrVQaHeYszTR https://www.youtube.com/playlist?list=PLbzoR-pLrL6rF8E5yyknJ... Plenty of tasty material how Linux ecosystem has benefited from the improvements made by the research community.
  - roca 7y ago
    Microsoft has lots of state-of-the-art dynamic and static analysis tooling for Windows. You don't hear much about it because a lot of it is closed source. E.g. here's some info about some of the static annotations they use in the kernel: https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/sal-2-annotations-for-windows-drivers https://docs.microsoft.com/en-us/windows-hardware/drivers/de... The links in the sidebar point to a lot of other stuff. If you look at the publications of MSR's software researchers, many of whom are very good, you will see lots of papers about finding bugs in Windows, some of which have been productized. > In fact, a brand new project could probably reach 0 (or very close to it) memory bugs in C++ by following modern testing practices and using the variety of dynamic and static analyzers that exist today. A bold claim to offer without evidence. Unfortunately even the best organizations have so far failed to achieve this.
    - madmax96 7y ago
      > Microsoft has lots of state-of-the-art dynamic and static analysis tooling for Windows. Right. If you look at the linked article, the Microsoft Engineer claimed 70% of security bugs in Microsoft products are caused by memory errors. Does Microsoft apply the same tools to all their products or only Windows? Do these tools even exist for other products? > A bold claim to offer without evidence. If one writes a new C++ program, tested with > 75% code coverage, tested with valgrind, the program passed coverity checks and clang static analysis, and they followed the best practices for hardening the host kernel, and told me that they still had an exploitable memory bug, I would be surprised. Notice that performing all those steps is still less effort than learning Rust and building the program in that. And you’d still have to harden your kernel and test anyway. The evidence? NGINX and Linux is written in C. If the situation was so dire, why isn’t every computer in the world compromised right this second?
staticassertion 7y ago
Even if it were 17%, that ignores impact. Impact of a bug in C is very often, at best, taking the entire service down, and at worse gaining full RCE. I also think that a percentage is a weak indicator in general. With bug bounties we're seeing a massive influx of vulnerability reports for exposed APIs - this is almost always XSS and CSRF. I am not discounting the impact of those vulns, only saying that percentages are very market driven.

beart 7y ago

If I could eliminate 17% of the bugs in a future code base by choosing to use a different language, I would need a strong reason not to.

madmax96 7y ago
The strong reason is given in the linked article. C is better supported, more stable, has more developers, and is better understood. Meanwhile many of these bugs could be caught by testing, which you should be doing anyway. You can also survive the effects of the bugs with other tools like stackguard with extremely low overhead, while still having the vast benefits of C described in the original article.
- pjmlp 7y ago
  We have been hearing that matra for 40 years now, thankfully companies are finally getting wiser.

tomesco 7y ago

>I think the effects of memory bugs on security are often overstated. How often?

liamdiprose 7y ago

> Speaking at the BlueHat security conference in Israel last week, Microsoft security engineer Matt Miller said that over the last 12 years, around 70 percent of all Microsoft patches were fixes for memory safety bugs. https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

madmax96 7y ago
It seems like the Windows ecosystem hasn’t benefited from the improvements made by the research community. For example, Valgrind doesn’t run on Windows. Cross platform applications (like the ones studied in the referenced paper) don’t have nearly the same level of memory problems. I think that presenting the 70% figure as inherent to developing in C/C++ is misleading because of this. In fact, a brand new project could probably reach 0 (or very close to it) memory bugs in C++ by following modern testing practices and using the variety of dynamic and static analyzers that exist today.
- pjmlp 7y ago
  You mean like Linux? https://www.youtube.com/playlist?list=PLbzoR-pLrL6rF8E5yyknJzrVQaHeYszTR https://www.youtube.com/playlist?list=PLbzoR-pLrL6rF8E5yyknJ... Plenty of tasty material how Linux ecosystem has benefited from the improvements made by the research community.
- roca 7y ago
  Microsoft has lots of state-of-the-art dynamic and static analysis tooling for Windows. You don't hear much about it because a lot of it is closed source. E.g. here's some info about some of the static annotations they use in the kernel: https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/sal-2-annotations-for-windows-drivers https://docs.microsoft.com/en-us/windows-hardware/drivers/de... The links in the sidebar point to a lot of other stuff. If you look at the publications of MSR's software researchers, many of whom are very good, you will see lots of papers about finding bugs in Windows, some of which have been productized. > In fact, a brand new project could probably reach 0 (or very close to it) memory bugs in C++ by following modern testing practices and using the variety of dynamic and static analyzers that exist today. A bold claim to offer without evidence. Unfortunately even the best organizations have so far failed to achieve this.
  - madmax96 7y ago
    > Microsoft has lots of state-of-the-art dynamic and static analysis tooling for Windows. Right. If you look at the linked article, the Microsoft Engineer claimed 70% of security bugs in Microsoft products are caused by memory errors. Does Microsoft apply the same tools to all their products or only Windows? Do these tools even exist for other products? > A bold claim to offer without evidence. If one writes a new C++ program, tested with > 75% code coverage, tested with valgrind, the program passed coverity checks and clang static analysis, and they followed the best practices for hardening the host kernel, and told me that they still had an exploitable memory bug, I would be surprised. Notice that performing all those steps is still less effort than learning Rust and building the program in that. And you’d still have to harden your kernel and test anyway. The evidence? NGINX and Linux is written in C. If the situation was so dire, why isn’t every computer in the world compromised right this second?

staticassertion 7y ago

Even if it were 17%, that ignores impact. Impact of a bug in C is very often, at best, taking the entire service down, and at worse gaining full RCE. I also think that a percentage is a weak indicator in general. With bug bounties we're seeing a massive influx of vulnerability reports for exposed APIs - this is almost always XSS and CSRF. I am not discounting the impact of those vulns, only saying that percentages are very market driven.