Well, I think if you're running win 2003/XP and actually dare to go into the internet with the machine, you openly and proudly do not give a flying fuck about any security. The amount of open holes is insane, and some Chromium project that some dude ported is not going to save you.
Most people these days sit behind a firewall on their router. This wasn't nearly as common in 2003. So the only way the OS is exposed is via the browser.
I'd hope (expect even) this port to include it's own libraries for things like TLS, JPEG, PNG, PDF, etc. Which I'm pretty sure Chromium does anyway. But type-faces might still be an issue. TTF is Turing complete and I wouldn't be surprised if that was handed by the OS. So there might be an issue there.
>But assuming the Browser is secure, the browser communicates to the internet "hey here is an IP" that fact alone is a security risk as the attack may come directly to the OS not the browser. Heck, this Browser may even send a user agent that actually says it's some old windows that is no longer supported, lol.
Can you sketch how you're going to hack a windows XP SP3 that's behind a NAT firewall?
I use a XP VM on a ARM Mac as it's a handy way to run most Win16/32 exes that won't run properly in Wine. Old random utilities, random OEM software required to upgrade old devices' firmware, silly Win16 apps, the works. Anything more recent than XPis too heavy for x86 VM emulation on ARM and Win 10/11 ARM come with their own quirks that are not worth dealing with for my purposes.
It's handy to have a modern browser at hand to not have to shuffle files around between the host and the VM, so you can do Google -> website of the tool in question (plus uBlock, so the main source of infection, ad networks, is taken care of). The likelihood of either Google or whatever very focused and targeted website I happen to visit to be serving XP malware is negligible.
And if it does get infected, congrats, you infected a VM with no connection to the host or shared folders that has no personal files and is powered up maybe 30 minutes per year.
It's not zero, no, but to say there's no use case and it's the same as running around in scissors blindfolded is a huge simplification.
Take a moment to think about this please. I get this is a topic you're passionate about but you're making a number of false assumptions.
> NOPE, some "firewall" in a consumer router does not suddenly make a 20+ year old OS secure.
That wasn't the claim. The claim was it eliminates a chunk of risk (ie someone connecting to you from outside). So the risk is now "just" code you import and run.
> The OS accesses the internet, not the browser
Which part of the "OS" are you concerned about? Please be specific.
> It's funny how you just mention some 20-year-old technique that even grandma knows about.
I don't recall seeing you comment on any techniques. If you're so much wiser than the rest of us, then please do share these techniques that we've all missed.
> But assuming the Browser is secure, the browser communicates to the internet "hey here is an IP" that fact alone is a security risk as the attack may come directly to the OS not the browser.
How does it? A buffer overflow in the TCP/IP stack? Maybe. Have you got an CVEs to back that claim up?
Maybe DNS? But the Browser can easily bypass the hosts DNS resolver so this is a solvable problem.
Beyond that, the browser manages the rest.
> Heck, this Browser may even send a user agent that actually says it's some old windows that is no longer supported, lol.
User agent string is trivial to change. It's literally just a HTTP header and there are numerous browser plugins that support doing just this.
---
As I commented in another reply, we need to be clear about attack surface and threat model.
In the case of the former, most (nobody said "all") of the security concerns are sandboxed by the browser.
In the case of the latter, if your threat model includes targetted attacks then this browser on an older OS would clearly be the wrong choice. But for most people this would appeal to, that isn't a risk worth accounting for. ie this is safe enough for anything not important.
Let's say I was running VirtualBox† on top of a bare-metal Windows XP host. Inside of Virtualbox is a modern Linux distro with Chromium installed, which I'm using to browse the web. Would you still consider this a major security risk?
If so, fair, I'd like to hear more about why you would be concerned! But if not, how is this situation inherently different from running Chromium, which has a strong sandbox and statically links basically everything? I realize that in the virtualization case, Chromium is running on a separate kernel, but does that really make a difference in practice?
---
† I can't figure out from a quick Google search exactly when Virtualbox dropped support for Windows XP hosts, but it appears to have have happened relatively recently. It probably wouldn't be too hard to build the latest version from source with some patches for XP compatibility.
Yes, it does. To be fair I wouldn’t really trust some old version of VirtualBox that runs on XP (it probably has bugs of its own) but it’s way better than sharing a kernel that is known to be full of bugs.
VirtualBox on XP would still be sharing the XP kernel.
If you're concerned about bugs and age of code then Supermium would actually be better than VirtualBox:
1. VirtualBox doesn't support XP hosts, so you'd have to use an older version.
2. Whereas Supermium is current Chromium. So you will get the latest patches.
3. Chromium also has more maintainers than VirtualBox. Google and Microsoft invest far more resources into Chromium than Oracle does into VirtualBox. And that's without factoring in all the other contributors outside of G&M. VirtualBox just isn't nearly as cool. The fact that there still isn't a stable VBox release for Apple Silicon speaks volumes for just how stark the contrast is with regards to developer resources.
What virtualisation extensions in XP? There’s extensions on the intel and AMD COUs. And Windows Server has a product called hyper-v. But there’s nothing provided by Microsoft to support XP being a virt host.
VirtualBox manages that itself.
Plus, like with Chrome, VBox still needs to write to the display, and hook into the hosts TCP/IP stack. And like with Chrome, a zero day in the hypervisor could allow sandboxed code to escape the confines of the virtual machine.
> But if not, how is this situation inherently different from running Chromium, which has a strong sandbox and statically links basically everything? I realize that in the virtualization case, Chromium is running on a separate kernel, but does that really make a difference in practice?
This is just not how static linking works. You're not suddenly running on a modern, secure OS because all your web browser dependencies are up to date. And your up-to-date, statically-linked browser is still interacting with your OS, not just the kernel but the OS and userland and everything.
Static linking is not typically a security measure because you would assume the host system's libraries are equally if not more up to date.
In the case of modern software designed for Windows XP, I absolutely consider static linking to be a very significant security measure, because every statically linked library decreases the amount of vulnerable userland code in use. For example, Chromium literally doesn't use the Windows SSL stack—it brings its own—so any and all SSL vulnerabilities on the Windows side are irrelevant.
On Linux, you could decide to statically link everything and create a binary which literally doesn't touch userland—but I don't know if it's possible to go this far on Windows. Regardless, it's true that at some point Chromium will need to tell the OS to e.g. blit pixels on the screen—as does VMWare, which was the point of that comparison—and you could attack the OS via the pixel blitting function. However, this would be considered a Chromium zero day.
A zero-day which is non-exploitable in Windows 11 might be exploitable in Windows XP—this is what you loose by forgoing defense in depth—but it would be fixed in due time regardless.
The browser is a bloated beast that incorporates and reimplements so much of the OS. But not that much. The OS still interacts with the OS far too much for static linking to make much of a difference. And even if there is a modern Chromium 0day, like the Skia exploit I mentioned, sure, that's a Chrome bug. That's still a bigger problem for older OSes that have absolutely no protection once something escapes the sandbox.
> The browser is a bloated beast that incorporates and reimplements so much of the OS. But not that much. The OS still interacts with the OS far too much for static linking to make much of a difference.
The thing is, we don't actually care about the whole OS, we care about the bits that interact with untrusted remote data, i.e. web content. I really don't think there are many opportunities for Chromium web content to interact with the host OS. Everything goes through Chromium's renderer. If web content is able to affect things on the other side of that renderer, that's a zero day!
> And even if there is a modern Chromium 0day, like the Skia exploit I mentioned, sure, that's a Chrome bug. That's still a bigger problem for older OSes that have absolutely no protection once something escapes the sandbox.
We agree on this point! A zero day is vastly more dangerous to a Windows XP user than a Windows 10 user. This is the benefit of defense in depth, which you loose by blatantly removing a major layer of defense.
However, for regular consumers, I still believe the risk of being hit with a zero day is vanishingly small. A person who daily drives Windows XP but browses the web in Supermium, installs new versions of Supermium within 24 hours of release, keeps his or her passwords in Bitwarden behind a strong master password, and uses a good home router with updated firmware is less vulnerable to cyber threats than the vast majority of the population!
Zero days aren't used to create botnets, they're used to launch targeted attacks on high-stakes targets. No one uses them in automated attacks because (A) people would see the attack and patch the vulnerability and (B) it's so much easier to take over insecure wifi routers.
Please do share if you think there is a specific attack surface I am overlooking. As I've said, this is directly relevant to me as a user of OS X 10.9, which hasn't been updated by Apple since 2015. If I am currently exposed in a way that leaves me vulnerable to an automated attack (!), I need to either patch the OS myself—I have done this before—or, if I absolutely must, take more drastic measures such as moving all of my web browsing inside VMWare Fusion or migrating off of my favorite platform.
Ok recent example we had a bunch of 0 days targeting Android where attackers sidestepped basically all of Chrome’s security features because of bugs in Mail GPU drivers. A fully-patched Chrome can only assume that these were written correctly and dutifully calls into them as appropriate (from userspace, of course). If these legitimate calls end up triggering the bug then you have attack surface that is exposed to web content.
You can configure and even turn off external url handlers in Chromium.
But even if you didn’t, the attack becomes even more difficult and niche here because now you’re looking for a machine running a specific version of $email_client on a specific version of Windows. This is something that you can’t even use browser fingerprinting to detect.
Let me throw the same question to you that I had to redder23:
What part of the OS are you specifically concerned about?
"Operating system" is a pretty broad description and there isn't a whole lot of surface area between this specific sandbox and the OS-owned APIs.
Font rendering is one concern that has already been raised; and by those defending this browser too. But literally no-one who's opposed to this browser has named a single specific vulnerable API in this thread.
This is the problem we're having in this conversation. Claims are being made that this is insecure -- made in absolute terms. Yet zero attempts have been made to back up those claims. Just handwavey comments about "the OS is out-of-date".
> "Operating system" is a pretty broad description
That's the problem, and the concern.
I've given several concrete examples (both of actual exploitable surface area and more abstract kinds of exploitable surface areas) in this thread already, feel free to refer back to them.
A lot of what you're complaining about as handwavy is just common knowledge. Ask questions if you're interested, but out-of-date OSes are factually insecure in known-unfixable and unknown-unfixable ways.
But the point you keep missing is that browser do not interface with the entirety of the OS. Just because code exists, it doesn't mean the browser calls that code. For example notepad.exe was used as a UAC bypass in early versions of Vista. But there isn't any way a website running in Supermium can elevate itself to run as Administrator, let alone use notepad.exe to bypass the UAC, without exploiting a serious zero-day in Chromium. And if attackers have a zero-day that serious in Chromium, then they're not going to burn it on infecting the 10 people who run Supermium.
> I've given several concrete examples (both of actual exploitable surface area and more abstract kinds of exploitable surface areas) in this thread already, feel free to refer back to them.
You've given one and even that was impossibly vague.
> A lot of what you're complaining about as handwavy is just common knowledge.
Nobody is disputing that you should keep your OS fully patched. But what's being said here is that the age of the system ironically actually works in its benefit: it's now a small enough market share that it isn't worth burning a Chromium zero day on.
That all said, advise of not running XP / Vista for work is wise. And not connecting them to untrusted networks is wise too. Nobody is disputing that either. What is being said is that having an XP / Vista machine at home (likely for retro gaming or other niche use case) isn't automatically catastrophic.
Things don't have to be boolean :)
> Ask questions if you're interested, but out-of-date OSes are factually insecure in known-unfixable and unknown-unfixable ways.
I have quite a lot of experience hacking Windows and even wrote my own hobby browser a while back. I'm pretty well versed on the topic. The one question I asked is examples of how you would exploit "the OS" from the browser.
With all possible respect, I don't think you have given concrete examples. You have given general examples, and hnlmorg and I have explained why we don't think there are concrete problems to be found there.
The exception is font rendering. I haven't used Supermium specifically and I don't know enough about how it works, but if Supermium is passing remote web fonts directly to the OS for rendering, that needs to stop immediately, and until it does all Supermium users should disable webfonts!
As an aside, if there is in fact something like an exploitable buffer overflow in Windows XP's TCP/IP stack, that is something enthusiasts could probably patch.
If the browser is properly sandboxed, and you're only accessing the internet through the browser, you should reasonably safe, no? Obviously it's better to have defense in depth, but I don't see the immediate danger.
What is the attack vector you are concerned about?
---
I daily drive a 2013-era version of OS X, using a similar modified version of Chromium[1] to browse the web. I'm pretty sure I've plugged the holes I need to plug in order to be reasonably safe, but if you have a specific concern I'd like to hear about it!
No, just as an example, Windows has had multiple kernel exploits that only required crafted fonts to be loaded by the victim computer. Any interaction with the world outside of the sandbox leaves room for a foot in the door, and there's necessarily a lot. Images, video, audio, the multitude of device APIs, and like the font exploits show, even the most basic page rendering.
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.
Not that I recommend using such an old operating system or not getting current patches, what is the likely ways a hacker would own the user is they were otherwise using a host blocker combined with unlock origin and not running any other executables except chrome on their system?
Well, I think if you're running win 2003/XP and actually dare to go into the internet with the machine, you openly and proudly do not give a flying fuck about any security. The amount of open holes is insane, and some Chromium project that some dude ported is not going to save you.
Projects like this never made any sense to me.