1

On modern user oriented devices, such as Android phones, iPhones, PCs(Windows, MacOS, Linux), if there is a remote buffer overflow 0 day, are they only exploitable with the aid of multiple vulnerabilities? An example of this is the need to bypass ASLR or NX. It seems on modern devices exploiting a buffer overflow has become very complicated and expensive to chain together multiple 0 days in order to exploit a fully patched system.

john doe
  • 648
  • 4
  • 15
  • This depends massively on the vulnerability. One in the network stack might be triggerable remotely on its own; one in the filesystem handling could require layered exploits. "Buffer overflow" is a _gigantic_ category. – Nic Jul 24 '19 at 19:42
  • @NicHartley Let me clarify to remote buffer overflow, and sure its able to be triggered remotely, but can someone do anything like exfiltration of data from a system with only 1 remote buffer overflow exploit – john doe Jul 24 '19 at 20:19
  • 1
    What you're asking is essentially "how thick is a piece of nylon string?" Specifying that it's "nylon" (remote) means that there are certain theoretical and practical limits, but you're still asking about a _massive_ spread of possibilities. – Nic Jul 24 '19 at 20:20
  • I feel that it is difficult to speak in such absolutes, yes. – multithr3at3d Jul 25 '19 at 21:42

1 Answers1

2

It depends on your definition of "exploit", what piece of software you're targeting, and where the bug is.

For example, if I found a bug in Chrome's renderer (i.e. the thing that draws webpages on your screen) that gave me code execution, I'd only have code execution in the sandboxed context of the renderer process that runs in low integrity mode. I'd then need to find a sandbox escape (e.g. via exploiting a bug in one of the privileged Chrome IPC services offered to the renderer process) that allows me to gain code execution in a higher privileged Chrome process, then possibly another bug to escape API restrictions or other sandboxing protections. However, if I were to find a bug in the privileged Chrome process itself that was somehow possible to trigger from JavaScript, I would probably need only that bug.

By comparison, if I found a bug in Call of Duty 5 that let me gain remote code execution from a corrupted voice chat packet (using that example because voice chat is usually direct peer-to-peer) then I might get immediate code execution as the user.

Bypassing mitigations isn't itself considered an exploit - we usually refer to it as a technique. You may have to leverage multiple techniques in order to build a successful exploit, and those techniques may have to rely upon problems or mistakes in the code or build config, but those problems aren't generally considered vulnerabilities. As an example, a process might have ASLR but load a DLL which was not configured with ASLR enabled, allowing an attacker who was building an exploit to utilise the fixed address space of that module in order to build a ROP chain. The lack of ASLR on that module might be raised as an issue alongside the actual vulnerability, but most would not consider it a vulnerability on its own.

You're correct that it is generally difficult to bypass all mitigations on modern systems. The exploit mitigations on modern operating systems are generally doing their jobs well. On a heap use-after-free bug in a Windows application that has CFG + (Hi)ASLR + DEP + ACG + EAF/IAF enabled you're pretty much relying on pure luck that the bug you found and the memory layout you're presented with gives you enough control to be able to come up with a workable JOP chain. This often requires great skill and weeks of work. Ultimately the exploit mitigations are designed to increase the cost of developing working exploits when vulnerabilities are found, and I would say that the economics of building exploits on properly configured modern software is shifting further away from the attackers' favour.

Polynomial
  • 132,208
  • 43
  • 298
  • 379