Slashdot Mirror

← Back to Stories (view on slashdot.org)

Every Browser Hacked At Pwn2own 2015, HP Pays Out $557,500 In Awards

Posted by Soulskill on from the another-four-bite-the-dust dept.

darthcamaro writes: Every year, browser vendors patch their browsers ahead of the annual HP Pwn2own browser hacking competition in a bid to prevent exploitation. The sad truth is that it's never enough. This year, security researchers were able to exploit fully patched versions of Mozilla Firefox, Google Chrome, Microsoft Internet Explorer 11 and Apple Safari in record time. For their efforts, HP awarded researchers $557,500. Is it reasonable to expect browser makers to hold their own in an arms race against exploits? "Every year, we run the competition, the browsers get stronger, but attackers react to changes in defenses by taking different, and sometimes unexpected, approaches," Brian Gorenc manager of vulnerability research for HP Security Research said.

22 of 237 comments (clear)

  1. Browsers getting too complex by ron_ivi · · Score: 3, Insightful

    Is it reasonable to expect browser makers to hold their own in an arms race against exploits?

    The problem is that browsers are trying to become an OS - with all the complexities associated with one.

    If we want back to a world where HTML was mostly about content -- that could be displayed in everything down to things like the Lynx browser -- they coudl be made secure.

    People wanted more, though -- so they decided to allow extensions like Java Applets, Flash Plugins, and ActiveX controls. Obviously more complex, those were not surprisingly insecure.

    So now people decide to take all the complexity and insecurity and build it directly into the browser itself?!? WTF.

    Makes me miss gopher clients. Maybe we should go back.

    TL/DR: Javascript+HTML5 is the new Java applet + Flash Player + ActiveX control.

    1. Re:Browsers getting too complex by dave420 · · Score: 4, Insightful

      There's nothing stopping you from going back. The rest of us can still use the vastly more functional modern web applications to get stuff done. Yes, there are security issues, but security issues exist regardless of whether they are in the browser or in software. It's not as if we never had any computer security issues before Web 2.0...

    2. Re:Browsers getting too complex by jellomizer · · Score: 4, Insightful

      I wouldn't say a browser is trying to be an OS but more of an interpreted language compiler.
      But if you turn off those nostalgia blinders. Of the days of the old web. We needed to install a program for almost everything, you needed an encyclopedia, then you put in that Encarta CD. Every piece of software worked for a particular OS. We had some multi-platform but they required other software that you needed to be lucky enough to have a version for your system as well. You needed ports open to share data with an other system...

      This is why back in the 1990's nearly everyone had to use windows. It is because buying a Mac, or using Linux will give you disadvantage in available software. The advanced browser opened up your Linux and Mac to the world, and people really don't care much what freaking OS you are using, because the content renders nearly the same.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    3. Re:Browsers getting too complex by tlhIngan · · Score: 4, Insightful

      TL/DR: Javascript+HTML5 is the new Java applet + Flash Player + ActiveX control.

      But it's far better than before. Because Flash Player and ActiveX you were limited to waiting for a third party to fix the flaw. There's nothing the browser vendor or the user could do. JavaScript/HTML5? The browser vendor's at fault and hell, it may even be possible to fix it yourself.

      JavaScript/HTML5 may be the new vulnerability, but it's a lot easier to fix the issue. If the vulnerability was in Flash Player or some random ActiveX object, you're stuck waiting for Adobe or other third party to make the fix. With JavaScript/HTML5, the browser vendor can fix it, if it's open source, you or the community can fix it.

      So yeah, there's vulnerabilities, but the resolution of which is far easier. It may even be simply switching browsers!

  2. If the browser authors spent more time... by Viol8 · · Score: 3, Insightful

    ... getting their code airtight and less time constantly fucking about with GUI and javascript interpreter - sorry, "engine" - changes perhaps these exploits could become less of an issue.

    1. Re:If the browser authors spent more time... by Richard_at_work · · Score: 3, Insightful

      Most people dont want shitty static pages, they want the application experience. Which is why we have the heavy browsers we have today.

  3. Build it yourself -- from source by mi · · Score: 3, Informative

    A security researcher identified by HP only as ilxu1a delivered the first exploit of the day with an out-of-bounds memory vulnerability in Firefox that took less than one second to execute. For his efforts, ilxu1a was awarded $15,000.

    To successfully exploit such a vulnerability (other than to make the browser to simply crash), and attacker needs to craft the attack to place just the right content into memory.

    By building the browser yourself (with CFLAGS, CXXFLAGS and even CC and CXX set to something unusual — such as to target only your specific -march) — rather than downloading prebuilt binaries — you make the attacker's job much harder. To successfully exploit your browser, he'll now need to make a custom exploit just for you.

    And, if you include -fstack-protector or equivalent among your compiler-flags, you may even be able to make such attacks impossible for good.

    --
    In Soviet Washington the swamp drains you.
    1. Re:Build it yourself -- from source by rudy_wayne · · Score: 4, Informative

      By building the browser yourself (with CFLAGS, CXXFLAGS and even CC and CXX set to something unusual — such as to target only your specific -march) — rather than downloading prebuilt binaries — you make the attacker's job much harder. To successfully exploit your browser, he'll now need to make a custom exploit just for you.

      And, if you include -fstack-protector or equivalent among your compiler-flags, you may even be able to make such attacks impossible for good.

      Technically, this is correct.

      However, I've tried to make my own custom builds of Firefox and it's a nightmare. The build process used by Firefox is so complicated and convoluted, it would make Rube Goldberg laugh. I haven't tried building Chrome, but reading the build instructions, it appears to be only marginally better.

  4. How many of the exploits can be blamed on C? by Pinky's+Brain · · Score: 3, Insightful

    Are the majority of exploits due to bugs which would be trivially detected at compile time let alone runtime in a modern language as usual?

    1. Re:How many of the exploits can be blamed on C? by Lunix+Nutcase · · Score: 3, Interesting

      What a joke. "Modern" languages allow all sorts of security exploits through. Such as this hilarious one involving Ruby on Rails.

    2. Re:How many of the exploits can be blamed on C? by Lunix+Nutcase · · Score: 4, Insightful

      Because they lack any historical perspective like most language hipsters.

  5. Exploit details (sort of) by Nermal · · Score: 5, Informative

    The article doesn't provide many details on what these exploits actually were, but in case anyone else is curious like I was they appear to be published on the ZDI site:

    Broad strokes for new discoveries

    Details for older exploits

  6. How much would NoScript mitagte the FF Vulns? by SirBitBucket · · Score: 5, Insightful

    Curious how much NoScript would mitigate the Firefox vulnerabilities. I find the mild annoyance of having to enable scripting occasionally is well worth it.

    1. Re:How much would NoScript mitagte the FF Vulns? by Anonymous Coward · · Score: 3, Insightful

      Nearly all of them likely.

      99.9% of exploits are delivered via JS as sort of obfuscation mechanism. Otherwise said exploits would be immediately be caught by simple heuristics facilities and input sanitization.

      Honestly, that's the real problem with Web security. We've got a system where it's seen as acceptable to run un-trusted, un-signed code, from unknown or untrusted sources, requested by websites with similarly deficient credentials.

      Really, just point your browser at any modern website and you'll be loading and executing dozens of scripts from dozens of domains, all with absolutely zero credential checking. Web developers will tell you this is "standard practice" and "necessary". Computer security experts just laugh, shake their heads, and enjoy their job security.

  7. Re:Plug-ins were scapegoats but now we can't go ba by ThePhilips · · Score: 5, Insightful

    [...] they are also trying to write secure software in unsuitable programming languages like C++.

    Right. So tell me, what "suitable" language would allow the browser to parse 200-500K of minified JS code in under 0.5 second? (200K == JQuery + few JQ plug-ins, 500K - JQuery + lots of JQ plug-ins.) Anyway, browsers already do resort to optimizations in assembler, because even C++ is not fast enough for what the web has become.

    So now we can't use tried and tested plug-in technologies to actually make stuff, and we all have to use HTML5+JS instead, even though in some areas they are still far inferior to what we had before with Flash or Silverlight or Java applets.

    Integration with 3rd parties is a bitch. That was and remains the main reason why plug-ins suck.

    Portability is another big reason. Windows, iOS and Android do things in starkly different ways, making portable plug-ins even harder.

    The problem are not plug-ins per se. The problem is that Google steers development of the Web toward its own goal which is to make the OSs obsolete. The short-sighted strategy resulted in overbloated browsers, with all the consequences for the security. Worse, they keep "optimizing" the browsers instead of e.g. integrating the JQuery/etc right into the browser to avoid repeating the loading of the same every time user clicks a link.

    --
    All hope abandon ye who enter here.
  8. Re:IE Fell first. by Anonymous Coward · · Score: 4, Funny

    IE Fell First...

    But then George Lucas decided to edit it?

  9. Re:IE Fell first. by suutar · · Score: 3, Insightful

    so, since the attackers came with prewritten exploits, that essentially means that IE got tested first. And this means what?

  10. Re:IE Fell first. by Anonymous Coward · · Score: 5, Funny

    Shaka, When the Browsers Fell

  11. Re:IE Fell first. by barbariccow · · Score: 4, Interesting

    These are "stock" browsers without security plugins or addons, correct? None too surprising really.

    You mean malware like Symantec? I agree, exploiting anything on a Symantec infested machine would take much longer... but only because everything running on that system would run at about 1/17th max throughput.

  12. dodged another bullet. by nimbius · · Score: 4, Funny

    I was at Pwn2own and NEVER ONCE experienced an exploit thanks to my browser of the future: Links.

    now if youll excuse me i need to gloat...there are some arpanet users on gopher that are going to be mighty impressed by this.

    --
    Good people go to bed earlier.
  13. Re:Plug-ins were scapegoats but now we can't go ba by ThePhilips · · Score: 4, Informative

    Slashdot is pretty "lightweight" and yet:

    The size of JS embedded on this page I'm replying from is 33K in about 890 lines of code.

    Externally loaded libraries are (most minimified):

    http://a.fsdn.com/sd/all-minified.js?release_20150309
    http://player.ooyala.com/v3/85...
    http://a.fsdn.com/sd/html5.js
    http://a.fsdn.com/sd/comments-...
    http://www.googleadservices.co...

    Total size: 1147446 bytes, aka 1.1MB.

    You are welcome.

    --
    All hope abandon ye who enter here.
  14. Re:Plug-ins were scapegoats but now we can't go ba by sexconker · · Score: 3, Interesting

    window.onbeforeunload = function(){while(1);}

    Throw that on a page, close the tab, and lol.

    Browsers happily execute what the page commands it to before considering what you the user commanded it to do. There are poorly-documented restrictions on things you can do during beforeunload or unload, all varying across browsers. I don't think you can alert(), you can return 'Some Shit' but it always displays a stock message ("Do you want to leave this page?"), IE will block window.open calls, etc. There's still plenty of room for you to fuck the user's experience over, however.

    Eventually the browser's long-running script timer will grant you, the pitiful user, the option to fucking do what you want.