4 ms·

> 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 o

> 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?
    - dpbriggs 7y ago
      Look no further than the browser you're likely using: Google Chrome. There's 91 code executions and 121 RCEs, details here: https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 https://www.cvedetails.com/product/15031/Google-Chrome.html?... And the project has some of the best testing and practices in the world. Constant fuzzing, significant test coverage [0], no doubt there's memory sanitizers, etc. It's increasing clear that large projects written in memory-unsafe languages will contain memory unsafety. > 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? Nice hyperbole. Check the stats [1]. [0] https://analysis.chromium.org/p/chromium/coverage https://analysis.chromium.org/p/chromium/coverage [1] https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
      - madmax96 7y ago
        >Nice hyperbole Not hyperbole. Most of these bugs are never known to be exploited by attackers. >Check the stats In your first link, there was one memory corruption vulnerability in Chrome last year. If we're looking at RCEs, CVE-2019-5762 and CVE-2019-5756 appear to have the same root cause (a memory bug), and CVE-2018-6118, CVE-2018-6111, and CVE-2017-15401 (which is also the memory corruption vulnerability) are also memory bugs. So it looks like Chrome had ~4 serious memory vulnerabilities last year. Don't have time to dig right now, but it appears similar observations hold for [1].

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?
  - dpbriggs 7y ago
    Look no further than the browser you're likely using: Google Chrome. There's 91 code executions and 121 RCEs, details here: https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 https://www.cvedetails.com/product/15031/Google-Chrome.html?... And the project has some of the best testing and practices in the world. Constant fuzzing, significant test coverage [0], no doubt there's memory sanitizers, etc. It's increasing clear that large projects written in memory-unsafe languages will contain memory unsafety. > 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? Nice hyperbole. Check the stats [1]. [0] https://analysis.chromium.org/p/chromium/coverage https://analysis.chromium.org/p/chromium/coverage [1] https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
    - madmax96 7y ago
      >Nice hyperbole Not hyperbole. Most of these bugs are never known to be exploited by attackers. >Check the stats In your first link, there was one memory corruption vulnerability in Chrome last year. If we're looking at RCEs, CVE-2019-5762 and CVE-2019-5756 appear to have the same root cause (a memory bug), and CVE-2018-6118, CVE-2018-6111, and CVE-2017-15401 (which is also the memory corruption vulnerability) are also memory bugs. So it looks like Chrome had ~4 serious memory vulnerabilities last year. Don't have time to dig right now, but it appears similar observations hold for [1].