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.
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]
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.
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.
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.
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.
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...
> 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. ;)
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.
Direct2D, DirectWrite, et al. are all technologies introduced with NT6, aka Windows Vista and 7.
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.
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.
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.
See https://issues.chromium.org/issues/40597670, it was only ever AAT fonts that invoked coretext and that too since 2019 it's handled natively. Webfonts never allowed AAT in the first place (https://issues.chromium.org/issues/41475337).
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.