11 ms·

In this case I think the point of running from RAM is that there isn't non-volatile storage. Of course, someone who has physically compromised the server could

by jchw 3y ago

In this case I think the point of running from RAM is that there isn't non-volatile storage. Of course, someone who has physically compromised the server could do potentially bad things, but this makes it harder to e.g. persistently compromise a server, since it doesn't have storage to store malware on persistently, or e.g. accidentally or intentionally log data, since there is no local storage to log it on. Encrypting what's in RAM would possibly add some additional protection but realistically if things are done right what's left in RAM will probably be only marginally more interesting than what you can see over the wire; at most I'd expect you could see a tiny amount of active request data. That's just a guess, though.

ignoramous 3y ago
> since it doesn't have storage to store malware on persistently, or e.g. accidentally or intentionally log data, since there is no local storage to log it on. Does this prevent rootkits? > but realistically if things are done right what's left in RAM will probably be only marginally more interesting See: https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack
- jchw 3y ago
  > Does this prevet rootkits? That's the idea. If the OS is immutable, where do you put them? Bootkits require further mitigation to prevent, but Mullvad has also put effort into that, too, with their secure coreboot bootchain. Of course as an end-user you still can't really fully validate a machine over the network has not been tampered with, so you're obviously ultimately still trusting Mullvad as you'd expect. > See: https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack Yes, that's what I'm referring to. I don't expect that there would be a significant amount of requests in RAM, probably just remnants of mainly what was active (and some de-allocated but not cleared remnants?) when the machine was reset.
  - LinuxBender 3y ago
    That's the idea. If the OS is immutable, where do you put them? They would be in the PXE image. There was one time I flubbed on this actually. I had to change export options on our PXE servers to fix something and I forgot to change it back adding my poor excuse of multitasking and being lazy. This was in a Dev environment we also used PXE in production believe it or not. A developer sitting across from me said he changed something in the image by mistake and I said, "That's not possi... oh crap." It was cool of them to call it out right away. Attackers probably won't be so kind.
    - jchw 3y ago
      For what it's worth though, that's possible to mitigate. I don't believe Mullvad uses PXE and they do have a "secure boot" validation chain, starting from Coreboot on the hardware. https://mullvad.net/en/blog/2022/1/12/diskless-infrastructure-beta-system-transparency-stboot https://mullvad.net/en/blog/2022/1/12/diskless-infrastructur...
      - ignoramous 3y ago
        It is an improvement, for sure. secure boot, as painful it is to get right, doesn't help when the vendor runs its own things with elevated privileges, like they are known to do: https://news.ycombinator.com/item?id=34085635 https://news.ycombinator.com/item?id=34085635 Doubly so, when the said things are not only closed source but vulnerable themselves: https://archive.is/6ClWm https://archive.is/6ClWm Does coreboot help in mitigating vuln in privilged vendor blobs?
        jchw 3y ago
        Well, with Coreboot, you at least know the very first instructions executed by the x86 cores are under your control. That's all it can really do. Whatever else lurks beneath is really impossible for anyone to scrutinize without insane capital or insider knowledge. Mitigating the risk of Intel ME is obviously something that is complicated. The "state of the art" so-to-speak is really just rendering it non-functional. This isn't strictly related to Coreboot; that said, Coreboot has a page about ME: https://www.coreboot.org/Intel_Management_Engine https://www.coreboot.org/Intel_Management_Engine And in general, when you're running Coreboot, you're running significantly less privileged blackbox blobs (possibly none in some rare cases), and in general, the surface area of Coreboot is going to be dramatically tinier than any typical UEFI system firmware. So it's absolutely worth it in that regard. There's never going to be a "perfect" option here with how complex things have gotten, but I think that you can at least say that Mullvad has taken almost any reasonable step, and perhaps a few steps that are beyond what many would consider reasonable, towards developing effective mitigation of the risks of rootkits, bootkits and malicious/unwanted vendor code running on their "diskless" architecture. Of course, you still have to trust Mullvad. Trust is definitely a meaty human-y experience, and the cold rational part of our brain craves some kind of technically-bulletproof way to prove that it's truly safe, secure, and private, but that's just not possible. Best you can do is layer enough assurances on top of each-other in a way that at least some layers are completely independent of others for maintaining your operational security. Far easier said than done, and obviously how rigorously one approaches this will vary on paranoia. At some point you have to pick your middle-ground I suppose.

by jchw 3y ago

ignoramous 3y ago

> since it doesn't have storage to store malware on persistently, or e.g. accidentally or intentionally log data, since there is no local storage to log it on. Does this prevent rootkits? > but realistically if things are done right what's left in RAM will probably be only marginally more interesting See: https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack

jchw 3y ago
> Does this prevet rootkits? That's the idea. If the OS is immutable, where do you put them? Bootkits require further mitigation to prevent, but Mullvad has also put effort into that, too, with their secure coreboot bootchain. Of course as an end-user you still can't really fully validate a machine over the network has not been tampered with, so you're obviously ultimately still trusting Mullvad as you'd expect. > See: https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack Yes, that's what I'm referring to. I don't expect that there would be a significant amount of requests in RAM, probably just remnants of mainly what was active (and some de-allocated but not cleared remnants?) when the machine was reset.
- LinuxBender 3y ago
  That's the idea. If the OS is immutable, where do you put them? They would be in the PXE image. There was one time I flubbed on this actually. I had to change export options on our PXE servers to fix something and I forgot to change it back adding my poor excuse of multitasking and being lazy. This was in a Dev environment we also used PXE in production believe it or not. A developer sitting across from me said he changed something in the image by mistake and I said, "That's not possi... oh crap." It was cool of them to call it out right away. Attackers probably won't be so kind.
  - jchw 3y ago
    For what it's worth though, that's possible to mitigate. I don't believe Mullvad uses PXE and they do have a "secure boot" validation chain, starting from Coreboot on the hardware. https://mullvad.net/en/blog/2022/1/12/diskless-infrastructure-beta-system-transparency-stboot https://mullvad.net/en/blog/2022/1/12/diskless-infrastructur...
    - ignoramous 3y ago
      It is an improvement, for sure. secure boot, as painful it is to get right, doesn't help when the vendor runs its own things with elevated privileges, like they are known to do: https://news.ycombinator.com/item?id=34085635 https://news.ycombinator.com/item?id=34085635 Doubly so, when the said things are not only closed source but vulnerable themselves: https://archive.is/6ClWm https://archive.is/6ClWm Does coreboot help in mitigating vuln in privilged vendor blobs?
      - jchw 3y ago
        Well, with Coreboot, you at least know the very first instructions executed by the x86 cores are under your control. That's all it can really do. Whatever else lurks beneath is really impossible for anyone to scrutinize without insane capital or insider knowledge. Mitigating the risk of Intel ME is obviously something that is complicated. The "state of the art" so-to-speak is really just rendering it non-functional. This isn't strictly related to Coreboot; that said, Coreboot has a page about ME: https://www.coreboot.org/Intel_Management_Engine https://www.coreboot.org/Intel_Management_Engine And in general, when you're running Coreboot, you're running significantly less privileged blackbox blobs (possibly none in some rare cases), and in general, the surface area of Coreboot is going to be dramatically tinier than any typical UEFI system firmware. So it's absolutely worth it in that regard. There's never going to be a "perfect" option here with how complex things have gotten, but I think that you can at least say that Mullvad has taken almost any reasonable step, and perhaps a few steps that are beyond what many would consider reasonable, towards developing effective mitigation of the risks of rootkits, bootkits and malicious/unwanted vendor code running on their "diskless" architecture. Of course, you still have to trust Mullvad. Trust is definitely a meaty human-y experience, and the cold rational part of our brain craves some kind of technically-bulletproof way to prove that it's truly safe, secure, and private, but that's just not possible. Best you can do is layer enough assurances on top of each-other in a way that at least some layers are completely independent of others for maintaining your operational security. Far easier said than done, and obviously how rigorously one approaches this will vary on paranoia. At some point you have to pick your middle-ground I suppose.