|Memory Safety Bugs Form 70 Percent Of Vulnerabilities|
|Written by Kay Ewbank|
|Thursday, 14 February 2019|
Almost three quarters of all vulnerabilities found in Microsoft products come into the category of memory safety issues, according to a talk by a Microsoft Engineer at this year's BlueHat conference.
The figures came as part of a session titled "Trends, challenge, and strategic shifts in the software vulnerability mitigation landscape" that Matt Miller of Microsoft's Security Response Center gave at the Blue Hat conference in Israel.
The thinking at Microsoft is that because not all vulnerabilities can be removed, Microsoft has concentrated instead on exploit mitigations such as ASLR (Memory layout randomisation), Mem GC (a memory allocation hardening measure) and Control Flow Guard to prevent code reuse.
These techniques have been very successful, meaning that exploitation is becoming harder all the time. The number of zero day vulnerabilities used for mass attacks has essentially been reduced to zero, and fewer vulnerabilities are showing up in “mass market” exploit kits. As the more obvious attack vectors are blocked, attackers are moving to using social engineering, or more attacks on mobile phones and misconfigured servers.
However, memory safety issues remain the dominant target for attacks, where system memory is accessed in a way that exceeds its allocated size and memory addresses. This happens because Windows is mainly written in C and C++, and both languages allow developers to access memory in ways that make it more likely there's a vulnerability. According to Miller, the most common technique is Use After Free (UAF), where memory is freed after use but can still be accessed. Heap corruption is the other preferred route for attack.
The other change has seen attackers move away from basic memory errors to more sophisticated techniques that run code at specific memory addresses that are likely to be in use by applications or processes running on the system. The slide pack for the presentation is available on Github.
or email your comment to: firstname.lastname@example.org