1-616-874-7810 info@vdalabs.com

From the 90s to 2015ish memory corruption bugs in C/C++ programs, which lead to control flow hijacks (think buffer overflows etc.) were one of the hottest topics in security.  There were all kinds of talks, research projects, mitigations like EMET to stop ROP, etc.  Here’s a talk I gave a bit ago on such matters: ShmooCon talk on Recent Memory corruption advancements.

But the rapid pace of web and connected apps/devices has given rise for languages that are easier to develop in: higher level and safer.  Thus came “managed code” –  languages like Java, .Net, Ruby, Python, etc. These programs are unlikely to have memory corruption introduced by the programmer (though the interpreter is still written in C++ and could have memory corruption), because the language handles lower level memory allocation/frees.

However, as it turns out, these programs still have plenty of vulnerabilities, perhaps even more sometimes.  But they tend to be OWASP top 10 bugs.  So the nature of bug hunting has changed.  We’re fuzzing less, and doing less buffer overflow exploits, compared to prior years.  Also, current mitigations (like isolated heap, delayed free, pointer protection, etc.), make such memory corruption bugs hard to exploit.  Instead, as pentesters, we’re dumping databases with sqlmap, getting DA with responder, social engineering and using XSS, accessing unintended records with IDOR vulnerabilities, etc. as shown in our prior blog posts on Ruby on Rails vulnerabilities.

Clearly we’re not safer because memory corruption has decreased – hackers simply turn to other vectors.  But, the question is, are control flow hijacks still a thing? The answer is Yes.  People have been asking that for a decade.  It reminds of 2001 when I was told that IPv4 was going away, and that IPv6 would replace it “very soon”.  IPv6 is in use now.  Probably more all the time.  But it never really replaced IPv4.  Likwise, memory corruption is still around – perhaps more than security experts realize.  Here are a few recent memory corruption exploits:

  1. The MS17-010 bug exploited a memory corruption vulnerability in the Microsoft Windows SMB protocol. This bug was weaponized into an exploit called EternalBlue, a part of the Shadowbrokers leaks last year.
  2. Another Microsoft memory corruption bug was found recently in their Edge browser – CVE-2018-0834.
  3. Already this year there was another memory corruption based bug discovered in Microsoft Office dubbed CVE-2018-0802.
  4. These type of issues certainly aren’t unique to Microsoft – take for example this recent bug found in the very popular Xen hypervisor – CVE-2017-17536.
  5. Lastly, memory corruption bugs are definitely a problem for embedded devices and other platforms as shown by Cisco router CVE-2018-0101 – which ranked a whopping 10/10 CVE score! Not only that, but it has caused Cisco to send out two rounds of patches due to the challenges of fixing this particular bug.

Kernels, hypervisors, microcode, embedded systems, IoT, automobile engine control units, browsers, video parsers, office building HVAC systems, and much more — are all still written in C/C++.  Pentesters may be less versed in control hijack hunting and exploitation techniques, because they may not see those types of engagements on a regular bases.  But there is still a very real need for native programmers to use the newest protections like CFI, and to keep auditing/securing C/C++ – to keep our things, networks, and increasingly people safe.

In the spirit of continuing to kill bugs in C/C++, I’d like to recommend you check out the 2nd edition of our book: https://smile.amazon.com/Fuzzing-Software-Security-Testing-Assurance/dp/1608078507/ref=sr_1_3?ie=UTF8&qid=1517582326&sr=8-3&keywords=fuzzing+book