C/C++ has been around for a long time. As you may know, it has issues; lots of them. And we can’t be rid of it; it’s still being used all the time in the creation of new software. But over time, have we gotten better at writing and auditing it? If so, are there newer bug types and patterns that we should now be looking for?
Answer: it depends. Many of the bugs from yester-year still exist in code, particularly older or immature code like SCADA, ICS, telematics, etc. Their secure software development lifecycle needs to catch up to desktop maturity. Speaking of which, most new C/C++ that is being written for mainstream, desktop-like systems is very complex: kernels, browsers, virtulizers, etc. And yes, there are new bug patterns to be found there.
The strcpys of yesterday won’t likely be found, and even if they were, exploiting them would be difficult with today’s protections. What today’s attacker needs is a bug that will give each of the three primary exploit primitives: read/write/execute. The read is used to leak information, often addresses related to the start of data structures and code modules. The write is often used to “update” objects, including function pointers. And of course, the execute redirection often begins with a stack pivot, ROP payload, shellcode, and maybe even sandbox escapes. Wow. Do such bugs exist? Yup.
I’ll be presenting a talk on this subject September 13th at GrrCon and again September 28th at DerbyCon. The talk begins with a background on yesterday’s bugs. Next it describes todays bugs, like use-after-free and type confusion. Code examples of bugs and fixes will be presented. The talk concludes with trends and thoughts on mitigations. Hope to see you there!