Java Every-Days: Exploiting Software Running on 3 Billion Devices
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Gorenc, Brian
Spelman, Jasiel
Over the last three years, Oracle Java has become the exploit author's best friend. And why not? Java has a rich attack surface, broad install base, and runs on multiple platforms allowing attackers to maximize their return-on-investment. The increased focus on uncovering weaknesses in the Java Runtime Environment (JRE) shifted research beyond classic memory corruption issues into abuses of the reflection API that allow for remote code execution. This talk focuses on the vulnerability trends in Java over the last three years and intersects public vulnerability data with Java vulnerabilities submitted to the Zero Day Initiative (ZDI) program. We begin by reviewing Java's architecture and patch statistics to identify a set of vulnerable Java components. We then highlight the top five vulnerability types seen in ZDI researcher submissions that impact these JRE components and emphasize their recent historical significance. The presentation continues with an in-depth look at specific weaknesses in several Java sub-components, including vulnerability details and examples of how the vulnerabilities manifest and what vulnerability researchers should look for when auditing the component. Finally, we discuss how attackers typically leverage weaknesses in Java. We focus on specific vulnerability types attackers and exploit kits authors are using and what they are doing beyond the vulnerability itself to compromise machines. We conclude with details on the vulnerabilities that were used in this year's Pwn2Own competition and review steps Oracle has taken to address recent issues uncovered in Java. Brian Gorenc (@MaliciousInput, @thezdi) is the Manager of Vulnerability Research in HP's Security Research organization. His primary responsibility is running the Zero Day Initiative (ZDI) program and doing root cause analysis on ZDI submissions. Brian's current research centers on discovering vulnerabilities in popular software, analyzing attack techniques, and identifying vulnerability trends. Prior to joining HP he worked for Lockheed Martin on the F-35 Joint Strike Fighter program where he led the development effort of the Information Assurance (IA) products in the JSF's mission planning environment. Jasiel Spelman is a vulnerability analyst and exploit developer for the Zero Day Initiative (ZDI) program. His primary role involves performing root cause analysis on ZDI submissions to determine exploitability, followed by developing exploits for accepted cases. Prior to being part of ZDI, he was a member of the Digital Vaccine team where he wrote exploits for ZDI submissions and helped develop the ReputationDV service from TippingPoint. Jasiel's focus started off in the networking world but then shifted to development until transitioning to security. He has a B.A. in Computer Science from the University of Texas at Austin.
 Welcome and thanks for attending. This is Java every day exploiting software running on 3 billion devices. It's an honor to be speaking in front of you all today. I've been coming to this con for almost a decade now and this is the first time I'm presenting and I'm happy to be here. From the looks of it, more than half of you are hung over so we're going to take it real slow in the beginning and we'll speed up. Yeah, you're welcome. So we hope you enjoy this tour of Java's attack surface and you walk away with a greater understanding of the vulnerabilities that affect Java and where you can find your next zero day. The first thing we're going to do is start with the solution. Actually provided to us by the U.S. government. Unless it's absolutely necessary to run Java in a web browser, disable it as described below, even after updating to 7 U11, this will help mitigate other Java vulnerabilities that may be discovered in the future. So this actually came from advisory on the day that they released U11. So the U.S. government is telling you that you should not use the latest version of a software. You know it's been a rough year for a piece of software. But as we know, nobody in this room is actually going to follow what the U.S. government has to say so we're forced to do this presentation. So for the agenda, we're going to take a tour of Java's attack surface. We're going to describe the different vulnerability types that exist in the framework itself. Then we're going to go through a set of five case studies of the top vulnerability types in the Java framework. Provide you a set of proof of concepts for triggering those bugs. We actually just released them last week at Black Hat. They've all been patched there from our researchers in the zero-day initiative program. But they're good examples of the classic vulnerability types in Java. Then we're going to take that and we're going to look at what's being used in the landscape by attackers and then take an independent look at what Oracle is doing to fix the problem in Java. So a quick introduction. If you don't know who I am, my name is Brian Gorance. I work for Hewlett Packard. I run the zero-day initiative program which is the world's largest vendor agnostic bug bounty program. So we buy vulnerabilities and exploits. So if you have some and you want to sell them, let me know. I also run the PONDA owned hacking competition. I do root cause analysis on ZDI submissions. I'm a family man. I've got two kids and a wonderful wife. When I'm not spending time with them, I'm looking at assembly code looking for bugs. Hey, I'm Jayzels Spalman and I'm part of the zero-day initiative. I actually report to Brian. I spent a lot of my time looking at IDA and analyzing the case that gets submitted to ZDI. I'm known as wandering glitch on FreeNode and Twitter and I'm also behind the ZDI account. So why did we choose Java to look at? Well, we wanted to get was a more granular insight of the attack surface itself because we had a surge of submissions in late 2012, early 2013. And at the time the industry was focused on the sandbox bypass issue. We wanted to look independently at the framework itself and see if that was actually the case. We wanted to determine what the most common vulnerability type was, which part of the architecture, specifically the sub components of the architecture contained the most vulnerabilities and which ones produced the most severe vulnerabilities. Tying that with what's actually being used in the landscape to determine whether the CVSS scoring system was correct for those vulnerabilities. And then we also wanted to take that independent look at Java Oracle's response to the increased vulnerability discoveries in their product. So let's talk about the sample set that we had for this analysis. We scoped ourselves to modern day Java vulnerabilities. Every issue patched between 2011 and 2013. We performed a root cause analysis on over 120 unique Java vulnerabilities. This is probably the largest collection of Java vulnerabilities outside of Oracle or the NSA or some other nation states. We had the entire zero day initiative database, numerous vulnerability feeds, all the big name penetration testing tools and we actually had six Java zero days that we've already submitted to Oracle for patching in this analysis as well. So this is actually trending for next year's patches too. When we looked at the threat landscape, we worked with reversing labs and they provided us a sample set of 52,000 Java malware samples so we could understand what's actually being used out there today. If we look at the footprint of Java, it has a huge installation base and that's what makes it a big red target for attackers and they actually boast about it, Oracle boast about it during the installation process. Three billion devices run Java. According to Oracle, 1.1 billion desktops actually run Java itself and somebody produces 1.4 billion Java cards every year. I have no idea what a Java card is but I'm pretty sure it can't be updated and if it's running any part of Java, it's probably got a vulnerability in it. The other interesting thing is that schools are using Java for their base language for computer science students and so we have thousands and thousands of developers coming out every year and their core language is Java and as a result, there's been a massive widespread adoption of Java in the marketplace and the financial marketplace and in the mobile space so it's a really good target for attackers. If we look at the architecture itself, it's on the slide right here. There's over 50 subcomponents and that's what we're focusing on in this presentation is what is the most vulnerable pieces of this architecture and we'll cover a couple of them which will come up later in the presentation. The deployment subcomponent consists of the Java Webster capabilities and the Applet capabilities. Java FX is a set of APIs for creating and delivering rich internet applications. Java 2D, it produces 2D graphics and the library subcomponent, the actual lang and util components, provide the basic functionality for almost every application that's out there. So there is a wide range of capabilities and it allows developers to quickly implement complicated tasks and deploy applications quickly. Kind of right once, run everywhere. Let's look at the vulnerabilities themselves. What you're seeing here is patch statistics from Oracle from their patch releases. They've actually patched year over year more vulnerabilities every year with 50 vulnerabilities being patched that were remotely exploitable in 2011 with over 130 vulnerabilities remotely exploitable in the first half of 2013. So there's been a huge increase in research in that area and patching in that area. When they release a patch, they actually provide quite a bit of metadata and what you see on the screen is Java's SC risk matrix and it will tell application developers and people deploying the patches what they should know about the vulnerabilities themselves. What we see on the screen is a 2D component vulnerability. It is remotely exploitable without authentication. It garners a score of 10.0 which is the most severe vulnerability. So there's a lot of information there that we can look at and try to analyze to determine what the most vulnerable piece of the architecture is. The interesting thing about Oracle and the way that they actually score the CVSS is they assume that all the users running the Java Web Start and applets are running with administrative privileges. So they're actually giving themselves a more severe score on CVSS than most vendors probably would. If we take a look just at the information that's available from the patches, we can start to determine component rankings for the most vulnerable components in the architecture. The five that you see on the screen are responsible for half of the remotely exploitable vulnerabilities in Java to date or for 2011 through 2013. Deployment being number one, 2DB number two, followed by libraries, Java FX and AWT. But if you look at the rankings, you see the 2D component is producing vulnerabilities with the CVSS score of 9.43 on average. So you can argue that that is actually the worst component in the architecture. Some other interesting statistics is the 2D, there's been several components that have been patched in every single patch release over the last two and a half years. That would be deployment and 2D. And at one point there was two components that had double digit CDE counts in a single patch. The deployment which had 10 vulnerabilities patched in February 2013 and Java FX with 12 vulnerabilities in February 2013. If we tie that with the zero-day initiative submissions, we start to see some interesting stuff. We see that on average the zero-day initiative is receiving about five Java zero days every quarter with a high of 33 and one quarter thanks to Ben Murphy and Vitaly for the highest count submitted to our program in one quarter. Our researchers actually account for 36% of Java vulnerabilities with CVSS score 9 or higher. And that's a lot of vulnerabilities being patched. On average our researchers are scoring about a 9.28 in CVSS so they're focusing on severe vulnerabilities in the framework itself. And we can look at it in two ways. Either the ZDI researchers are focusing on the components that produce the most vulnerabilities or the components that they're focusing on end up in the most vulnerable list when they start looking at them. So it just depends on your perspective. So what we did is we took the 120 vulnerabilities that we had. We performed a root cause analysis on it and we bucketed them into the blue boxes up here. And the first one is privilege in sandbox issues followed by buffer overflows, followed by improper restrictions on buffer operations, untrusted pointer dereferences, integer overflow and a bunch of other issues. And what we found out was that the sandbox bypass issue was the most popular vulnerability in our collection followed by buffer overflows. But we could take an even more granular look at them, those specific issues by breaking them out into even further subcategories. So we broke them out into unsafe reflection which is the abuse of the reflection APIs to gain access to restrict components and bypass the sandbox. Another subcategory was least privilege violations which is the abuse of Java's do privilege blocks to execute code at a higher privilege and then type confusion which are vulnerabilities that confuse Java's type system either through the use of unserilized, deserialized untrusted data or other techniques. We had the classic heap based buffer overflow and stack based buffer overflow and then various other, like I said, process control issues. But the key takeaway for this is that Java suffers from every major class of bug that's out there and it's a really good case study on basically everything. So we take a look specifically at the sandbox bypass issue, those accounted for half of the vulnerabilities in our dataset. If you look at the pie chart you can see that the unsafe reflection vulnerability accounted for half of those. And then followed by least privilege violation which accounted for quarter. The interesting thing about these is they're really popular in the exploit kit community because you don't have to bypass any OS mitigations that just work. You don't have to bypass that, you don't have to bypass ASLR, they just work every single time. Every time you click on it a calculator pops up. It's quite good. If you look there on the actual timeline itself, that's what you're seeing is the blue chart, the actual timeline, those are the submissions into the zero day initiatives specifically for sandbox bypass issues. So we've been receiving these since early 2011 and late 2010. So Oracle is actually known about these issues for some time. If we look specifically at memory corruption style of vulnerabilities, out of bounds rights and heat based buffer overflows, there's really two causes for the access violations in those two classes so we could further analyze those bugs. We found out that a third of them were caused by integer overflows, causing an allocation of a smaller than intended buffer and the rest were incorrect arithmetic operations. So it's just interesting to see that there's different types of memory corruption issues and the granularity that you can get to. So taking all this information, all the publicly available information, all the information from the ZDI, we're able to determine the top seven vulnerability classes in Java. Number one being the unsafe reflection vulnerability which is most popular in the library subcomponent. The least, followed by least privilege which was also the most popular in the library subcomponent, followed by two classic memory corruption issues. Again, like we talked earlier, most of these ended up in the 2D subcomponent which was heat based buffer overflows and out of bounds rights. The untrusted pointer dereference which is actually my favorite bug in the Java framework, I don't know why they exist but they do and they're quite funny when they happen. Followed by we have heat based buffer overflows due to integer overflows and then type confusion issues. But to make it even more interesting, we wanted to lay all of that information on top of the architecture itself so we could understand what type of vulnerabilities existed in which subcomponents. And that's what you're seeing on the slide now. This is really one of the first times there's been a road map for vulnerabilities in Java for you to start looking for them. What you see is the subcomponents, then the packages that had vulnerable code in them, followed by the type of vulnerabilities that existed in that code base. And you see the 2D component suffers from memory corruption issues and that's mostly due to its native code use. The deployment subcomponent suffered from numerous command injection and process control problems and the rest of them on the slide here were sandbox bypass issues. The rest of the subcomponents in the architecture, we had the Java FX component which suffered from a lot of untrusted pointer dereferences and that's one of our case studies. The library subcomponent which suffered from sandbox issues and one of the subcomponents on the screen is interesting because it suffers from both sandbox and memory corruption issues. So that's the sound component. But this is really valuable for this audience specifically because it's a mapping that you can use to go bug hunting and look for stuff and hopefully submit them to the zero to initiative. But basically you're able to take a look at the 2D component and you know that you should be looking for heap based stuff or overflows or memory corruption issues. It's also useful when the patch comes out. You can use this as a way to scope what you need to look for when Oracle patches because they give you which component they're patching in that patch itself. So now what we're going to do is we're going to take a look at a set of case studies for the most popular vulnerability types that we talked about in the slides. There's a sandbox, we're going to do two case studies on sandbox issues in the library subcomponent, two different memory corruption issues in the 2D component and untrusted pointer dereferencing in the Java FX component. And again these pox were just released and so this is probably one of the second time they've actually been shown publicly. All right so the first bug we're going to go over is in the library subcomponent and it's a privilege in sandbox issue due to unsafe reflection but as a quick primer on what unsafe reflection is imagine you have a dispatch method that takes a string and then some arbitrary number of arguments. Based on the string it then will look up a function and make a call so if you pass it add it will look up the add method and dynamically invoke it. Unsafe reflection is when you don't have proper validation on that string such that you could call the delete everything method or something else. In CVE 2013, Ben Murphy found that using security explorations issue 54 and I'll talk about that in a second you could achieve a sandbox bypass. Issue 54 makes use of the invoke dynamic JVM opcode to get access to a protected method of a class without actually having an ‑‑ without having an instance of it. It requires the use of a custom created class which means usually the use of a framework such as ASM2 but if you really wanted you could hard code the bytes. After you've done that you can use method handle bind to get on the class loader and that will bind the method handle to the class loader such that you can invoke it. Once you've done that all you have to do is create a permission domain that contains all permission and you'll be able to load a class and disable the security manager. You do that either through the use of a static initializer within that class or within a method in that class. I'll go into that in this slide. So here you can see invoke dynamic would be our custom created class and get class handle would be the method we've defined within it. All that we'll do is make a call and it'll call the set define class handle method here and it'll send a method handle. In this case it'll be a method handle to the class loader's protected defined class method. We then save it off into our defined class handle static variable so we can access it later on. Once we've done that then we create a permission object and add all permission to it and create a protection domain based off that. Once we've done that we get access to our class loader and we bind the method handle to our class loader. At this point we can invoke the defined class method and load a malicious class that will then be able to disable the sandbox or the security manager. This was patched in JDK 7 update 21 through the use of the convert or by updating the convert method in sun invoke util dot wrapper. The main takeaway here is that there's now an if check such that if the parameter class is not an interface we will cast the given object to the given class. We can see in the previous version that there is no such check and as a result the after mentioned Pock will result in a class cast exception. The next weakness is also in the libraries up component and it is a privilege in sandbox issue due to least privilege violation. Least privilege violation exists because of the access controllers do privilege blocks. They take two arguments or the do privilege blocks takes two arguments the first of which is a class that can be anonymous or otherwise that exposes a run method. This run method will get run at a different context than you're currently within. The second optional argument is an access control context and that's basically a safe state of the security context that you're running within. When you're running an untrusted applet you're going to have a much lower privilege level than say the library code which could do whatever it wanted. Ben Murphy found in CVE 2014, 1484 that proxy dot new proxy instance does not save the colors access control context and as a result it will use the libraries. Unfortunately it requires an invocation handler that is able to execute an arbitrary statement. He then found that method handle proxies has a method as interface instance that can do exactly this and using this you can access the defined class method of class loader and load a malicious class. You still have one hurdle to go through in that you have to be able to execute this bound method without putting any user frames on the stack but that's still doable. So here we can see a little snippet of what you would have to do. You start off by deciding on a class that has an instance method you want to run at a higher privilege and you would instantiate it. You then create a method type based off the instance method's return value and the parameters it takes and the classes for parameters it takes. You then use the find virtual method to look up that method based off the desired class, the name of the method and the method type you just created. You bind it to the, you bind the method handle you just created to the desired class and then you run this method handles dot drop arguments which as the name implies drops arguments. What this means is that when the method handle is actually invoked in this case the first three arguments a object argument and method argument and an object array argument will just be dropped and not be sent to the actual method that's being called. At this point you create your invocation handler by making use of method handles dot as interface instance and you still have to create the proxy with proxy dot new proxy instance and you have to do that in a way that does not add user frames but that is doable. We haven't added it because adding it makes it very clear what the actual exploit is. So this was patched in three classes. First class is the method handles class and that was patched first in the find virtual method which now makes use of the find bound caller class method. The main take away from this is that you have the potential for null to be returned here which means when you make, when you call access virtual right below in find virtual you could potentially be sending null there. In method handle proxies you have an updated as interface instance method which now makes use of the maybe bind caller function. And in the maybe bind caller the main take away is that if the parameter class is null or if the parameter class is class loader's null which means it's library code then we will return the method handle without any further modification of it. Only then if that's not the case we will call the maybe, the bind caller method. The last function or last class that was modified as a result of this patch is the method handle implementation class and specifically the bind caller method. The main take away here is that the parameter class if it's null will just throw an internal error. Previous to this you would try to continue on using a C trampoline. That said we wouldn't actually make it here because we would die in this check and just return the method handle. All right so the next bug is in the 2D sub component and is a heat based buffer overflow due to integer overflow. It was reported to us by AXT AXT and CVE 2013 0809 exists in native C code. Java has what's called Java native interface and that allows for native code to be called from Java land. In this particular case the issue lies in SunAWT medialib, MLib image create and the issue lies because of improper validation. You have 4 arguments that are passed to this function MLib image create. The first is MLib type and that's just a type specifier used in a switch statement later on. Then you have 3 arguments channels width and height that are all MLib S32 which is a type def for a sign 32 bit integer. So there are some bounds placed on the input variables in that width and height must be greater than 1 or greater than 0 and channels must be greater than 1 and less than 4. But then once that's done, if the MLib type is MLib int, we will multiply height and channels by 4 and set that to WB. Then later on we will multiply that value by height. So if height times width times channels times 4 is greater than 2 to the 32 power, we'll end up setting a value to malloc that is smaller than we actually require. As a result when we actually start writing to this buffer, we'll overflow. Sorry. This was patched in JDK 7 update 17 through the use of the safe to mult macro and they added the use of this macro every time they did any sort of multiplication. Here we can see that they're making use of the safe to mult macro and if it fails, they'll return null. Otherwise, they'll actually do the multiplication on width and channels. Here we can see that we're making use of the macro yet again and checking it against WB and 4 and only if it succeeds, we'll multiply WB by 4. Same goes for WB and height before passing it to malloc. So the next vulnerability is also in the 2D sub component and is an out of bounds right due to integer overflow. It was reported to us by Vitaly Torupov and it also exists in native code specifically in SunADVT, ADVT image rep. It's accessible via SunADVT image representation and the issue lies in the last parameter which is an integer component raster object that has a scan line stride field that is used without any validation whatsoever. So here we can see a snippet of the setICM pixels function which is the vulnerable function and here we can see that the J object is the image component raster. Here is where we're getting access to the scan line stride field and we're now setting destination and source pointers. You can see that the destination pointer is being set based off some math that uses the scan line stride field. We then have an outer for loop where you have the source pointer and destination pointer incremented by pixel stride and scan line stride and this is done without any sort of validation to prevent integer overflow. We then update the source and destination pointers that we're actually going to be writing to and then inside our inner loop we once again increment destination pointer without any validation whatsoever. Finally we actually have the rights to it. So this was patched in JDK 7 update 21 through the use of three new macros, checked stride, checked source and checked dest and in addition Oracle actually did proper patching of this function by actually validating every argument to this function. So here are the three macros that were added and you can see that they're checking for any integer overflow by actually doing the calculations. If one occurs then they'll return false and not continue on. Same goes for the checked source and the checked dest functions. And here you can see that now X and W and Y and H are now actually being validated and you can see that the data offsets array is also being checked just in this case to make sure it's not null. And then here you can see the use of the three new macros. So the last vulnerability is in the Java effects subcomponent and is an untrusted pointer dereference which as Brian mentioned is his favorite bug in Java. It was reported to us by Vitaly Torpev and this particular one exists in the commsun web pane platform web page class. The issue lies because the web page class has native functions that are executed through Java native interface and one of them will allocate a buffer in C land and then return it back to Java land. This is then stored in the P page private instance variable. There is a public get page accessor method and some of the methods within the web page class will directly access the P page variable whereas others will actually make use of the get page accessor method. As a result we can subclass the class and reimplement get page and we can achieve memory corruption. So here we can see that the class is indeed public which means we can subclass it. Here we can see that the get page method is also public which also means we can subclass it. Here is one of the native functions, TWK set editable. It's private but above it we can see that there is a set editable function that is public so we can actually call it. Within it we see a call to TWK set editable where we are using get page, the value returned by get page as the parameter. So this was patched in an interesting way. We actually got a slew of untrusted pointer derefs all at the same time and in JDK 7 update 13, Oracle in kind of a make the hurting stop reaction just flat out banned the comms on web page package. As a result any attempt to access any class within that package or sub package would result in a package access exception error. There is also a package definition restriction list and that also contains the same thing. In fact, Brian will go into that a little later. It then properly patches in JDK 7 update 21 by making the get page method package private and final. With that I'm going to turn it back over to Brian so he can go over to Pone to own and how these are utilized in the threat landscape. So the first place we're going to look at to see how people are actually using the bugs themselves is Pone to own. This year when we were organizing Pone to own we decided to expand the scope of the competition and include browser plug ins into it. Mostly because they were being used by malware and being utilized and targeted attacks. So we added flash reader and of course Java. When we did that some people thought we were making it too easy. You can see Coast.org is giving out $20,000 for free. At the time it felt like that because there was a lot of zero day activity going on in Java and a lot of independent discovery going on. We thought it was important to highlight the browser plug ins. What our expectation was that the researchers who were going to come and participate in Pone to own would bring sandbox bypasses due to unsafe reflection. But that turned out not to be the case. They actually brought the top four vulnerability types affecting Java. If we look at the actual participants, James Forshaw brought a least privilege violation. Josh Drake brought a out of bounds write and out of bounds read. And Ben Murphy brought an unsafe reflection bug. So it's kind of interesting to see that basically all the top vulnerability types could be leveraged and used to win money in our competition. One of my favorite quotes when we were running Pone to own was Woop and security. We asked them if they were going to bring us an unsafe reflection vulnerability. And they go and Chucky says of course we've got unsafe reflection vulnerabilities but we wanted to bring you something interesting. So they brought the heat based buffer overflow. Looking at the landscape itself, the exploit kit authors are really jumping on the bandwagon. You can see that in the chart. This chart is depicting the 52,000 malware samples that we had and which vulnerability types and CVEs they were leveraging. And you see a huge increase in December and January, the recent months. This actually mirrors the independent discoveries that were going on at the time. And so that's just an interesting data point that people are looking at Java. It is a very popular application to audit. And if you're an exploit kit developer, you actually pretty much require to include two plus Java vulnerabilities just to stay competitive with the other exploit kits on the market. So it's quite a competitive marker out there for Java bugs. The attackers are upping their game. One of the interesting things about the chart itself is it shows that vulnerabilities in 2011 that were discovered in 2011 are still actively being used on the web. And that's because the installation process for Java is less than optimal. There have been several studies that have come out recently from stating that 93% of the install base hasn't updated to the latest patch a month after it's released and sometimes even up to a year. And the fact is that multiple major versions of Java can be installed on a desktop at one time. And as a result, attackers can actually target older versions. So we wanted to look at what's actually being utilized compared to what's actually in the framework itself. And what we see is that type confusion is actually the most common bug to be utilized in the landscape with over two thirds of the sample set being a type confusion bug. What you see is unsafe reflection taking a quarter followed by least privilege violation. And the three of the sandbox issues account for almost 90% of the actual activity out there on the web. Memory corruption issues do end up being exploited but it's very rare. And so there's more focus and in reality the sandbox issues are worth more because you don't have to bypass OS mitigations like DEP and ASLR. So now we're going to go through several exploitation techniques and one that is not as common but interesting to look at. All right. So the main goal with Java exploitation is at least with sandbox bypasses is to run system.setSecurityManager and pass null as the argument. This has the effect of nullifying the security manager which means at that point you can run or download anything you want. For memory corruption you usually have your usual techniques such as overwriting a function pointer but you still have to bypass DEP and ASLR. Something that's potentially easier is a technique that was given to us by Vitaly Torupov which is to make use of Java Bean statement class. And I'll go into that in the next slide. So Java Bean statement represents a single Java expression of the form instance variable dot instance method and arguments. What you could potentially do is say you have an out of bounds write and an out of bounds read you could allocate your buffer that's vulnerable then allocate a statement. A statement has an implicitly created access control context that is clearly going to be weaker since you're going to have it created in your untrusted applet. You then create a more powerful access control context by creating a permissions object adding all permission to it. Then you create a protection domain array out of that and then create an access control context using that. You then use your memory corruption bug to basically swap or replace the statements access control context with yours and then you can just execute the statement and it will execute with more privileges. Now I'm going to go through a piece of malware we have that actually makes use of a sandbox bypass and it's CVE 2012, 5076. Basic functionality and I'll show the code in a sec. Makes use of the generic constructor class to instantiate an anonymous class loader instance. Once it does that it uses manage object manager factory to get access to the load class protected method and it then invokes that class or invokes that method on a malicious class that implements privilege exception action and once it's done that it nullifies the security manager and runs it stage 2. So here we see that the first thing it's doing is getting the Java version and checking to see if it's 1.7. So if it's not JDK 7 it's just going to bail out. If it is it then grabs the class that implements privilege exception action and turns it into an array of bytes. We then make use of generic constructor to instantiate the anonymous class loader and we then get access to the load class protected method using manage object manager factory. At this point we invoke the method and load our malicious class and we then call method within it and forgot to mention all these function names are obviously very clear and easy to understand because we've de-offuscated it. This particular piece of malware was using allotories Java offuskator but they did not use advanced options such as code flow offuskation and it made it very easy to de-offuskate. We were able to just use normal compiler optimizations to remove basically dead code. So continuing on we call the trigger do prove block method and we give it two arguments. The class we just loaded and basically a string that's given by the HTML that serve this piece of malware up. Within the malicious class we start off in the trigger do prove block method and we first ‑‑ whoa. All right. Sorry about that. All right. So we first take our string and we split it by the characters h and j then we turn that into another string that we pass later on. We then get access to the given class's constructor and instantiate it and pass it the string that we just created. At this point we end up in the constructor and the first thing we do is make a call to access controllers do privilege block and we pass this as the variable. This has the effect of because we're ‑‑ because we implement privilege exception action this has the effect of calling a run method and nullifies the security manager. At this point everything after this is stage two because the vulnerability has fully taken place. So now we make ‑‑ now we call our stage two method and the first thing we do is grab the URL or create a handle to the URL that we were given and then we create a new file on disk in our app data directories called Java IO tempter. We then go through and download the file and drop it into that ‑‑ download the file from the URL and drop it into the Java IO tempter file. Then we try to execute it as an executable and failing that we will then try to load it as a DLL. At this point I'm going to hand it back over to Brian so he can go over how Oracle has been dealing with all of this. All right. So we kind of have a unique perspective on vendors and how they handle vulnerability disclosures because we handle so many of them. We've done over 200 just this year. Zero days patched through the vendors. In the case of Oracle, on average they are taking about three months to turn around a zero‑day submission which puts them right in the middle of pack for vendors but in reality what's going on with them is they've decreased their turnaround time year over year while the vulnerability submissions have gone up. So it's actually quite a feat when in 2011 you patched 50 bugs and then in 2013 you patched over 130 and you're actually decreasing your turnaround time. So from an external perspective it looks like they're staffing up the response organization to handle some of the vulnerabilities that are being discovered. They've increased their patch cycle. They release about four times a year, sometimes more when zero days are discovered but they've actually made public commitments to their customers to actually decrease the amount of time it takes to turn a patch when a zero day is discovered. One of the things that's not really reported very often is that they're aggressively adjusting the attack surface for Java which we'll go over next. They've actually killed several of the cases that we purchased and killed in this perspective means we've purchased the vulnerability, we've verified that it works and they release a patch and it kills the bug. And so in 2013 they killed three and in 2015 they killed two. And this is due to increased applet restrictions and also a tightening up of the least privileged violation bugs. What you see on this screen is actually the adjustments to the attack surface that they've made over the last several releases and we've baselined it in U9. They had about 12 packages in the restriction list and you see in U10 and U11 they didn't change it and in U13 they added another dozen or so packages to the package restriction list and one of those packages is Becom, the sun web pain package that we actually went over in the case studies. They're actually adding those in there as bugs are discovered and trying to tighten up the attack surface. In U15 you see that they actually removed packages which is kind of strange but what they're actually doing is removing lower level packages and adding higher level packages and so you see that it's commsunjmx remote.util was removed and commsunjmx was added. So there's further tightening the available packages that an applet can get to. In U21 they made a lot of changes. You see there but the same sort of thing. Removing lower level packages and adding more packages. The interesting thing is for everybody in this audience is those are where you want to look when they release a patch. If you're doing one day patch analysis or exploit development because there's vulnerabilities in that code base that they're trying to remove and so you can take this and the mapping that we provided and you can understand and reduce the amount of work that you have to do to look for bugs in the program, in Java itself and you can see that they're changing quite a bit. So what you see on the screen is the full package restriction list for JDK7 U25. There's 43 packages in the list right now and that's quite a change from U9 which had 12. And you see a lot of commsun or patchy packages and so you can expect in the future that they'll probably remove some of those and add a higher level package. So in conclusion Oracle has weathered quite the storm over the last two and a half years, three years. They've had a large number of vulnerability discoveries and just through our program alone we've had 50 plus zero day submissions over the last three quarters. Attackers are leveraging them most recently in attacks against Facebook and Apple and you've seen some of the largest Java security updates to date. Everybody's focusing on the sandbox bypass with unsafe reflection being the most prolific vulnerability in the architecture followed by with type confusion being the most popular, properly used vulnerability, most exploited vulnerability. The 2D component actually produces the most severe vulnerabilities but it's just not used. So when they come out with a 2D component with a CVSS or a 10, it's not in reality as important as the sandbox bypass issue which usually garners like an 8.6 or a 7.6. They've done some process improvements at Oracle. We talked about how they adjusted the attack surface and the increased patching and so they're actually working to fix the issues that they have. We want to thank everybody for showing up today and we want to thank the researchers who submitted zero day Java cases to us over the last three years. If you have a Java zero day and you'd like to sell it, make some legal money, where the avenue to do that, you can submit it at zerodayinitiative.com and we'll pay you and handle all the responsibility disclosure for you. We also want to thank the labs and security explorations for providing additional information to help us validate some of the assumptions we had early on in the paper development. So thanks for attending. Good luck bug hunting and we'll be in the chill out round to answer some questions if you have them. Thank you.
 Welcome and thanks for attending. This is Java every day exploiting software running on 3 billion  devices. It's an honor to be speaking in front of you all today. I've been coming to this con for  almost a decade now and this is the first time I'm presenting and I'm happy to be here. From the  looks of it, more than half of you are hung over so we're going to take it real slow in the  beginning and we'll speed up. Yeah, you're welcome. So we hope you enjoy this tour of Java's  attack surface and you walk away with a greater understanding of the vulnerabilities that affect  Java and where you can find your next zero day. The first thing we're going to do is start with  the solution. Actually provided to us by the U.S. government. Unless it's absolutely necessary to  run Java in a web browser, disable it as described below, even after updating to 7 U11, this will  help mitigate other Java vulnerabilities that may be discovered in the future. So this actually  came from advisory on the day that they released U11. So the U.S. government is telling you that  you should not use the latest version of a software. You know it's been a rough year for a  piece of software. But as we know, nobody in this room is actually going to follow what the U.S.  government has to say so we're forced to do this presentation. So for the agenda, we're going to  take a tour of Java's attack surface. We're going to describe the different vulnerability types  that exist in the framework itself. Then we're going to go through a set of five case studies of  the top vulnerability types in the Java framework. Provide you a set of proof of concepts for  triggering those bugs. We actually just released them last week at Black Hat. They've all been  patched there from our researchers in the zero-day initiative program. But they're good  examples of the classic vulnerability types in Java. Then we're going to take that and we're  going to look at what's being used in the landscape by attackers and then take an independent  look at what Oracle is doing to fix the problem in Java. So a quick introduction. If you don't  know who I am, my name is Brian Gorance. I work for Hewlett Packard. I run the zero-day  initiative program which is the world's largest vendor agnostic bug bounty program. So we buy  vulnerabilities and exploits. So if you have some and you want to sell them, let me know. I also  run the PONDA owned hacking competition. I do root cause analysis on ZDI submissions. I'm a  family man. I've got two kids and a wonderful wife. When I'm not spending time with them, I'm  looking at assembly code looking for bugs. Hey, I'm Jayzels Spalman and I'm part of the zero-day  initiative. I actually report to Brian. I spent a lot of my time looking at IDA and analyzing the  case that gets submitted to ZDI. I'm known as wandering glitch on FreeNode and Twitter and I'm  also behind the ZDI account. So why did we choose Java to look at? Well, we wanted to get was a  more granular insight of the attack surface itself because we had a surge of submissions in late  2012, early 2013. And at the time the industry was focused on the sandbox bypass issue. We wanted  to look independently at the framework itself and see if that was actually the case. We wanted  to determine what the most common vulnerability type was, which part of the architecture,  specifically the sub components of the architecture contained the most vulnerabilities and which  ones produced the most severe vulnerabilities. Tying that with what's actually being used in  the landscape to determine whether the CVSS scoring system was correct for those vulnerabilities.  And then we also wanted to take that independent look at Java Oracle's response to the  increased vulnerability discoveries in their product. So let's talk about the sample set that  we had for this analysis. We scoped ourselves to modern day Java vulnerabilities. Every issue  patched between 2011 and 2013. We performed a root cause analysis on over 120 unique Java  vulnerabilities. This is probably the largest collection of Java vulnerabilities outside of  Oracle or the NSA or some other nation states. We had the entire zero day initiative database,  numerous vulnerability feeds, all the big name penetration testing tools and we actually had  six Java zero days that we've already submitted to Oracle for patching in this analysis as well.  So this is actually trending for next year's patches too. When we looked at the threat  landscape, we worked with reversing labs and they provided us a sample set of 52,000 Java  malware samples so we could understand what's actually being used out there today. If we look  at the footprint of Java, it has a huge installation base and that's what makes it a big red  target for attackers and they actually boast about it, Oracle boast about it during the  installation process. Three billion devices run Java. According to Oracle, 1.1 billion  desktops actually run Java itself and somebody produces 1.4 billion Java cards every year.  I have no idea what a Java card is but I'm pretty sure it can't be updated and if it's  running any part of Java, it's probably got a vulnerability in it. The other interesting  thing is that schools are using Java for their base language for computer science students  and so we have thousands and thousands of developers coming out every year and their core  language is Java and as a result, there's been a massive widespread adoption of Java in the  marketplace and the financial marketplace and in the mobile space so it's a really good  target for attackers. If we look at the architecture itself, it's on the slide right here. There's  over 50 subcomponents and that's what we're focusing on in this presentation is what is the  most vulnerable pieces of this architecture and we'll cover a couple of them which will come  up later in the presentation. The deployment subcomponent consists of the Java Webster  capabilities and the Applet capabilities. Java FX is a set of APIs for creating and delivering  rich internet applications. Java 2D, it produces 2D graphics and the library subcomponent, the  actual lang and util components, provide the basic functionality for almost every application  that's out there. So there is a wide range of capabilities and it allows developers to  quickly implement complicated tasks and deploy applications quickly. Kind of right once,  run everywhere. Let's look at the vulnerabilities themselves. What you're seeing here is patch  statistics from Oracle from their patch releases. They've actually patched year over year more  vulnerabilities every year with 50 vulnerabilities being patched that were remotely exploitable in  2011 with over 130 vulnerabilities remotely exploitable in the first half of 2013. So there's  been a huge increase in research in that area and patching in that area. When they release a  patch, they actually provide quite a bit of metadata and what you see on the screen is Java's  SC risk matrix and it will tell application developers and people deploying the patches what  they should know about the vulnerabilities themselves. What we see on the screen is a 2D  component vulnerability. It is remotely exploitable without authentication. It garners a  score of 10.0 which is the most severe vulnerability. So there's a lot of information there  that we can look at and try to analyze to determine what the most vulnerable piece of the  architecture is. The interesting thing about Oracle and the way that they actually score the  CVSS is they assume that all the users running the Java Web Start and applets are running with  administrative privileges. So they're actually giving themselves a more severe score on CVSS  than most vendors probably would. If we take a look just at the information that's available  from the patches, we can start to determine component rankings for the most vulnerable  components in the architecture. The five that you see on the screen are responsible for half of  the remotely exploitable vulnerabilities in Java to date or for 2011 through 2013. Deployment  being number one, 2DB number two, followed by libraries, Java FX and AWT. But if you look at  the rankings, you see the 2D component is producing vulnerabilities with the CVSS score of 9.43 on  average. So you can argue that that is actually the worst component in the architecture. Some  other interesting statistics is the 2D, there's been several components that have been patched in  every single patch release over the last two and a half years. That would be deployment and 2D.  And at one point there was two components that had double digit CDE counts in a single patch. The  deployment which had 10 vulnerabilities patched in February 2013 and Java FX with 12  vulnerabilities in February 2013. If we tie that with the zero-day initiative submissions, we  start to see some interesting stuff. We see that on average the zero-day initiative is receiving  about five Java zero days every quarter with a high of 33 and one quarter thanks to Ben Murphy  and Vitaly for the highest count submitted to our program in one quarter. Our researchers  actually account for 36% of Java vulnerabilities with CVSS score 9 or higher. And that's a lot of  vulnerabilities being patched. On average our researchers are scoring about a 9.28 in CVSS so  they're focusing on severe vulnerabilities in the framework itself. And we can look at it in two  ways. Either the ZDI researchers are focusing on the components that produce the most  vulnerabilities or the components that they're focusing on end up in the most vulnerable list  when they start looking at them. So it just depends on your perspective. So what we did is we  took the 120 vulnerabilities that we had. We performed a root cause analysis on it and we  bucketed them into the blue boxes up here. And the first one is privilege in sandbox issues  followed by buffer overflows, followed by improper restrictions on buffer operations,  untrusted pointer dereferences, integer overflow and a bunch of other issues. And what we  found out was that the sandbox bypass issue was the most popular vulnerability in our collection  followed by buffer overflows. But we could take an even more granular look at them, those  specific issues by breaking them out into even further subcategories. So we broke them out into  unsafe reflection which is the abuse of the reflection APIs to gain access to restrict  components and bypass the sandbox. Another subcategory was least privilege violations which  is the abuse of Java's do privilege blocks to execute code at a higher privilege and then type  confusion which are vulnerabilities that confuse Java's type system either through the use of  unserilized, deserialized untrusted data or other techniques. We had the classic heap based  buffer overflow and stack based buffer overflow and then various other, like I said, process  control issues. But the key takeaway for this is that Java suffers from every major class of  bug that's out there and it's a really good case study on basically everything. So we take a look  specifically at the sandbox bypass issue, those accounted for half of the vulnerabilities in  our dataset. If you look at the pie chart you can see that the unsafe reflection vulnerability  accounted for half of those. And then followed by least privilege violation which accounted for  quarter. The interesting thing about these is they're really popular in the exploit kit  community because you don't have to bypass any OS mitigations that just work. You don't have to  bypass that, you don't have to bypass ASLR, they just work every single time. Every time you  click on it a calculator pops up. It's quite good. If you look there on the actual timeline  itself, that's what you're seeing is the blue chart, the actual timeline, those are the  submissions into the zero day initiatives specifically for sandbox bypass issues. So we've  been receiving these since early 2011 and late 2010. So Oracle is actually known about these  issues for some time. If we look specifically at memory corruption style of vulnerabilities,  out of bounds rights and heat based buffer overflows, there's really two causes for the  access violations in those two classes so we could further analyze those bugs. We found out  that a third of them were caused by integer overflows, causing an allocation of a smaller  than intended buffer and the rest were incorrect arithmetic operations. So it's just interesting  to see that there's different types of memory corruption issues and the granularity that  you can get to. So taking all this information, all the publicly available information, all  the information from the ZDI, we're able to determine the top seven vulnerability classes  in Java. Number one being the unsafe reflection vulnerability which is most popular in the  library subcomponent. The least, followed by least privilege which was also the most  popular in the library subcomponent, followed by two classic memory corruption issues. Again,  like we talked earlier, most of these ended up in the 2D subcomponent which was heat based  buffer overflows and out of bounds rights. The untrusted pointer dereference which is  actually my favorite bug in the Java framework, I don't know why they exist but they do and  they're quite funny when they happen. Followed by we have heat based buffer overflows due  to integer overflows and then type confusion issues. But to make it even more interesting,  we wanted to lay all of that information on top of the architecture itself so we could  understand what type of vulnerabilities existed in which subcomponents. And that's what you're  seeing on the slide now. This is really one of the first times there's been a road map  for vulnerabilities in Java for you to start looking for them. What you see is the subcomponents,  then the packages that had vulnerable code in them, followed by the type of vulnerabilities  that existed in that code base. And you see the 2D component suffers from memory corruption  issues and that's mostly due to its native code use. The deployment subcomponent suffered  from numerous command injection and process control problems and the rest of them on the  slide here were sandbox bypass issues. The rest of the subcomponents in the architecture,  we had the Java FX component which suffered from a lot of untrusted pointer dereferences  and that's one of our case studies. The library subcomponent which suffered from sandbox  issues and one of the subcomponents on the screen is interesting because it suffers from  both sandbox and memory corruption issues. So that's the sound component. But this is  really valuable for this audience specifically because it's a mapping that you can use to  go bug hunting and look for stuff and hopefully submit them to the zero to initiative. But  basically you're able to take a look at the 2D component and you know that you should  be looking for heap based stuff or overflows or memory corruption issues. It's also useful  when the patch comes out. You can use this as a way to scope what you need to look for  when Oracle patches because they give you which component they're patching in that patch  itself. So now what we're going to do is we're going to take a look at a set of case studies  for the most popular vulnerability types that we talked about in the slides. There's a sandbox,  we're going to do two case studies on sandbox issues in the library subcomponent, two different  memory corruption issues in the 2D component and untrusted pointer dereferencing in the  Java FX component. And again these pox were just released and so this is probably one  of the second time they've actually been shown publicly.  All right so the first bug we're going to go over is in the library subcomponent and  it's a privilege in sandbox issue due to unsafe reflection but as a quick primer on what unsafe  reflection is imagine you have a dispatch method that takes a string and then some arbitrary  number of arguments. Based on the string it then will look up a function and make a call  so if you pass it add it will look up the add method and dynamically invoke it. Unsafe  reflection is when you don't have proper validation on that string such that you could call the  delete everything method or something else. In CVE 2013, Ben Murphy found that using security  explorations issue 54 and I'll talk about that in a second you could achieve a sandbox bypass.  Issue 54 makes use of the invoke dynamic JVM opcode to get access to a protected method  of a class without actually having an ‑‑ without having an instance of it. It requires  the use of a custom created class which means usually the use of a framework such as ASM2  but if you really wanted you could hard code the bytes. After you've done that you can  use method handle bind to get on the class loader and that will bind the method handle  to the class loader such that you can invoke it. Once you've done that all you have to  do is create a permission domain that contains all permission and you'll be able to load  a class and disable the security manager. You do that either through the use of a static  initializer within that class or within a method in that class. I'll go into that in  this slide. So here you can see invoke dynamic would be our custom created class and get  class handle would be the method we've defined within it. All that we'll do is make a call  and it'll call the set define class handle method here and it'll send a method handle.  In this case it'll be a method handle to the class loader's protected defined class method.  We then save it off into our defined class handle static variable so we can access it  later on. Once we've done that then we create a permission object and add all permission  to it and create a protection domain based off that. Once we've done that we get access  to our class loader and we bind the method handle to our class loader. At this point  we can invoke the defined class method and load a malicious class that will then be able  to disable the sandbox or the security manager. This was patched in JDK 7 update 21 through  the use of the convert or by updating the convert method in sun invoke util dot wrapper.  The main takeaway here is that there's now an if check such that if the parameter class  is not an interface we will cast the given object to the given class. We can see in the  previous version that there is no such check and as a result the after mentioned Pock will  result in a class cast exception. The next weakness is also in the libraries  up component and it is a privilege in sandbox issue due to least privilege violation. Least  privilege violation exists because of the access controllers do privilege blocks. They  take two arguments or the do privilege blocks takes two arguments the first of which is  a class that can be anonymous or otherwise that exposes a run method. This run method  will get run at a different context than you're currently within. The second optional argument  is an access control context and that's basically a safe state of the security context that  you're running within. When you're running an untrusted applet you're going to have a  much lower privilege level than say the library code which could do whatever it wanted.  Ben Murphy found in CVE 2014, 1484 that proxy dot new proxy instance does not save the colors  access control context and as a result it will use the libraries. Unfortunately it requires  an invocation handler that is able to execute an arbitrary statement. He then found that  method handle proxies has a method as interface instance that can do exactly this and using  this you can access the defined class method of class loader and load a malicious class.  You still have one hurdle to go through in that you have to be able to execute this bound  method without putting any user frames on the stack but that's still doable. So here  we can see a little snippet of what you would have to do. You start off by deciding on a  class that has an instance method you want to run at a higher privilege and you would  instantiate it. You then create a method type based off the instance method's return value  and the parameters it takes and the classes for parameters it takes. You then use the  find virtual method to look up that method based off the desired class, the name of the  method and the method type you just created. You bind it to the, you bind the method handle  you just created to the desired class and then you run this method handles dot drop arguments  which as the name implies drops arguments. What this means is that when the method handle  is actually invoked in this case the first three arguments a object argument and method  argument and an object array argument will just be dropped and not be sent to the actual  method that's being called. At this point you create your invocation handler by making  use of method handles dot as interface instance and you still have to create the proxy with  proxy dot new proxy instance and you have to do that in a way that does not add user  frames but that is doable. We haven't added it because adding it makes it very clear what  the actual exploit is. So this was patched in three classes. First class is the method  handles class and that was patched first in the find virtual method which now makes use  of the find bound caller class method. The main take away from this is that you have  the potential for null to be returned here which means when you make, when you call access  virtual right below in find virtual you could potentially be sending null there. In method  handle proxies you have an updated as interface instance method which now makes use of the  maybe bind caller function. And in the maybe bind caller the main take away is that if  the parameter class is null or if the parameter class is class loader's null which means it's  library code then we will return the method handle without any further modification of  it. Only then if that's not the case we will call the maybe, the bind caller method. The  last function or last class that was modified as a result of this patch is the method handle  implementation class and specifically the bind caller method. The main take away here  is that the parameter class if it's null will just throw an internal error. Previous to  this you would try to continue on using a C trampoline. That said we wouldn't actually  make it here because we would die in this check and just return the method handle. All  right so the next bug is in the 2D sub component and is a heat based buffer overflow due to  integer overflow. It was reported to us by AXT AXT and CVE 2013 0809 exists in native C code.  Java has what's called Java native interface and that allows for native code to be called  from Java land. In this particular case the issue lies in SunAWT medialib, MLib image  create and the issue lies because of improper validation. You have 4 arguments that are  passed to this function MLib image create. The first is MLib type and that's just a type  specifier used in a switch statement later on. Then you have 3 arguments channels width  and height that are all MLib S32 which is a type def for a sign 32 bit integer. So there  are some bounds placed on the input variables in that width and height must be greater than  1 or greater than 0 and channels must be greater than 1 and less than 4. But then once that's  done, if the MLib type is MLib int, we will multiply height and channels by 4 and set that to  WB. Then later on we will multiply that value by height. So if height times width times  channels times 4 is greater than 2 to the 32 power, we'll end up setting a value to malloc  that is smaller than we actually require. As a result when we actually start writing to this  buffer, we'll overflow. Sorry. This was patched in JDK 7 update 17 through the use of the  safe to mult macro and they added the use of this macro every time they did any sort of  multiplication. Here we can see that they're making use of the safe to mult macro and if  it fails, they'll return null. Otherwise, they'll actually do the multiplication on width and  channels. Here we can see that we're making use of the macro yet again and checking it  against WB and 4 and only if it succeeds, we'll multiply WB by 4. Same goes for WB and height  before passing it to malloc. So the next vulnerability is also in the 2D sub component and  is an out of bounds right due to integer overflow. It was reported to us by Vitaly Torupov and  it also exists in native code specifically in SunADVT, ADVT image rep. It's accessible  via SunADVT image representation and the issue lies in the last parameter which is an integer  component raster object that has a scan line stride field that is used without any validation  whatsoever. So here we can see a snippet of the setICM pixels function which is the vulnerable  function and here we can see that the J object is the image component raster. Here is where  we're getting access to the scan line stride field and we're now setting destination and  source pointers. You can see that the destination pointer is being set based off some math that  uses the scan line stride field. We then have an outer for loop where you have the source  pointer and destination pointer incremented by pixel stride and scan line stride and this  is done without any sort of validation to prevent integer overflow. We then update the  source and destination pointers that we're actually going to be writing to and then inside  our inner loop we once again increment destination pointer without any validation whatsoever.  Finally we actually have the rights to it. So this was patched in JDK 7 update 21 through  the use of three new macros, checked stride, checked source and checked dest and in addition  Oracle actually did proper patching of this function by actually validating every argument  to this function. So here are the three macros that were added and you can see that they're  checking for any integer overflow by actually doing the calculations. If one occurs then  they'll return false and not continue on. Same goes for the checked source and the checked  dest functions. And here you can see that now X and W and Y and H are now actually being  validated and you can see that the data offsets array is also being checked just in this case  to make sure it's not null. And then here you can see the use of the three new macros. So  the last vulnerability is in the Java effects subcomponent and is an untrusted pointer dereference  which as Brian mentioned is his favorite bug in Java. It was reported to us by Vitaly Torpev  and this particular one exists in the commsun web pane platform web page class. The issue  lies because the web page class has native functions that are executed through Java  native interface and one of them will allocate a buffer in C land and then return it back  to Java land. This is then stored in the P page private instance variable. There is  a public get page accessor method and some of the methods within the web page class will  directly access the P page variable whereas others will actually make use of the get page  accessor method. As a result we can subclass the class and reimplement get page and we  can achieve memory corruption. So here we can see that the class is indeed public which  means we can subclass it. Here we can see that the get page method is also public which  also means we can subclass it. Here is one of the native functions, TWK set editable.  It's private but above it we can see that there is a set editable function that is public  so we can actually call it. Within it we see a call to TWK set editable where we are using  get page, the value returned by get page as the parameter. So this was patched in an  interesting way. We actually got a slew of untrusted pointer derefs all at the same time  and in JDK 7 update 13, Oracle in kind of a make the hurting stop reaction just flat  out banned the comms on web page package. As a result any attempt to access any class within  that package or sub package would result in a package access exception error. There is  also a package definition restriction list and that also contains the same thing. In  fact, Brian will go into that a little later. It then properly patches in JDK 7 update 21  by making the get page method package private and final. With that I'm going to turn it  back over to Brian so he can go over to Pone to own and how these are utilized in the threat  landscape. So the first place we're going to look at to see how people are actually  using the bugs themselves is Pone to own. This year when we were organizing Pone to  own we decided to expand the scope of the competition and include browser plug ins into  it. Mostly because they were being used by malware and being utilized and targeted attacks.  So we added flash reader and of course Java. When we did that some people thought we were  making it too easy. You can see Coast.org is giving out $20,000 for free. At the time it  felt like that because there was a lot of zero day activity going on in Java and a lot of  independent discovery going on. We thought it was important to highlight the browser  plug ins. What our expectation was that the researchers who were going to come and participate  in Pone to own would bring sandbox bypasses due to unsafe reflection. But that turned  out not to be the case. They actually brought the top four vulnerability types affecting  Java. If we look at the actual participants, James Forshaw brought a least privilege violation.  Josh Drake brought a out of bounds write and out of bounds read. And Ben Murphy brought  an unsafe reflection bug. So it's kind of interesting to see that basically all the top  vulnerability types could be leveraged and used to win money in our competition. One  of my favorite quotes when we were running Pone to own was Woop and security. We asked  them if they were going to bring us an unsafe reflection vulnerability. And they go and  Chucky says of course we've got unsafe reflection vulnerabilities but we wanted to bring you  something interesting. So they brought the heat based buffer overflow.  Looking at the landscape itself, the exploit kit authors are really jumping on the bandwagon.  You can see that in the chart. This chart is depicting the 52,000 malware samples that  we had and which vulnerability types and CVEs they were leveraging. And you see a huge increase  in December and January, the recent months. This actually mirrors the independent discoveries  that were going on at the time. And so that's just an interesting data point that people  are looking at Java. It is a very popular application to audit. And if you're an exploit  kit developer, you actually pretty much require to include two plus Java vulnerabilities just  to stay competitive with the other exploit kits on the market. So it's quite a competitive  marker out there for Java bugs. The attackers are upping their game. One of the interesting  things about the chart itself is it shows that vulnerabilities in 2011 that were discovered  in 2011 are still actively being used on the web. And that's because the installation process  for Java is less than optimal. There have been several studies that have come out recently  from stating that 93% of the install base hasn't updated to the latest patch a month  after it's released and sometimes even up to a year. And the fact is that multiple major  versions of Java can be installed on a desktop at one time. And as a result, attackers can  actually target older versions. So we wanted to look at what's actually being utilized  compared to what's actually in the framework itself. And what we see is that type confusion  is actually the most common bug to be utilized in the landscape with over two thirds of the  sample set being a type confusion bug. What you see is unsafe reflection taking a quarter  followed by least privilege violation. And the three of the sandbox issues account for  almost 90% of the actual activity out there on the web. Memory corruption issues do end  up being exploited but it's very rare. And so there's more focus and in reality the sandbox  issues are worth more because you don't have to bypass OS mitigations like DEP and ASLR.  So now we're going to go through several exploitation techniques and one that is not as  common but interesting to look at. All right. So the main goal with Java exploitation is at  least with sandbox bypasses is to run system.setSecurityManager and pass null as the argument.  This has the effect of nullifying the security manager which means at that point you can  run or download anything you want. For memory corruption you usually have your usual techniques  such as overwriting a function pointer but you still have to bypass DEP and ASLR. Something  that's potentially easier is a technique that was given to us by Vitaly Torupov which is  to make use of Java Bean statement class. And I'll go into that in the next slide. So  Java Bean statement represents a single Java expression of the form instance variable  dot instance method and arguments. What you could potentially do is say you have an out  of bounds write and an out of bounds read you could allocate your buffer that's vulnerable  then allocate a statement. A statement has an implicitly created access control context  that is clearly going to be weaker since you're going to have it created in your untrusted  applet. You then create a more powerful access control context by creating a permissions object  adding all permission to it. Then you create a protection domain array out of that and then  create an access control context using that. You then use your memory corruption bug to  basically swap or replace the statements access control context with yours and then you can  just execute the statement and it will execute with more privileges. Now I'm going to go  through a piece of malware we have that actually makes use of a sandbox bypass and it's CVE  2012, 5076. Basic functionality and I'll show the code in a sec. Makes use of the generic  constructor class to instantiate an anonymous class loader instance. Once it does that it  uses manage object manager factory to get access to the load class protected method and it  then invokes that class or invokes that method on a malicious class that implements privilege  exception action and once it's done that it nullifies the security manager and runs it  stage 2. So here we see that the first thing it's doing is getting the Java version and  checking to see if it's 1.7. So if it's not JDK 7 it's just going to bail out. If it is  it then grabs the class that implements privilege exception action and turns it into an array  of bytes. We then make use of generic constructor to instantiate the anonymous class loader and  we then get access to the load class protected method using manage object manager factory.  At this point we invoke the method and load our malicious class and we then call method  within it and forgot to mention all these function names are obviously very clear and  easy to understand because we've de-offuscated it. This particular piece of malware was  using allotories Java offuskator but they did not use advanced options such as code flow  offuskation and it made it very easy to de-offuskate. We were able to just use normal compiler  optimizations to remove basically dead code. So continuing on we call the trigger do prove  block method and we give it two arguments. The class we just loaded and basically a string  that's given by the HTML that serve this piece of malware up. Within the malicious class we  start off in the trigger do prove block method and we first ‑‑ whoa. All right. Sorry  about that. All right. So we first take our string and we split it by the characters h and j  then we turn that into another string that we pass later on. We then get access to the  given class's constructor and instantiate it and pass it the string that we just created.  At this point we end up in the constructor and the first thing we do is make a call to access  controllers do privilege block and we pass this as the variable. This has the effect of  because we're ‑‑ because we implement privilege exception action this has the effect of  calling a run method and nullifies the security manager. At this point everything after this  is stage two because the vulnerability has fully taken place. So now we make ‑‑ now we  call our stage two method and the first thing we do is grab the URL or create a handle to  the URL that we were given and then we create a new file on disk in our app data directories  called Java IO tempter. We then go through and download the file and drop it into that ‑‑  download the file from the URL and drop it into the Java IO tempter file. Then we try to  execute it as an executable and failing that we will then try to load it as a DLL. At this  point I'm going to hand it back over to Brian so he can go over how Oracle has been dealing  with all of this. All right. So we kind of have a unique perspective on vendors and how they  handle vulnerability disclosures because we handle so many of them. We've done over 200  just this year. Zero days patched through the vendors. In the case of Oracle, on average  they are taking about three months to turn around a zero‑day submission which puts  them right in the middle of pack for vendors but in reality what's going on with them is  they've decreased their turnaround time year over year while the vulnerability submissions  have gone up. So it's actually quite a feat when in 2011 you patched 50 bugs and then in  2013 you patched over 130 and you're actually decreasing your turnaround time. So from an  external perspective it looks like they're staffing up the response organization to handle  some of the vulnerabilities that are being discovered. They've increased their patch  cycle. They release about four times a year, sometimes more when zero days are discovered  but they've actually made public commitments to their customers to actually decrease the  amount of time it takes to turn a patch when a zero day is discovered. One of the things  that's not really reported very often is that they're aggressively adjusting the attack surface  for Java which we'll go over next. They've actually killed several of the cases that we  purchased and killed in this perspective means we've purchased the vulnerability, we've verified  that it works and they release a patch and it kills the bug. And so in 2013 they killed  three and in 2015 they killed two. And this is due to increased applet restrictions and  also a tightening up of the least privileged violation bugs. What you see on this screen  is actually the adjustments to the attack surface that they've made over the last several  releases and we've baselined it in U9. They had about 12 packages in the restriction list  and you see in U10 and U11 they didn't change it and in U13 they added another dozen or  so packages to the package restriction list and one of those packages is Becom, the sun  web pain package that we actually went over in the case studies. They're actually adding  those in there as bugs are discovered and trying to tighten up the attack surface. In  U15 you see that they actually removed packages which is kind of strange but what they're  actually doing is removing lower level packages and adding higher level packages and so you  see that it's commsunjmx remote.util was removed and commsunjmx was added. So there's further  tightening the available packages that an applet can get to. In U21 they made a lot of  changes. You see there but the same sort of thing. Removing lower level packages and adding  more packages. The interesting thing is for everybody in this audience is those are where  you want to look when they release a patch. If you're doing one day patch analysis or  exploit development because there's vulnerabilities in that code base that they're trying to  remove and so you can take this and the mapping that we provided and you can understand and  reduce the amount of work that you have to do to look for bugs in the program, in Java  itself and you can see that they're changing quite a bit. So what you see on the screen is  the full package restriction list for JDK7 U25. There's 43 packages in the list right now and  that's quite a change from U9 which had 12. And you see a lot of commsun or patchy packages  and so you can expect in the future that they'll probably remove some of those and add a higher  level package. So in conclusion Oracle has weathered quite the storm over the last two and a  half years, three years. They've had a large number of vulnerability discoveries and just  through our program alone we've had 50 plus zero day submissions over the last three quarters.  Attackers are leveraging them most recently in attacks against Facebook and Apple and you've  seen some of the largest Java security updates to date. Everybody's focusing on the sandbox  bypass with unsafe reflection being the most prolific vulnerability in the architecture  followed by with type confusion being the most popular, properly used vulnerability, most  exploited vulnerability. The 2D component actually produces the most severe vulnerabilities but  it's just not used. So when they come out with a 2D component with a CVSS or a 10, it's not  in reality as important as the sandbox bypass issue which usually garners like an 8.6 or  a 7.6. They've done some process improvements at Oracle. We talked about how they adjusted  the attack surface and the increased patching and so they're actually working to fix the  issues that they have. We want to thank everybody for showing up today and we want to thank  the researchers who submitted zero day Java cases to us over the last three years. If  you have a Java zero day and you'd like to sell it, make some legal money, where the  avenue to do that, you can submit it at zerodayinitiative.com and we'll pay you and handle all the  responsibility disclosure for you. We also want to thank the labs and security explorations  for providing additional information to help us validate some of the assumptions we had  early on in the paper development. So thanks for attending. Good luck bug hunting and we'll  be in the chill out round to answer some questions if you have them.  Thank you.
DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_0_803.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_804_1811.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_1812_2747.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_2748_3563.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_3564_3611.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_3612_3731.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_3732_3983.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_3984_4031.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_4032_4163.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_4164_5399.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_5400_6791.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_6792_8087.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_8088_9347.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_9348_9431.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_9432_11447.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_11448_13067.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_13068_14375.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_14376_16715.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_16716_18203.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_18204_19031.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_19032_20303.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_20304_21467.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_21468_22871.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_22872_23651.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_23652_23699.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_23700_23747.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_23748_23807.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_23808_26027.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_26028_27431.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_27432_27983.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_27984_28199.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_28200_32147.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_32148_32459.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_32460_32771.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_32772_33983.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_33984_34211.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_34212_36023.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_36024_36803.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_36804_37403.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_37404_38159.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_38160_39455.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_39456_39815.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_39816_40223.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_40224_40583.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_40584_40715.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_40716_41867.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_41868_42815.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_42816_43847.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_43848_44027.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_44028_46451.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_46452_48479.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_48480_49583.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_49584_49787.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_49788_50591.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_50592_51995.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_51996_52991.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_52992_54815.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_54816_55019.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_55020_55067.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_55068_55403.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_55404_57059.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_57060_57203.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_57204_57251.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_57252_59423.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_59424_61667.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_61668_62183.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_62184_63851.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_63852_64583.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_64584_64883.png DEF_CON_21_-_Brian_Gorenc_and_Jasiel_Spelman_-_Java_Every_Days_noNcfyxnTh0_64884_64893.png