Conversation

"Rust doesn't check integer overflow" is one of the worst reasons I've ever heard to avoid it in favor of a non-memory-safe language. You can turn on Rust integer overflow checks with a compiler flag. You can't turn on memory safety in non-memory-safe languages.

351

Replying to

You could argue that compiling with asan is turning on memory safety. Sort of.

Replying to

and

Not at all since the only issues it finds reliably are linear overflows. It can't detect temporal safety issues when allocations are out of the quarantine and can't detect most out-of-bounds accesses but rather only special cases. It can't detect anything within objects either.

Replying to

and

Sure they aren’t the same but not that different either. The tools available for “memory unsafe” languages (like asan, valgrind) catch the vast majority of memory bugs. Acting like it’s the wild wild west for C/C++ is silly.

Replying to

and

They detect memory corruption when it occurs at runtime not the presence of the memory corruption bugs. If the current usage of the program doesn't trigger memory corruption with those bugs, there's nothing for them to detect. They're far from detecting the vast majority of them.

Replying to

and

In almost any mature program, the vast majority of memory corruption bugs will be latent issues not actually corrupting memory between objects during regular usage. ASan only detects memory corruption when it occurs, only between objects (not within) and nowhere close to all.

Replying to

and

Do you have data to back this up? This has not been my experience.

Replying to

and

The vast majority of my memory bugs have to do with pointer invalidation (like access after a realloc)

Replying to

and

Finding bugs with ASan during regular usage / testing is a demonstration of the program having memory corruption bugs to the point that the bugs are corrupting memory during regular use, not just adversarial conditions. It's not relevant data or experience with this at all.

Replying to

and

I can boot up AOSP and open Chromium to example.org with the kernel, userspace and browser compiled with ASan. There are no bugs detected. I can run a substantial portion of the massive CTS with none detected. Rate memory corruption bugs are found has not gone down.

Replying to

and

Linux kernel is tested quite a bit with ASan these days and yet somehow there are hundreds of memory corruption bugs found every month on the SAME configurations that are tested ranging from ancient decades old ones to new ones. Flow of discoveries is accelerating not slowing.

5:31 PM · Mar 30, 2022Twitter Web App

Replying to

and

Even after writing great domain-specific fuzzers to use with ASan, clearly there are still a massive amount of edge cases triggering memory corruption that are left undiscovered. ASan can only find what actually happens at runtime, and as stated above, only a subset of that.

Replying to

and

The statistics for major real world open source projects where security research is actually done in any significant way would be totally impossible if you could find most memory corruption bugs by simply running the program in ASan through regular usage or their test suites.

Show replies

Replying to

and

The Linux kernel is an incredibly large and complex code base used by billions of applications each day, which obviously influences rate of bug detection. I’m not aware of any such project written in a memory safe language, so what are you comparing this with?

Replying to

and

Linux kernel is one example of the overall example I was using which is Android, an OS that's largely written in Kotlin and Java with the other half of the OS written in C and C++. Half of the codebase for both groups of languages are externally developed open source projects.

Show replies