My understanding is that Chromium renders fonts and other graphics primitives via Skia. Video and audio uses ffmpeg. And all of these libraries are statically linked.
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]
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.
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.
> 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.
> 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.
> 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.
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.
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.
Doesn't chrome use harfbuzz for the glyph shaping, which ends up calling into coretext? It may use skia for the drawing, but (at least in the past) text rendering (in the sense of font parsing and gyph shaping) is then ultimately still done by coretext. So it seems like it would still be vulnerable to CoreText exploits, of which there was a notable recent 0-day. This is why I think it is prudent to disable remote fonts (PDFs are still an issue, but you can at choose to not auto-render them).
Edit: This may not be the case, seems like CoreText was only invoked by Harfbuzz for some specific fonts, and newer versions of Harfbuzz can handle those too.
Hi! Note that this thread is about Windows, which definitely doesn't use Coretext. ;)
If anyone actually has an XP machine handy, I really am curious whether colored emojis work in Supermium. If they do, I would assume Chromium (or at least Supermium) isn't using the OS font renderer.
And I'd honestly be pretty surprised if emojis didn't work. Passing web fonts off to be handled by the OS (in anything above the most trivial way) just doesn't seem to fit how Chromium does things, for the security reasons we are discussing if nothing else.
