I could imagine that in few years, cryptolockers could become so advanced that instead of just encrypting some files on the partition of the current OS, they could also touch all other partitions on main drive (let's say in a laptop).
Full hard drive encryption is not what would solve this problem, as cryptolocker could just add one more layer of encryption.
Do we have any reasonable way to separate the systems? Does UEFI offer anything?
Unless virtualization physically prevents the opreating system from seeing the device as such (e.g. the "disk" really being a VHDX or similar), the answer is "yes, of course". There is nothing special needed for that, and nothing you can do to prevent it from happening, once malware has gained admin privileges.
I wouldn't know by heart how to open the device under Windows (something like \device\harddisk1 or such?), but sure enough I've overwritten the raw device under Linux more than once. Something like cat /dev/random > /dev/sda has been "working fine" for, like... forever, assuming you logged in as root. That's poor man's secure erase in lack of something better.
Installing a boot loader (which is part 1 of the ransomware) is nothing but doing just that, only with not-so-random data. Overwrite the boot loader with a binary of yours that shows the "pay me, sucker" text.
Note that this bootloader (nor the encrypt/decrypt portion, if there is a decrypt portion at all) needs to be able to access the partition or the filesystem in a meaningful manner.
Encrypting (or garbling, the user cannot really tell a difference) is the second part, and that is similarly easy. If you can write a boot loader, you can write sectors. So, instead of files, encrypt sectors on the raw device. Who cares about the logical structure inside those sectors when you can make them unusable either way? Different partition type, different filesystem? You couldn't care less. Someone who wants to use them needs to know, you don't need to know.
This is something the malware can do in a few seconds, there is not even much of a need to be secretive or super smart. You do not need to keep a low profile to avoid detection. By the time the user even notices the furiously blinking light on the computer and wonders what may be going on, the malware will already have overwritten hundreds of megabytes (dozens of gigabytes) of data. If the malware writer possesses only a minimum amount of smartness, this is sufficient to overwrite the filesystem metadata on every partition including backup metadata at their respective well-known offsets, and a couple of hundred megabytes of actual file contents.
Certainly, with only the metadata overwritten, it is in principle still possible to recover the contents of the not-yet-overwritten files, but this is an excessively expensive thing to do, and well beyond the average user's capabilities (and may be impossible for small files on some file systems).
You need not even properly encrypt, you can as well just overwrite sectors with garbage data. The user cannot tell a difference, they only realize after having paid if they are so stupid as to pay a criminal in hope the criminal will stand up to his word.
So... yes, technically this is absolutely no problem (for most computers owned by most people).
Short Version: Probably not, assuming the virus is capable of mounting the partition on its own.
Long Version: On a given computer where you have separate partitions, Windows and Linux each aren't really "aware" that the other partition contains a different operating system. They might understand it, but if you want to you can mount the partition just like any other and modify the file system.
If you can do it on your own, there's no stopping a virus from doing it, assuming it's capable of checking for unmounted partitions to mount. Your only real bet is to hope it can't do that or to put your OS-s on separate disks, which you'd have to remove when you open Windows.
With any luck Windows 10's new system would prevent such an attack but there's no telling for certain.
YES.
The technical pieces necessary to do this are available today (and have been, for a few years now). In fact grub (one of the most popular boot loader on Linuxes) comes with support for many file systems in a very small piece of code. For someone capable of writing cryptolockers (using it as a generic term) without blind-copy-paste, it is not too big a deal.
If they haven't already done it, it will be done (entering the realm of predictions, sorry) as soon as someone thinks it is useful. FWIW, malware authors need to keep their code as compact as possible (both in size and behavior) to evade detection - so that could be one possible factor against it.
The scenarios were multiple OSs coexist in the same computer are virtualization and multi-boot.
In the case of virtualization of type-1 (There is no host machine, aka bare-metal virtualization), the systems are isolated from each other through the virtualization system.
In the case of virtualization of type-2 (A host machine and virtualized guest machines), a guest machine can't access directly the files in the host machine. On the other hand, the host machine can encrypt the entire guest machine file system. Anyway, as the guest machine file system is a file itself in the host machine it's not a different case from actual cryptolocker malware.
Finally, for the multi-boot scheme. A malware is able to mount other system partitions the same way the user does and encrypt the files (Or even the entire partition without mounting!). But protection for this scenario is much harder to achieve.
Every operating system handles permissions granted by itself, that's if the user boots a Linux system and mounts a Windows partition the permissions from the Windows system are not preserved and viceversa.
If the restriction were implemented at the OS layer it could be bypassed or removed by a user or process with enough privileges. Therefore it should be controlled by some element out of the OS control.
AFAIK, UEFI does not offer protections for the scenario you describe, but it has knowledge of the partitions available and works as an abstraction layer to communicate with the hardware. So I think the permissions could be implemented there but maybe it requires architecture changes.
That being said, IMO multi-boot systems are something that a limited ammount of end-users have and not something the majority of the computers have (Most end-users and enterprise environments). A malware with the capabilities you mention looks too much complex for such a small target.
The only possible protection is the least priviledge rule. If the ranswomware can get admin priviledge (or priviledge to write on raw disk partition) on a machine, it will be able to do anything on any disk. It does not even need to understand what file system lies there nor mount the partition, but simply encrypt everything at a sector level. AFAIK, it is still uncommon for cryptolockers to try and access raw dist partitions, but as it is not very hard to do - except for the priviledge question - it could be added if some evil guy believes it is worth it.
So I'm afraid I have to disagree with your "probably not".
– Sas3 Aug 16 '17 at 02:53