End goal

Posted Jul 4, 2024 23:56 UTC (Thu) by josh (subscriber, #17465)
In reply to: End goal by comex
Parent article: Another try for getrandom() in the vDSO

In general, uses of vmfork that care about security are forking at request time, not at some random time in the middle.

End goal

Posted Jul 5, 2024 4:17 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (5 responses)

Personally, I'm unclear on how a mid-request fork would even function. Both parent and child VMs are (presumably) going to be trying to talk to the remote host at the same time. If your guests have distinct public IP addresses, then at least one of the two connections should break right there. If not, then you'd have interleaved TCP streams with duplicate sequence numbers, and the whole thing should fall apart pretty quickly.

The only case I can think of where this could possibly work is when the application is in cahoots with the VM management plane and intentionally causes VM forks to occur as part of its request handling logic. But in that case, this is trivial: At worst, you have to design your request handling logic to ensure that the fork does not happen at the same time as some delicate crypto code is running (e.g. take a lock). Which you were maybe already doing anyway, since some code in this genre uses a userspace CSPRNG instead of getrandom (for the performance reasons cited in the article), and that absolutely requires you to be aware of forking and mitigate it.

End goal

Posted Jul 5, 2024 5:51 UTC (Fri) by comex (subscriber, #71521) [Link] (4 responses)

When I mentioned TLS, I was imagining a scenario where the VM just happens to fork while some software on it is coincidentally in the middle of a TLS connection, and meanwhile there is an on-path network attacker specifically waiting for it to fork, with a custom TCP implementation designed to paper over the broken sequencing.

As for why the VM forks in the first place, well, as one possibility, it could be a desktop VM which the user manually chose to fork (while some service was talking to the network in the background). Some desktop VM software offers cloning as an option. Or even without cloning, the risks seem similar if the VM is just restored from a snapshot.

Admittedly, waiting for a desktop VM to be forked/restored seems like a pretty niche thing for an attacker to do, but not completely unrealistic. I'm sure there are people who make a habit of regularly restoring their VMs from snapshot.

End goal

Posted Jul 5, 2024 20:28 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (3 responses)

> When I mentioned TLS, I was imagining a scenario where the VM just happens to fork while some software on it is coincidentally in the middle of a TLS connection, and meanwhile there is an on-path network attacker specifically waiting for it to fork, with a custom TCP implementation designed to paper over the broken sequencing.

That would require the application to be originally deployed in a broken state where it randomly drops TCP connections for no apparent reason. Maybe there are some people who do that, but I wouldn't want to work there.

End goal

Posted Jul 5, 2024 20:43 UTC (Fri) by comex (subscriber, #71521) [Link] (2 responses)

I think you're still envisioning a server. That's definitely one possible scenario, but as I described in the rest of my comment, a simpler scenario is a desktop VM where the user is manually pausing the VM and either restoring it from snapshot or cloning it. Yes, this normally drops TCP connections, but not for no apparent reason.

End goal

Posted Jul 5, 2024 23:28 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

Simpler, and far less common. The people running desktop VMs are mostly security researchers and a few power users and hobbyists. Especially if it's desktop *Linux*. In the real world, to a first approximation, a Linux VM is nearly always a cloud VM.

End goal

Posted Jul 5, 2024 23:31 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

(Just in case I wasn't clear enough: Attackers usually want to compromise as many users as possible, so an attack that only affects a tiny fraction of the computer-using population is simply not worth developing. Especially when a significant portion of that tiny fraction is made up of security researchers, whom malware authors generally try to avoid hitting in order to further obfuscate their work.)