10 ms·

Chrome OS exploit: WebAsm, Site Isolation, crosh, crash reporter, cryptohomed

222 points by chx 9y ago

Izmaki 9y ago
It’s great to see the bug program in effect. Also a huge thank you to all the whitehats our there!
eugeneionesco 9y ago
Beautiful chain of exploits, well done.
mbertschler 9y ago
Does reward 100000 mean 100k$ in bounty?
- Ajedi32 9y ago
  Yes. https://www.google.com/about/appsecurity/chrome-rewards/ https://www.google.com/about/appsecurity/chrome-rewards/ > We have a standing $100,000 reward for participants that can compromise a Chromebook or Chromebox with device persistence in guest mode
  - euyyn 9y ago
    Searching by label shows only another instance of a bug that got paid that amount: https://bugs.chromium.org/p/chromium/issues/detail?id=648971&can=1&q=label%3Areward-100000&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified https://bugs.chromium.org/p/chromium/issues/detail?id=648971... It was actually reported by the same guy!
    - esturk 9y ago
      I wonder if s/he save a bunch of bugs to chain together a single big exploit. From the latest report, there was 6 bugs chained together. Imagine reporting 6 small bugs individually that nets you 6 x 1000$ = 6k$. But if you save each one, it may chain together for a potential 100k$ bounty. Of course, any insight that reveals these underlying relations is most certainly worth 100k$.
      - lomnakkus 9y ago
        AFAIUI (not a security researcher) that's actually how most of the most devastating security exploits work. There are obvious exceptions like HEARTBLEED, but in general escalation through multiple levels seems to be the name of the game.
        rodjun 9y ago
        Or you can just get root from javascript, which that guy also did
      - jwilk 9y ago
        If they care about security, they shouldn't pay more for chaining, because that gives security researchers incentive to hoard vulnerabilities, rather than report them ASAP.
    - allenz 9y ago
      There is another persistent exploit, by GeoHot, that earned $150,000: https://bugs.chromium.org/p/chromium/issues/detail?id=351788 https://bugs.chromium.org/p/chromium/issues/detail?id=351788
- delroth 9y ago
  Yes: https://bugs.chromium.org/p/chromium/issues/detail?id=766253#c35 https://bugs.chromium.org/p/chromium/issues/detail?id=766253...
  - jshap70 9y ago
    > i hope it's delivered via absurdly large check :D this would be awesome
kevingadd 9y ago
It's kind of depressing to see that a considerable portion of this depends on design decisions that probably seemed safe at the time but are wildly dangerous in hindsight. Getting access to the privileged 'crosh' extension in this exploit depends on getting code into its process, which depends on the odd choice to put unrelated extensions into a shared extension process when there's too many processes. Given the insecure nature of the Chrome App Store, this was questionable to begin with - should a potentially backdoored bookmarking extension really share a process with my password safe? - but once privileged Chrome OS code started running in extension processes this immediately became a huge security hole waiting to be exploited. In this case they also don't even need a compromised extension, because they can (if I understand this right) impersonate an extension's frame and then send messages of their choice to the extension. The access control here is almost entirely done inside the content process, where potentially compromised content is running. It's hard to avoid this since most extension code runs inside content processes by design, but it's a weakness that is rarely (if ever) called out in the chrome extension documentation. The webassembly exploit part of the chain bums me out (I was always afraid of stuff like this when I was working on the design for it) but it's pretty uninteresting, really. The simple sort of bug you get when you insist on writing stuff in C++. The parts of the chain after getting access to crosh also seem like tough-to-avoid oversights. This set of attacks definitely make symlinks look like a problem child, given how useful they are for all sorts of naughty behavior the attack gets up to :)
- eugeneionesco 9y ago
  >The webassembly exploit part of the chain bums me out (I was always afraid of stuff like this when I was working on the design for it) but it's pretty uninteresting, really. The simple sort of bug you get when you insist on writing stuff in C++. I really hope people don't think webassembly is the fault for this, this vulnerability is no different from any other memory corruption vulnerability you would find in the js interpreter or the css parser or whatever.
  - standupstandup 9y ago
    Well, WebAssembly's primary near term contribution will be introducing the world of C++ exploits to web apps, which are already groaning under the load of XSS, XSRF, path traversal, SSRF etc attacks. Adding double frees, use after frees and buffer overflows on top doesn't seem ideal. As for the rest, well, it'd be nice if there was any sort of plan to make Blink safer. I know about oilpan but what Mozilla is doing with Rust is impressive. The JVM guys are working on rewriting the JVM in Java. What's Blink's plan to make its own code safer? Sandboxing alone?
