New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
When in doubt, cancel.
Premium 2.6.32 kernel from 2009, all anyone should ever need.
No.
That being said, the CVEs the AI has been digging up seem to mostly affect recent kernels. What if the ancient kernel is safer...?
Doesn't make sense to use in 2026 regardless of how cheap/stable it is.
This is no different than shared hosting, and you cannot encrypt your files.
The provider can just vzctl enter 123 and become root on your VM.
Unless it's something you really don't care about, like a public repo.
No. Ancient ones just not scrutinized with llm. Once they will be - game over.
No one looking for vulns != no vulns.
You know what else has no new CVEs being released for it? IRIX 6.5.30...
To be fair, that's not unique to OpenVZ. You can do the same trivially with LXC, and even with KVM with a little more work if AMD SEV-SNP with proper remote attestation isn't in use.
With KVM you can encrypt your hard drive, which is what the normal practice should be.
Then it will require the malicious hoster to actively dump the encryption keys from the
hypervisor memory, run Volatility or some other forensic method, and even then it's not
guaranteed to be preserved in usable form for offline decryption.
With OpenVZ - every hoster can become charityhost.org at any given time. One command.
It is not safer. And to be fair it is likely not vanilla as it was in 2009, it's heavily patched since, especially for security issues and such. But it's still missing all the improvements and new features (including for performance) since then.
Yeah. But same with LXC. Although there doesn't seem to be many commercial LXC providers, aside from free/hobby ones.
At least with KVM they have to power it down (which you notice), mount the FS, insert their root ssh key or reset root password, power back on. And FS encryption foils that pretty effectively for most cases.
If you're in control of the hypervisor and have full access to guest memory, there will be no issue with memory preservation. But yes, it'll take more commands than a single
vzctlso the average host won't know how to do it.They have access to memory and can spawn a root shell with little difficulty. If they want to look around the VM without you somehow noticing, they can just duplicate it (memory and all) and play with that snapshot.
I'm not sure if it's as simple to control a VM from the outside, even having full R/W access to its memory. Unless there are ready-made tools for that, which I am not aware of (but never looked).
That takes steps which most, unless absolutely malicious, hosters won't attempt.
No trivial way do it, even if you can access raw memory, you need to be able to catch
the PBKDF'd hash used for FS encryption. And an offline attack is absolutely impossible.
Not saying it's not feasible to dig into the dumped guest memory and find some keys, but it makes the entire architecture completely different in comparison to OpenVZ, which is just a glorified shared hosting. This is a 2009 technology on so many levels.
lemme increase your trust issues, kvm also takes 1 command to become root.
Care to demonstrate how? No guest-agents installed, choose any guest OS of your choice.
Disk is fully encrypted during first install. How they say, PoC or GTFO.
There's probably an easier way, but one thing I've personally done a long time ago is modify a single instruction in agetty in memory so that any password is accepted, then login as root.
My dirt cheap provider uses OpenVZ 6
I asked about security and he said he uses firewall to block any exploits.
10/10
/s
I call bs. First, agetty is not responsible for passwords, PAM via /bin/login is.
Agetty only deals with assigning the terminal promt, messing with it will still not bypass password authentication. Show me exactly what you did from the memory side of things.
I still keep my OVZ from AlphaVPS which should have been upgraded back in 2025 and which will never be upgraded
how about i give you a vps, you do the basics any os install and encryption, and start use the vps, then i create a /root/hello.txt ?
if you want PoC you'll have to pay me through, as a sysadmin i don't do such things for free.
And if you fail, you pay me?
no, i won't fail you'll simply push me to go thru more complex things that i haven't sleept on last 17 hours so i'm not planning to go thru
You will definitelly fail
Who said there is going to be /root ?
What if it's Windows with veracrypt and an obscure algorithm that is not keeping a hashed string in a single place in memory?
I can do the same with Linux and opt in for something more exotic than plain simple AES.
Impossible? No. But won't be a walk in a park without reversing - attaching gdb to the qemu
process and live analyzing the memory.
we can surely give a try both linux and windows
it will only be impossible to use memory, if you ask to enable SEV-SNP.
still that would get too custom, and keeping the topic in mind, we'll be talking about things that 99% of people don't do or never heard about, not everyone gets a server and puts up maximum effort on encrypting data, 99% of people don't even use a custom iso they'll simply use the server as is.
IMO is all about privacy and the budget, openvz is less private but cheap, kvm is more private but costs more, dedicated is even more private but costs even more.
if is about data encryption you can also implement app layer encryption and run fine in openvz aswell, so "vzctl enter and youre root" is kind of pointless again IMO.
When livestream i'm buying popcorn and calling the gang
@bustersg see previous related thread:
https://lowendtalk.com/discussion/212975/can-you-explain-why-openvz-is-now-considered-worthless-and-should-i-avoid-providers-still-using-it/p1
Actually spawning processes inside a KVM VPS is probably not exactly trivial but locating the encryption keys in RAM shouldn't be that hard. While i personally usually encrypt the disks on my VMs i'm not having any illusions about it's safety. Its a little barrier to disincentivize random snooping but it surely won't keep any determined attacker out and once the disk is decrypted in theory all kinds of backdoors can be planted.
Did you ask him about kernel exploits?
The problem with this is the ask part. If you are trying to keep your host out relying on it's cooperation is a bit optimistic
But it's totally verifiable from your side after it's enabled. It's based on hardware, so
you can run it's attestation on your guest later.
Azure, GCP and AWS fully support it as part of the "confidential computing" instances.
Really? I mean if there's actual opcodes for that i figure it would at least be fairly inconvenient to emulate those but in general i wouldn't really give too much on information retrieved inside a virtual environment if there's no good will from the hosts side.
Edit: Seems it would basically come down to emulating RDMSR. I'm not deep enough into writing hypervisors to say how complicated it it would be to trap that without running the whole VM in software emulation but any case it's possible (highly likely also without the nasty software emulation part).