Someone here at work just made an interesting claim; they stated that it's possible for malware, launched in e.g. Windows, to remain in RAM through a reboot and continue working in Linux on the machine when it boots.
Are they right? I'm almost certain that's impossible, but am happy to be corrected.
They are not correct. Anything left in memory after the machine reboots, even if not overwritten, won't be active. This is because there is no code in any used operating system which looks in unallocated space in memory and executes anything that looks like code. While it is possible for specially designed malware to be cross-platform and to infect another operating system by virtue of having access to the storage device it resides on, it will not be able to persist an infection by staying in memory after reboot. For a more comprehensive description of the boot process, see System Initialization (x86) - OSDev.
Note that this only applies to system memory. In theory, malware that runs on the GPU may persist across reboot. The reason for this is that a warm reboot just resets the CPU. It does not power cycle peripherals, so a discrete GPU will still be executing code and retaining memory throughout the boot process. Malware that is made to run on the GPU may then use direct memory access to re-insert the malicious code in the main operating system. However, this will be fairly hardware-specific, and will not work if the device is booted up from a cold state (i.e. power is actually cut, including to the GPU).
They are correct. It is certainly possible for malware to migrate between operating systems on the same host, and in many different styles. To better answer this, distinctions should be made between virtual operating systems and dual booting, but at the end of the day, a compromised operating system can can reach out and interface with the host directly, and therefore potentially compromise it.
If we are talking about specifically a dual-boot scenario: Malicious firmware could certainly compromise every OS on the host. So, do we have physical access to boot it from arbitrary firmware? Is the separate OS in question on a separate HDD? What about secure boot options, bios admin passwords, encryption etc? We need to know a lot more to tell you how specifically this is done, I'm trying to give a general outline though.
If we are talking about a virtual scenario: There are a ton of different flavors of attacks surrounding hypervisor sandbox escapes, it's up to you what you do from there. Another user incorrectly stated that whatever attack it is will probably not be persistent, and that is just absolutely wrong. We have no idea what the initial compromise was. If you escaped a hypervisor sandbox or you booted the host from arbitrary firmware... It's game over in terms of persistence and spreading to the entire HDD (depending on the previously-mentioned conditions).
More specific information is required in order to accurately answer this in detail. Do we have physical access to the host? Are the OS's virtualized? Etc. Though the TL;DR is that yes, theoretically malware can certainly spread between OS's on the same host, both in the virtual and dual-boot scenario. Totally different implementations are applied between each, but the same goal is met and is extremely common in the malware research field.
Here is a very-loosely related question that describes the security risks between utilizing virtualization or dual booting: Is there a security benefit of using a Virtual Machine over dual booting?
