Full Report
Memory corruption vulnerabilities are 60%-70% of the issues exploited in the wild. There are many other classes of bugs so why are these so popular? This is what the article tackles. Ironically, it's the simplest way to do it. It all comes down to how expressive and unconstrained memory corruption vulnerabilities are. The usage of system() runs attacker controlled input on a computer, giving us lots of freedom. In the case of memory corruption, it's the same; we can create our own path with the infinite space of a weird machine. This expressive nature is really only offered with a few bug classes. With a simple logic bug, like an authorization issue, it is limited in nature. It has much more defined capabilities. Things like MTE and movement towards memory safe languages like Golang and Python are making memory corruption bugs harder and harder to exploit though. The author does make a distinction between memory corruption and memory unsafety. Memory corruption is commonly the effect of a memory unsafe bug. They reference a type confusion bug leading to memory corruption as an example. The author believes that true memory corruption vulnerabilities, like page table management in the kernel, will stay around but memory unsafety bugs will start to die. At the end of the day, memory corruption vulnerabilities are still likely to be used. They provide huge capabilities that cannot be paralleled. Additionally, they are easily abstractable. If I find an arbitrary read/write primitive, I can hide away the details to this with an API of sorts to continue using my exploits. This does not work well with logic bugs most of the time. Overall, a good post on why we like memory corruption vulnerabilities so much! It creates reusable primitives in an environment that can be repeated. Other bugs can't provide the same things, making them harder to find and harder to exploit for real gain.
Analysis Summary