megamindbrian2 9y ago
That didn't take long.
free2chill 9y ago
How do people discover this stuff? I am always so amazed.
- guessmyname 9y ago
  - Fuzzers are (most of the time) a great bug finder, - Random bugs that someone reported leading to something bigger, - You already know the software well enough to dive inside, - Luck ¯\_(ツ)_/¯
  - Jyaif 9y ago
    Finding 6 vulnerabilities you can chain is about very hard work, not luck.
    - guessmyname 9y ago
      I am referring to "luck" on finding the "initial" bug, obviously the rest is hard work.
      - rodjun 9y ago
        Why would one be luck and all the others skill?
  - arielb1 9y ago
    From the outside, it feels that most exploit chains on modern systems rely on 4 mostly-independent steps: 1. code execution in a worker process - typically a memory corruption 2. ACE in worker process to ACE in unsandboxed process 3. code execution in unsandboxed process to local root 4. local root to persistence Finding (1) (3) and (4) is old-school exploit development - a combination of looking at fuzzers, looking at code, looking at bug reports, and memory exploit development (which is a black art I'm not familiar with). So persistence and luck. Be lucky 3 times and you have 3 steps. If you were an organization I suppose you could have 3 separate groups or buy from 3 separate blackhats. I'm less familiar with the "worker process to user process" part, which tends to rely on combining a few vulnerabilities (in this exploit, 2 + 1 broken hardening), but it's probably similar.
zerebubuth 9y ago
Wow! That's really impressive. Seems like a _lot_ of work and ingenuity went into this. It's great that large, corporate projects like Chrome OS are attracting the sustained attention necessary to find bugs such as this one. But I worry that projects without such deep pockets are crowded out, leaving bugs unreported. Are many people doing security audits of open source projects without bug bounties?
- delroth 9y ago
  Google has been doing something close to bug bounties for many "critical" open source projects. Instead of focusing on bugs however, the Patch Rewards focuses on countermeasures: integrating a project into OSSFuzz, adding sandboxing, etc. https://www.google.com/about/appsecurity/patch-rewards/ https://www.google.com/about/appsecurity/patch-rewards/
- woodrowbarlow 9y ago
  one avenue for many smaller projects (especially open source libraries) is to become a dependency of a huge project like chrome. then the larger project redirects some of their auditing efforts toward your project.
jacksmith21006 9y ago
This is a text book example on why ChromeOS makes sense. Here this bug was found, fixed and because of the evergreen model deployed to actual people's machines and the users never even knew anything about it.
- woodrowbarlow 9y ago
  all modern operating systems are evergreen. how is ChromeOS unique in regard to bugfixes?
  - blacksmith_tb 9y ago
    My memory is that ChromeOS defaults to aggressively auto-updating itself, where macOS and Windows both remind / pester / offer to defer. So greener than evergreen?
    - kevingadd 9y ago
      With how often serious bugs ship to Chrome release channel, I don't think evergreen is implicitly a good thing in the OS that drives my computer, especially if it's my work PC. If you look through the chromium issue tracker you can also find multiple bug reports where people were struggling to get their chromebooks to update to the latest release, because auto-update had broken. Some of those people were Google employees.
      - jacksmith21006 9y ago
        Been involved with many Chromebooks and never had a single issue with any updating. It just happens completely transparently. Chromebooks have two boot partitions. So one updates while you are using the other. You then just pick up the update all ready to go next time you boot. You have zero idea that your laptop even updated.
    - nikanj 9y ago
      Windows today installs updates automatically and reboots when it's the least convenient. For a normal user, it's near-impossible to make it stop, and most people just grudgingly accept the lost work and ruined movie nights. You can google for a solution, but that solution only works on last year's version, the professional edition, or similar.
danjoc 9y ago
>reward-100000

222 points by chx 9y ago

Izmaki 9y ago

It’s great to see the bug program in effect. Also a huge thank you to all the whitehats our there!

eugeneionesco 9y ago

Beautiful chain of exploits, well done.

mbertschler 9y ago

Does reward 100000 mean 100k$ in bounty?

Ajedi32 9y ago
Yes. https://www.google.com/about/appsecurity/chrome-rewards/ https://www.google.com/about/appsecurity/chrome-rewards/ > We have a standing $100,000 reward for participants that can compromise a Chromebook or Chromebox with device persistence in guest mode
- euyyn 9y ago
  Searching by label shows only another instance of a bug that got paid that amount: https://bugs.chromium.org/p/chromium/issues/detail?id=648971&can=1&q=label%3Areward-100000&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified https://bugs.chromium.org/p/chromium/issues/detail?id=648971... It was actually reported by the same guy!
  - esturk 9y ago
    I wonder if s/he save a bunch of bugs to chain together a single big exploit. From the latest report, there was 6 bugs chained together. Imagine reporting 6 small bugs individually that nets you 6 x 1000$ = 6k$. But if you save each one, it may chain together for a potential 100k$ bounty. Of course, any insight that reveals these underlying relations is most certainly worth 100k$.
    - lomnakkus 9y ago
      AFAIUI (not a security researcher) that's actually how most of the most devastating security exploits work. There are obvious exceptions like HEARTBLEED, but in general escalation through multiple levels seems to be the name of the game.
      - rodjun 9y ago
        Or you can just get root from javascript, which that guy also did
    - jwilk 9y ago
      If they care about security, they shouldn't pay more for chaining, because that gives security researchers incentive to hoard vulnerabilities, rather than report them ASAP.
  - allenz 9y ago
    There is another persistent exploit, by GeoHot, that earned $150,000: https://bugs.chromium.org/p/chromium/issues/detail?id=351788 https://bugs.chromium.org/p/chromium/issues/detail?id=351788
delroth 9y ago
Yes: https://bugs.chromium.org/p/chromium/issues/detail?id=766253#c35 https://bugs.chromium.org/p/chromium/issues/detail?id=766253...
- jshap70 9y ago
  > i hope it's delivered via absurdly large check :D this would be awesome

kevingadd 9y ago

It's kind of depressing to see that a considerable portion of this depends on design decisions that probably seemed safe at the time but are wildly dangerous in hindsight. Getting access to the privileged 'crosh' extension in this exploit depends on getting code into its process, which depends on the odd choice to put unrelated extensions into a shared extension process when there's too many processes. Given the insecure nature of the Chrome App Store, this was questionable to begin with - should a potentially backdoored bookmarking extension really share a process with my password safe? - but once privileged Chrome OS code started running in extension processes this immediately became a huge security hole waiting to be exploited. In this case they also don't even need a compromised extension, because they can (if I understand this right) impersonate an extension's frame and then send messages of their choice to the extension. The access control here is almost entirely done inside the content process, where potentially compromised content is running. It's hard to avoid this since most extension code runs inside content processes by design, but it's a weakness that is rarely (if ever) called out in the chrome extension documentation. The webassembly exploit part of the chain bums me out (I was always afraid of stuff like this when I was working on the design for it) but it's pretty uninteresting, really. The simple sort of bug you get when you insist on writing stuff in C++. The parts of the chain after getting access to crosh also seem like tough-to-avoid oversights. This set of attacks definitely make symlinks look like a problem child, given how useful they are for all sorts of naughty behavior the attack gets up to :)

eugeneionesco 9y ago
>The webassembly exploit part of the chain bums me out (I was always afraid of stuff like this when I was working on the design for it) but it's pretty uninteresting, really. The simple sort of bug you get when you insist on writing stuff in C++. I really hope people don't think webassembly is the fault for this, this vulnerability is no different from any other memory corruption vulnerability you would find in the js interpreter or the css parser or whatever.
- standupstandup 9y ago
  Well, WebAssembly's primary near term contribution will be introducing the world of C++ exploits to web apps, which are already groaning under the load of XSS, XSRF, path traversal, SSRF etc attacks. Adding double frees, use after frees and buffer overflows on top doesn't seem ideal. As for the rest, well, it'd be nice if there was any sort of plan to make Blink safer. I know about oilpan but what Mozilla is doing with Rust is impressive. The JVM guys are working on rewriting the JVM in Java. What's Blink's plan to make its own code safer? Sandboxing alone?

megamindbrian2 9y ago

That didn't take long.

free2chill 9y ago

How do people discover this stuff? I am always so amazed.

guessmyname 9y ago
- Fuzzers are (most of the time) a great bug finder, - Random bugs that someone reported leading to something bigger, - You already know the software well enough to dive inside, - Luck ¯\_(ツ)_/¯
- Jyaif 9y ago
  Finding 6 vulnerabilities you can chain is about very hard work, not luck.
  - guessmyname 9y ago
    I am referring to "luck" on finding the "initial" bug, obviously the rest is hard work.
    - rodjun 9y ago
      Why would one be luck and all the others skill?
- arielb1 9y ago
  From the outside, it feels that most exploit chains on modern systems rely on 4 mostly-independent steps: 1. code execution in a worker process - typically a memory corruption 2. ACE in worker process to ACE in unsandboxed process 3. code execution in unsandboxed process to local root 4. local root to persistence Finding (1) (3) and (4) is old-school exploit development - a combination of looking at fuzzers, looking at code, looking at bug reports, and memory exploit development (which is a black art I'm not familiar with). So persistence and luck. Be lucky 3 times and you have 3 steps. If you were an organization I suppose you could have 3 separate groups or buy from 3 separate blackhats. I'm less familiar with the "worker process to user process" part, which tends to rely on combining a few vulnerabilities (in this exploit, 2 + 1 broken hardening), but it's probably similar.

zerebubuth 9y ago

Wow! That's really impressive. Seems like a _lot_ of work and ingenuity went into this. It's great that large, corporate projects like Chrome OS are attracting the sustained attention necessary to find bugs such as this one. But I worry that projects without such deep pockets are crowded out, leaving bugs unreported. Are many people doing security audits of open source projects without bug bounties?

delroth 9y ago
Google has been doing something close to bug bounties for many "critical" open source projects. Instead of focusing on bugs however, the Patch Rewards focuses on countermeasures: integrating a project into OSSFuzz, adding sandboxing, etc. https://www.google.com/about/appsecurity/patch-rewards/ https://www.google.com/about/appsecurity/patch-rewards/
woodrowbarlow 9y ago
one avenue for many smaller projects (especially open source libraries) is to become a dependency of a huge project like chrome. then the larger project redirects some of their auditing efforts toward your project.

jacksmith21006 9y ago

This is a text book example on why ChromeOS makes sense. Here this bug was found, fixed and because of the evergreen model deployed to actual people's machines and the users never even knew anything about it.

woodrowbarlow 9y ago
all modern operating systems are evergreen. how is ChromeOS unique in regard to bugfixes?
- blacksmith_tb 9y ago
  My memory is that ChromeOS defaults to aggressively auto-updating itself, where macOS and Windows both remind / pester / offer to defer. So greener than evergreen?
  - kevingadd 9y ago
    With how often serious bugs ship to Chrome release channel, I don't think evergreen is implicitly a good thing in the OS that drives my computer, especially if it's my work PC. If you look through the chromium issue tracker you can also find multiple bug reports where people were struggling to get their chromebooks to update to the latest release, because auto-update had broken. Some of those people were Google employees.
    - jacksmith21006 9y ago
      Been involved with many Chromebooks and never had a single issue with any updating. It just happens completely transparently. Chromebooks have two boot partitions. So one updates while you are using the other. You then just pick up the update all ready to go next time you boot. You have zero idea that your laptop even updated.
  - nikanj 9y ago
    Windows today installs updates automatically and reboots when it's the least convenient. For a normal user, it's near-impossible to make it stop, and most people just grudgingly accept the lost work and ruined movie nights. You can google for a solution, but that solution only works on last year's version, the professional edition, or similar.

danjoc 9y ago

>reward-100000