Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Microsoft, Google, and other companies have all determined that about 70% of CVEs are memory-related. Here's the US government's take: https://www.cisa.gov/news-events/news/urgent-need-memory-saf...

These memory-related exploits disappear with Rust aside from in "unsafe" blocks (possibly the worst named keyword in any language... it should have been called "trusted"), and that means you have a smaller and more easily auditable attack surface for these types of memory-related exploits. Some code (e.g., FFI) can't be verified as memory-safe by the Rust compiler at compilation time so "unsafe" is there as an escape hatch. I've written a bunch of Rust since 2014 building things like webservers, realtime futures processing algorithms, MEV bots, etc., and I've only had to use "unsafe" a few times.

I've also worked in security on products at Fortune 100 companies, and C is a constant nightmare for CVEs. I think I have PTSD from having to update libcurl. The more software we have written in memory safe languages, the better off we all are.




Just to avoid any “cyclist rides more aggressively when wearing helmet” type behaviour:

It’s probably worth nothing that that vast majority of, and of large scale attacks, is basic shit that has nothing to do with memory safety.

There’s benefit to memory safety, but just cause you’re wearing a helmet doesn’t mean you’re completely safe.

Additionally, it’s not Google overall, but chromium project that find this, as well as not Microsoft overall, but specifically Windows. These are two projects that will naturally see a much higher rate of memory safety issues.


> not Microsoft overall, but specifically Windows

This isn't the case: https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...

> Since 2004, the Microsoft Security Response Centre (MSRC) has triaged every reported Microsoft security vulnerability.

They've never qualified it as Windows only, to my knowledge.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: