3 ms·

It does leave the sandbox. How else are you going to get hardware acceleration? That means talking to the hardware, which means talking to the OS, which is outs

by jdiff 3y ago

It does leave the sandbox. How else are you going to get hardware acceleration? That means talking to the hardware, which means talking to the OS, which is outside of the sandbox. I already said scrollbars weren't a practical example, just an example of how benign APIs can be exploited. I heavily disagree about the threat model. It costs next to nothing to cast the net out for users neglecting their computer (and there are very many), and the payout is a hefty botnet.

hnlmorg 3y ago
> It does leave the sandbox. How else are you going to get hardware acceleration? Depends on what you're hardware accelerating and how you want to "accelerate" it. In the case of video decoding, ffmpeg would talk directly to the hardware. There wouldn't be an "OS" component to that (if there were, then ffmpeg wouldn't exist in the first place). The rendering part of video playback would be owned by the browser. So whatever graphics libraries Supermium uses. There is already a conversation about GDI elsewhere in this conversation. At least with the rendering part, the browser owns the API interaction. Which does reduce the attack surface significantly. Though that's not to say that there isn't the possibility of someone carefully crafting a zero day that exploits the latest builds of ffmpeg to purposely to attack an unpatched bug in an older rendering library. However this comes back to my earlier point that such an attack would be highly specific to this exact browser fork running on a specific version of Windows. ie you're now talking about nation state actor level of targetted attack. If that's your threat model, then you definitely shouldn't run this. But I doubt that's a concern for most people > I already said scrollbars weren't a practical example, just an example of how benign APIs can be exploited. I don't think anyone is confused about the fact that APIs can be exploited :) > I heavily disagree about the threat model. It costs next to nothing to cast the net out for users neglecting their computer (and there are very many), and the payout is a hefty botnet. Actually it costs a great deal of time and effort to craft an exploit that would target a zero day on a modern browser even if the underlying OS API vulnerability is already known. And how many people would be vulnerable? It's not worth the effort for the tens of people vulnerable. That is unless you're intentionally targetting one specific individual with this known configuration....and now we're back to my point about your threat model.
- jdiff 3y ago
  > Depends on what you're hardware accelerating and how you want to "accelerate" it. In the case of video decoding, ffmpeg would talk directly to the hardware. There wouldn't be an "OS" component to that (if there were, then ffmpeg wouldn't exist in the first place). FFmpeg does not talk directly to hardware. That's the job of the OS and the drivers. They exist outside of the sandbox. So does the hardware itself. > Actually it costs a great deal of time and effort to craft an exploit that would target a zero day on a modern browser even if the underlying OS API vulnerability is already known. And how many people would be vulnerable? It's not worth the effort for the tens of people vulnerable. That is unless you're intentionally targetting one specific individual with this known configuration....and now we're back to my point about your threat model. You missed a step. More like two, actually. First, it costs almost nothing to include exploits for known out-of-date OSes (and browsers, but that's separate to this particular point). Second, if a modern browser is exploited, it needs a payload to deal with the OS on the outside. It, again, costs almost nothing to see if there's any low hanging fruit on the outside. And plenty of modern vulnerabilities affect older OSes, so you may just get it for actually free instead of nearly free. Nobody who cares about their threat model is running an out-of-date OS. And yet, out-of-date OSes are vacuumed up in mass amounts for botnets. They're worth going after, even if the people running those machines don't even know what "threat model" means. They have an internet connection? That's plenty to make it worth the minimal effort.
  - hnlmorg 3y ago
    > FFmpeg does not talk directly to hardware. That's the job of the OS and the drivers. They exist outside of the sandbox. So does the hardware itself. It depends how you run (and build ffmpeg). ffmpeg supports a plethora of different hardware and software configurations. I don't know how Chromium runs ffmpeg -- likely different on each platform -- but Supermium could easily fallback to software decoding. > You missed a step. More like two, actually. First, it costs almost nothing to include exploits for known out-of-date OSes I haven't missed anything. We aren't talking about software that directly interfaces with the OS. We are talking about software that needs to escape the browser sandbox first. It's all good and well saying "it costs nothing to include exploits for known out-of-date OSes" but how do you execute that payload? That's the hard part. > Second, if a modern browser is exploited, it needs a payload to deal with the OS on the outside. It, again, costs almost nothing to see if there's any low hanging fruit on the outside. And plenty of modern vulnerabilities affect older OSes, so you may just get it for actually free instead of nearly free > Nobody who cares about their threat model is running an out-of-date OS. Exactly!! This browser is only going to be used on systems that aren't important. So the risk isn't as serious. > And yet, out-of-date OSes are vacuumed up in mass amounts for botnets. Indeed. And having an up-to-date browser will help those 0.29% of people still running XP: https://www.statista.com/statistics/993868/worldwide-windows-operating-system-market-share/ https://www.statista.com/statistics/993868/worldwide-windows... > They have an internet connection? That's plenty to make it worth the minimal effort. Assuming including any payload for XP doesn't prevent the attacker for also bundling a payload for Win10. ;)

by jdiff 3y ago

hnlmorg 3y ago

> It does leave the sandbox. How else are you going to get hardware acceleration? Depends on what you're hardware accelerating and how you want to "accelerate" it. In the case of video decoding, ffmpeg would talk directly to the hardware. There wouldn't be an "OS" component to that (if there were, then ffmpeg wouldn't exist in the first place). The rendering part of video playback would be owned by the browser. So whatever graphics libraries Supermium uses. There is already a conversation about GDI elsewhere in this conversation. At least with the rendering part, the browser owns the API interaction. Which does reduce the attack surface significantly. Though that's not to say that there isn't the possibility of someone carefully crafting a zero day that exploits the latest builds of ffmpeg to purposely to attack an unpatched bug in an older rendering library. However this comes back to my earlier point that such an attack would be highly specific to this exact browser fork running on a specific version of Windows. ie you're now talking about nation state actor level of targetted attack. If that's your threat model, then you definitely shouldn't run this. But I doubt that's a concern for most people > I already said scrollbars weren't a practical example, just an example of how benign APIs can be exploited. I don't think anyone is confused about the fact that APIs can be exploited :) > I heavily disagree about the threat model. It costs next to nothing to cast the net out for users neglecting their computer (and there are very many), and the payout is a hefty botnet. Actually it costs a great deal of time and effort to craft an exploit that would target a zero day on a modern browser even if the underlying OS API vulnerability is already known. And how many people would be vulnerable? It's not worth the effort for the tens of people vulnerable. That is unless you're intentionally targetting one specific individual with this known configuration....and now we're back to my point about your threat model.

jdiff 3y ago
> Depends on what you're hardware accelerating and how you want to "accelerate" it. In the case of video decoding, ffmpeg would talk directly to the hardware. There wouldn't be an "OS" component to that (if there were, then ffmpeg wouldn't exist in the first place). FFmpeg does not talk directly to hardware. That's the job of the OS and the drivers. They exist outside of the sandbox. So does the hardware itself. > Actually it costs a great deal of time and effort to craft an exploit that would target a zero day on a modern browser even if the underlying OS API vulnerability is already known. And how many people would be vulnerable? It's not worth the effort for the tens of people vulnerable. That is unless you're intentionally targetting one specific individual with this known configuration....and now we're back to my point about your threat model. You missed a step. More like two, actually. First, it costs almost nothing to include exploits for known out-of-date OSes (and browsers, but that's separate to this particular point). Second, if a modern browser is exploited, it needs a payload to deal with the OS on the outside. It, again, costs almost nothing to see if there's any low hanging fruit on the outside. And plenty of modern vulnerabilities affect older OSes, so you may just get it for actually free instead of nearly free. Nobody who cares about their threat model is running an out-of-date OS. And yet, out-of-date OSes are vacuumed up in mass amounts for botnets. They're worth going after, even if the people running those machines don't even know what "threat model" means. They have an internet connection? That's plenty to make it worth the minimal effort.
- hnlmorg 3y ago
  > FFmpeg does not talk directly to hardware. That's the job of the OS and the drivers. They exist outside of the sandbox. So does the hardware itself. It depends how you run (and build ffmpeg). ffmpeg supports a plethora of different hardware and software configurations. I don't know how Chromium runs ffmpeg -- likely different on each platform -- but Supermium could easily fallback to software decoding. > You missed a step. More like two, actually. First, it costs almost nothing to include exploits for known out-of-date OSes I haven't missed anything. We aren't talking about software that directly interfaces with the OS. We are talking about software that needs to escape the browser sandbox first. It's all good and well saying "it costs nothing to include exploits for known out-of-date OSes" but how do you execute that payload? That's the hard part. > Second, if a modern browser is exploited, it needs a payload to deal with the OS on the outside. It, again, costs almost nothing to see if there's any low hanging fruit on the outside. And plenty of modern vulnerabilities affect older OSes, so you may just get it for actually free instead of nearly free > Nobody who cares about their threat model is running an out-of-date OS. Exactly!! This browser is only going to be used on systems that aren't important. So the risk isn't as serious. > And yet, out-of-date OSes are vacuumed up in mass amounts for botnets. Indeed. And having an up-to-date browser will help those 0.29% of people still running XP: https://www.statista.com/statistics/993868/worldwide-windows-operating-system-market-share/ https://www.statista.com/statistics/993868/worldwide-windows... > They have an internet connection? That's plenty to make it worth the minimal effort. Assuming including any payload for XP doesn't prevent the attacker for also bundling a payload for Win10. ;)