5 ms·

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 h

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.

redder23 3y ago
[flagged]
- gruez 3y ago
  >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?
- hnlmorg 3y ago
  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.
- Wowfunhappy 3y ago
  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.
  - jdiff 3y ago
    > 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 a security measure.
    - Wowfunhappy 3y ago
      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.
- disruptiveink 3y ago
  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.
  - saagarjha 3y ago
    Running XP in a VM is really a very different threat model from “I run XP”

redder23 3y ago

[flagged]

gruez 3y ago
>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?
hnlmorg 3y ago
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.
Wowfunhappy 3y ago
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.
- jdiff 3y ago
  > 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 a security measure.
  - Wowfunhappy 3y ago
    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.
disruptiveink 3y ago
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.
- saagarjha 3y ago
  Running XP in a VM is really a very different threat model from “I run XP”