5 ms·

Supermium in specific will let you render text with GDI (for performance, probably?), videos are played with FFMPEG but that still means hauling untrusted foota

by jdiff 3y ago

Supermium in specific will let you render text with GDI (for performance, probably?), videos are played with FFMPEG but that still means hauling untrusted footage outside of the sandbox for hardware decoding, and there's still countless other potentially-pierceable membranes in the sandbox. This (probably) isn't a practical vector for a browser, but kernel exploits have been crafted out of scrollbars in the past. Any time the sandbox calls out to the OS in any capacity it's trusting that the surface it's touching isn't vulnerable, and sometimes it is. For a sandbox to solve this, it's not good enough to just prevent people from misusing the APIs that exist on paper, you have to verify that the API itself isn't bugged and exploitable. And it's not just OS surface, either, Skia's just as penetrable as any other membrane in the sandbox.[0] [0] https://nvd.nist.gov/vuln/detail/CVE-2023-6345 https://nvd.nist.gov/vuln/detail/CVE-2023-6345

hnlmorg 3y ago
If ffmpeg is statically linked then code isn't leaving the sandbox. Browsers don't use the OS's scrollbars because browser scrollbars are themeable in ways that the system scrollbars are not. I do agree with you in principle but in practice, we aren't talking about a wide attack surface if you're using an older OS + modern browser vs a modern OS + modern browser. It's certainly drifting into the realm of a targetted attack. And if you're the kind of individual that is likely to be targetted in this kind of way, then you'd have a lot more secure defaults than just "modern OS + modern browser". So it all boils down to what your threat model is. If you're Satya Nadella then this would be stupid. But if you're just some random Joe Bloggs who plays a few retro games, then realistically this should be safe enough to load GOG.
- 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.
Wowfunhappy 3y ago
> but kernel exploits have been crafted out of scrollbars in the past. But that would be a Chromium CVE, wouldn't it? Zero days of course happen, but I think it's reasonable for a normal consumer to leave them out of their threat model.
- Dalewyn 3y ago
  Can't really not use GDI if you're on Windows XP, though. Direct2D, DirectWrite, et al. are all technologies introduced with NT6, aka Windows Vista and 7.
  - Wowfunhappy 3y ago
    Sorry, I think is misunderstood. I've edited GP to remove the note about GDI. Is Supermium passing webfonts directly to the Windows font renderer instead of going through Skia? A good test for this might be whether emojis render properly in Windows XP, which doesn't natively support colored fonts.
    - Dalewyn 3y ago
      I don't know how Chrome/Chromium/Supermium handle text rendering, I'm just commenting on how GDI is the only option for Windows XP and prior.
      - mkup 3y ago
        Does GDI/non-GDI distinction really matter if the only job for GDI is to blit already rendered framebuffer after Skia library (up-to-date part of browser) to the hardware? I.e. when GDI is actually not exposed to the fonts and vector graphics downloaded from the web, just pixels? To me it seems highly unlikely that GDI can be exploited via colors of pixels.
  - hnlmorg 3y ago
    DirectDraw existed in old versions of DirectX. After a while it was deprecated in favour of using Direct3D even for 2D planes. So you don't really need to fall back to GDI. Though I wouldn't say older versions of DirectX would be any more secure than GDI.

by jdiff 3y ago

hnlmorg 3y ago

If ffmpeg is statically linked then code isn't leaving the sandbox. Browsers don't use the OS's scrollbars because browser scrollbars are themeable in ways that the system scrollbars are not. I do agree with you in principle but in practice, we aren't talking about a wide attack surface if you're using an older OS + modern browser vs a modern OS + modern browser. It's certainly drifting into the realm of a targetted attack. And if you're the kind of individual that is likely to be targetted in this kind of way, then you'd have a lot more secure defaults than just "modern OS + modern browser". So it all boils down to what your threat model is. If you're Satya Nadella then this would be stupid. But if you're just some random Joe Bloggs who plays a few retro games, then realistically this should be safe enough to load GOG.

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.

Wowfunhappy 3y ago

> but kernel exploits have been crafted out of scrollbars in the past. But that would be a Chromium CVE, wouldn't it? Zero days of course happen, but I think it's reasonable for a normal consumer to leave them out of their threat model.

Dalewyn 3y ago
Can't really not use GDI if you're on Windows XP, though. Direct2D, DirectWrite, et al. are all technologies introduced with NT6, aka Windows Vista and 7.
- Wowfunhappy 3y ago
  Sorry, I think is misunderstood. I've edited GP to remove the note about GDI. Is Supermium passing webfonts directly to the Windows font renderer instead of going through Skia? A good test for this might be whether emojis render properly in Windows XP, which doesn't natively support colored fonts.
  - Dalewyn 3y ago
    I don't know how Chrome/Chromium/Supermium handle text rendering, I'm just commenting on how GDI is the only option for Windows XP and prior.
    - mkup 3y ago
      Does GDI/non-GDI distinction really matter if the only job for GDI is to blit already rendered framebuffer after Skia library (up-to-date part of browser) to the hardware? I.e. when GDI is actually not exposed to the fonts and vector graphics downloaded from the web, just pixels? To me it seems highly unlikely that GDI can be exploited via colors of pixels.
- hnlmorg 3y ago
  DirectDraw existed in old versions of DirectX. After a while it was deprecated in favour of using Direct3D even for 2D planes. So you don't really need to fall back to GDI. Though I wouldn't say older versions of DirectX would be any more secure than GDI.