Hey Adobe, hackers have access to your Source Code!

Author: 1 Comment Share:

Introduction

Adobe recently announced it had been breached [1].  Among the problems are copied customer data and passwords, downloaded source code, and even possible access to modify source trees.  What a nightmare for Adobe!  One of the questions that popped into our heads: will we see new attacks against enterprises using exploits that target Adobe products because of this?  And, is finding flaws in software, and writing exploits easier because of access to source code?  As a professional source code auditor and instructor, I keep hearing this question all the time. The focus of this blog is answering the second question, because that pretty much answers the first.

How big is the problem?

Back in 2010, Julia Wolf pointed out that Adobe Acrobat had 13.5 Million lines of code [9].  To put that in perspective Firefox had 2.7 Million at that time.  Statistics on how many bugs/lines of code vary pretty widely, but we all know that the bigger the attack surface, the more bugs.  Wolf also mentions that Adobe uses static analysis tools, and Adobe has blogged about its fuzzing efforts [10].  Unfortunately, these tools are not likely to be doing a good job of weeding out all of the latest-and-greatest bugs. So not only do Adobe products have a large attack surface, but their widespread use ensures a large attack target base as well.

Skill of Exploit Groups

Dan Guido recently revisited the topic about the capability of “run-of-the-mill” exploit packs at BruCon 0x5 [2].  He did a nice job of showing how most of the common stuff is recycled exploits pulled from security research blogs like VUPENs blog [3].  Dan also spoke about how various APT groups were a bit more sophisticated, but not so much that they’re impossible to stop.  Their 0day exploits often weren’t even very reliable.  Of course more sophisticated APT groups, like the one that created STUXNET – sort of defy Dan’s overall premise [4].  So, can we say there are LOW, MED, and HIGH levels of exploit competency in the world?  Dan actually makes that point, by showing how well his college students can do.

Which bugs to hunt for?

So, why are common exploit packs not always as robust and novel as one might think?  And how does that relate to the topic at hand?  Well it relates because exploitation of memory corruption bugs has gotten more difficult on patched systems.  And finding bugs is not as easy as it once was in major desktop systems.  In the early 2000’s landing a stack buffer overflow exploit required a debugger and some well-known tricks.  So source code really wasn’t needed.  In today’s world of DEP/ASLR protections, and use-after-free and type confusion bugs [5], we believe access to source code will help if it falls into capable hands.  As defensive postures shift, we shouldn’t be surprised to see offensive tactics shift.  Figure 1, from a recent Microsoft study, shows a trend that is not at all surprising to those following the state of system software exploitation [6]:

 Exploitation Trends Chart

Figure 1: Exploitation Trends

The line in the chart shows a decrease in stack buffer overflow exploits, and an increase in use-after-free and type confusion bugs.  No surprise, because this shift is necessary for continued exploitation.

Does Source code help?

MWR Labs is a well-known exploit research group.  They did a source review of Webkit in April 2013 with the goal of finding a bug in Chrome.  They did find a good bug – a type confusion [7].  But why didn’t they reverse engineer Chrome?  Why start with the Webkit source code?  Because using the source was quicker, since finding bugs and writing memory corruption bugs are more complex nowadays.  The exploit writers must understand the size, state, member functions, etc. about a C++ object before most modern exploits can be reliably crafted.  Is it possible without source code?  Of course, IE exploits come out on a somewhat regular basis, and Peter Vreugdenhil of Exodus Intel frequently shares his built up knowledge on the tips and tricks of the trade [8].

Summary

We believe finding bugs and exploiting those vulnerabilities will be expedited if the source code makes it to groups capable of leveraging its power.  And based on the size of the attack surface and installation base the problem is big and will most certainly get bigger.  Furthermore, other types of design/logic issues will be easier to understand and leverage should memory corruption bugs prove difficult for whatever group is looking at the source code.  Stay tuned, and watch for new Adobe malware coming to an enterprise near you.

[1] http://blogs.adobe.com/asset/2013/10/illegal-access-to-adobe-source-code.html

[2] http://www.youtube.com/watch?v=z9UfoAyje-4

[3] http://www.vupen.com/blog/

[4] http://en.wikipedia.org/wiki/Stuxnet

[5] http://labs.bromium.com/2013/08/14/is-auditing-cc-different-nowadays/

[6] http://blogs.technet.com/b/security/archive/2013/07/25/the-impact-of-security-science-in-protecting-customers.aspx

[7] https://labs.mwrinfosecurity.com/blog/2013/04/19/mwr-labs-pwn2own-2013-write-up—webkit-exploit/

[8] https://www.exodusintel.com/#education

[9] https://www.troopers.de/wp-content/uploads/2011/04/TR11_Wolf_OMG_PDF.pdf

[10] http://blogs.adobe.com/asset/2009/12/fuzzing_reader_-_lessons_learned.html

Previous Article

Climbing Mount Never Rest: Features vs Security in Browsers

Next Article

Much Ado.be About Nothing New

You may also like

1 Comment

  1. Chris Rohlf ‏@chrisrohlf
    @JaredDeMott yes win2k leaked code led to 2 exploits. One in IE and one in mspaint iirc
    View conversation
    Julian Cohen ‏@HockeyInJune
    @JaredDeMott Some tools/techniques that generate input from symbolic execution and constraint solving (like SAGE and KLEE) require source.

Leave a Reply

Your email address will not be published. Required fields are marked *