I'd say Heartbleed was worse. This one requires local code execution, whereas Heartbleed was "connect to any OpenSSL-using server, send a magic packet, and read the private keys from its memory."
… and nowadays almost everyone permits remote sites to execute code in their browsers. I don't know if JavaScript can be used to implement Meltdown though.
This research has implications for products and services that execute externally supplied code, including Chrome and other browsers with support for JavaScript and WebAssembly.
The difference is scale. OpenSSL was on a lot of servers, but this affects literally every device manufactured in the last 9 years or so. A well-crafted virus could infect nearly any computer and exploit it reliably. We're talking billions and billions of devices, as opposed to millions by Heartbleed.
From my understanding, the VM can exploit it too via executing a crazy amount of syscalls. I may be misunderstanding, but if that were not the case I doubt that AWS would be forcing quick reboots of a ton of its VMs.
Edit: Wait, sorry, I misread. Read is all you really need, write would just be a cherry. If you can read the memory of the host kernel, then you can gain access to any other VMs on the system. This one is bottom-up, you need access to one system and in theory you can gain access to thousands.
True, though the fix for Meltdown requiring a performance hit might exacerbate bad incentives (people not wanting to upgrade) or bad publicity for major corporations (server hosts whose clients now have degraded performance). Whereas Heartbleed had a security cost, this has a possible financial cost.
Also the unpatched devices. Millions of phones don't receive patches anymore, whereas most servers do get patches. They're not really comparable in scale.
… and nowadays almost everyone permits remote sites to execute code in their browsers. I don't know if JavaScript can be used to implement Meltdown though.