 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 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. They're 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's doing to fix the problem in Java. So a quick introduction. If you don't know who I am, my name is Brian Gorenz. 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. And I do root cause analysis on ZDI submissions. I'm a family man. I've got two kids and a wonderful wife. And when I'm not spending time with them, I'm looking at assembly code looking for bugs. I'm part of the zero-day initiative. I actually report to Brian. I spend a lot of my time looking at IDA and analyzing the case that they get submitted to ZDI. I'm known as wandering glitch on free note and Twitter and I'm also behind the ZDI account. So why did we choose Java to look at? Well, we wanted to get 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 subcomponents 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 passed 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, the Oracle boast about it during the installation process, three billion devices run Java. According to Oracle, one point 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 WebStar capabilities and the app capabilities. Java FX is a set of APIs for creating and delivering rich internet applications. Java 2D 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's a wide range of capabilities and it allows developers to quickly implement complicated tasks and deploy applications quickly. Kind of right once, but run everywhere. But 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. 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, a CVSS 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. And the five that you see on the screen are actually responsible for half of the remotely exploitable vulnerabilities in Java to date or for 2011 through 2013. Deployment being number one, 2D being number two, followed by libraries, Java FX and AWT. But if you actually look at the rankings you see that the 2D component is producing vulnerabilities with the CVSS score of 9.43 on average. And 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 released 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 another 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 nine 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 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 and 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 restricted 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 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 data set. 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 a 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 DEP, 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 in the blue box, 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's actually known about these issues for some time. If we look specifically at memory corruption style of vulnerabilities, out of bounds writes 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 were 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, followed by lease 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 writes. 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 roadmap 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 actually one of our case studies. The library subcomponent which suffered from sandbox issues and one of the subcomponents on the screen is actually relatively 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 a 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 then we'll look up a function and make a call. So if you pass it add, it'll 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-24-36 Ben Murphy found that while 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 a 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 dot bind to to get on the class loader and that will bind the method handle to the class loader such that you can actually 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 sandbox or the security manager. You do that either through the use of a static initializer within that class or within a method in that class. And 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 define class method. We then save it off into our define class handle static variable so that 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 define 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 son 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 aforementioned POC will result in a class cast exception. The next weakness is also in the libraries up component and it is a privilege and sandbox issue due to least privilege violation. Least privilege violation exists because of the access controller's 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 is than you're currently within. The second optional argument is an access control context and that's basically a save 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 2013 1484 that proxy dot new proxy instance does not save the caller's access control context and as a result it'll 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 define 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 would 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 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 takeaway 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 and 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 takeaway 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'll just return the method handle without any further modification of it. Only then will we if that's not the case will we call the maybe or 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 takeaway 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. Alright so the next bug is in the 2D subcomponent and is a heap 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 well native code to be called from Java land. In this particular case the issue lies in son ADVT medialib MLib image create and the issue lies because of well improper validation. You have four arguments that are passed to this function MLib image create. The first is MLib type and that's just a type specifier that's used in a switch statement later on. Then you have three arguments channels within height that are all MLib S32 which is a type def for a sine 32 bit integer. So there are some bounds placed on the input variables in that width and height must be greater than one or greater than zero and channels must be greater than one and less than four. But then once that's done if the MLib type is MLib int we will multiply height and channels by four and sorry width and channels by four and set that to WB. Then later on we will multiply that value by height. So if height times width times channels times four is greater than two to the 32nd 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. All right. This was patched in JDK 7 update 17 through the use of the safe to mult macro and they added this check. They added the use of this macro every time they did any sort of multiplication. So 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 four and only if it succeeds will we multiply WB by four. Same goes for WB and height before passing it to malloc. So the next vulnerability is also in the 2D subcomponent and is an out of bounds right due to integer overflow. It was reported to us by Vitaliy Torapov and it exists in the, it also exists in native code specifically in Sun ADBT, ADBT image rep. It's accessible via Sun ADBT 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 set ICM pixels function where, which is the vulnerable function and here we can see that the J object GICT 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 a 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 right to it. So this was patched in JDK 7 update 21 through the use of three new macros, check stride, check source and check desk 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 check source and the check desk 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 corner dereference which as Brian mentioned is his favorite bug in Java. It was reported to us by Vitaliy Torapov and this particular one exists in the comm son web paying 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. And here is one of the native functions, TWK set editable. It's private but above it we can see that there's a set editable function that is public so we can actually call it and within it we see a call to TWK set editable where we're 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 deraps 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 comm son web pain package. As a result any attempt to access any class within that package or subpackage would result in a package access exception error. There's 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. And with that I'm going to turn it back over to Brian so that he can go over to Pone to Own and how these are utilizing the threat landscape. All right 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 did when we're organizing Pone to Own we decided to expand the scope of the competition and include browser plugins into it. Mostly because they were being used by malware and they were being utilized and targeted attacks. So we added Flash, Reader and of course Java. And when we did that some people thought we were making it too easy and you can see Kostia's quote up there, ZDI is giving out $20,000 for free. Which at the time it felt like that because there was a lot of zero day activity going on in Java. There was a lot of independent discovery going on. But we thought it was important to highlight the browser plugins. And 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 actually turned out not to be the case. They actually brought the top four vulnerability types affecting Java. And if we look at the actual participants James Forshaw brought a least privilege violation. Josh Drake brought an out of bounds write and out of bounds read. And Lupin security brought a heat based buffer overflow. And Ben Murphy brought an unsafe reflection bug. So it's kind of interesting just 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 actually when we were running Pone to Own was loop 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're actually pretty much a 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. So the main goal with Java exploitation is at least with sandbox bypasses is to run system.set security manager and pass null as the argument. This has the effect of well 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 Turpov which is to make use of the Java Bean statement class and I'll go into that on the next slide. So Java Bean statement represents a Java single Java expression of the form instance variable dot instance method and then arguments. What you could potentially do is say you have an out of bounds right or an out of bounds read. You could allocate your buffer that's vulnerable then allocate or create a statement. A statement has an implicitly created access control context that is well 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'll execute with more privileges. Now 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 then nullifies the security manager and runs it stage two. 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 allatories Java offuscator but they did not use advanced options such as code flow offuscation and it made it very easy to de-offuscate. 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 served 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 as 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 implement privilege exception action this has the effect of calling our run method and specifically nullifies the security manager. At this point everything after this is stage 2 because the vulnerability has fully taken place. So now we make, now we call our stage 2 method and the first thing we do is grab the URL, 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 and 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 that he can go over how Oracle has been dealing with all 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 turn around time year over year while the vulnerability submissions have gone up and so it's actually quite a feat when in 2011 you patched 50 bugs and then in 2013 you've patched over 130 and you're actually decreasing your turn around time so from an external perspective it actually 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 to 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 verify that it works and they release a patch and it kills the bug. And so in U-13 they killed three and in U-15 they killed two. I mean this is due to increased applet restrictions and also tightening up of the least privileged violation bugs. What you see on the screen is actually the adjustments to the attack surface that they've made over the last several releases and we've baselined it in U-9 and they had about 12 packages in the restriction list and you see in U-10 and U- 11 they didn't change it and in U-13 they added another dozen or so packages to the package restriction list and one of those packages is the com son 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 U-15 you see that they actually remove 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 there it's com son jmx remote dot util was removed and com son jmx was added so there's further tightening the available packages that an app can get to and U-21 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 export 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 JDK 7 U-25 there's 43 packages in the list right now and that's quite a change from U-9 which had 12 and you see a lot of com son or Apache 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 and with type confusion though being the most popular, popularly used vulnerability, most exploited vulnerability. The 2D component actually produces the most severe vulnerabilities but it's just not used and so when they come out with a 2D component with a CVSS score of 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've 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 that we're the avenue to do that. You can submit it at zerodayinitiative.com and we'll pay you and handle all the responsible disclosure for you. We also want to thank reversing 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 just to answer some questions if you have them.