End goal

Posted Jul 5, 2024 20:28 UTC (Fri) by NYKevin (subscriber, #129325)
In reply to: End goal by comex
Parent article: Another try for getrandom() in the vDSO

> 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.)