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
My jaw genuinely dropped when you had to go that far.......
customer can be exploited, customer cant apply fix, your customers share your kernel... how much more info could anyone need...
Console access in Solus is already root access. You cannot assign non-root console access. Unless I am mistaken this exploit does not work over SSH.
Sorry to hear about your jaw. You should get someone to look at that.
What has this got to do with Solus?
Maybe you should look into that because I don't think you understand how it works.
Okay then, I'll stop wasting my time with you.
wow...
Ok scenario.
Your customer installs cpanel, your customer gives shell access on a cpanel account, your customer can then have their cpanel server exploited/hacked/rm -Rf'ed because you wont apply a patch that takes less time to apply than your last response took.
But I guess as long as it only affects your customers and not you.. no big deal ...
I could give you 20 more examples but now I need to go get my jaw fixed for the second time
Isn't it weird how ubuntu a OS that is? should? be free, is offering a premium core service (aka for 3+ machines)? regarding the livepatch.
No. The mechanism to patch the kernel is open and available to everyone, it's the live patches themselves that they're monetizing.
Just think of this as paying Canonical for support. It's the same with RHEL's kpatch and SUSE's kGraft.
@moonmartin
THERE IS MORE THAN ONE USER - what can't you understand? If I logged in to my OpenVZ VPS, as the user thisisnotroot, I can use the exploit to gain root privileges of said container.
Hold on, I'll even show you. Just wait.
Wow I really hope you don't host a lot of people. You clearly have no idea what you're talking about..
@moonmartin
(INTRO SONG) ARE YOU SMAA-AAA-RTER THAN A FIFTH GRADER MY PET ROO-OO-OCK?
Host: Welcome back, folks! The last question is... true/false! Is SolusVM related to SSH?
Moonmartin: FOR CRYING OUT LOUD YES!
Host: It appears that you ARE WRONG! I guess that you're NOT SMARTER THAN A FIFTH GRADER MY PET ROCK!
well to be fair, he is not using a provider tag, he may just be trolling or just using it for very small scale personal use for friends etc so probably does not have much to worry about or really be expected to understand.
You can't get Redhat or Suse's livepatching for free, so it's actually really cool that Ubuntu IS giving their livepatching for free (on 3 machines).
You don't have to use it but if you do use it, it will make sure your server is patched when a dangerous kernel exploit comes out and you're not around to login to your server or for whatever reason you can't reboot at the moment it allows you to stay secure until you can upgrade the kernel and reboot.
@AnthonySmith
I feel like it's my duty to prove it to him that this can be exploited in other ways:
I guess you guys are all just doing it different. We control access to the tty console. If someone has access to get at their console (regardless of who they want to log in as) then they have full root credential access before they ever log into their server on the console. That is because there is another layer they have to authenticate into before they ever get there and only root users have that access.
This is still assuming tty console access to the container is required to do this. Nobody has answered that for me yet. Customers also have direct SSH root access. Of course they can log in as non root users on SSH if they want to. For what we do nobody is going to be creating non root log ins for SSH or console anyways but that's besides the point.
It would be nice to get a mature response about this instead of these guys selling $12/year servers which may not be that far off from their actual age. I'm not interested in pissing contests about security.
yep, for sure a troll, no doubt now.
So @moonmartin, how many years have you been in the hosting industry?
Because to be honest with you, you act more like a child than Jonny.
If you say so. We certainly don't do and have no interest in low end stuff. Judging by your responses you seem to feel like you have something to prove. That's on you.
This guy is worse than Noogats, don't even bother @FlamesRunner
As I said before, this exploit requires a local user on the server. The point others are making is that some of your clients may have local users so it's in your and your clients best interest to patch your kernel to protect them since the kernel of the host node is shared for the OpenVZ containers (clients cannot update their kernels for OpenVZ). Console access through SSH via SolusVM cannot be used to exploit this.
EDIT: You should be using KernelCare anyways which patched this on the 26th. You don't deal with the low end market so there's no reason why you should ever have to reboot your server for kernel patches.
tbh I don't even run a production OVZ node and I still updated before this kid
This is where your confusion comes from. This can be exploited via SSH by a privileged user. The user requires no access to the SolusVM console to exploit this. So at this point the reason that you want to fix it is because your customers have root access, and you can never say with 100% certainty what they'll do tomorrow. Should they add a privileged user at any point, they will then be in danger. The alternative, I suppose, would be to monitor their containers for new users and power them down if they add them. The upgrade, however, will take less time than this task.
I'm quite familiar with those. They lead you down a never ending rabbit hole of "nothing can ever be secure" to the point that, if you listen to them enough, you have no more customers and you've powered your servers off. That is not at all what is happening in this thread.
Quite frankly, if it's your job to decide whether or not to address this vulnerability and you jumped to the conclusion that privilege escalation requires direct mouse/keyboard access (like SolusVM's console basically is), then you really need to be more open to what other people suggest, because if you're not selling at low end prices then you have far more to lose. You need to quickly address this knowledge gap or bring on another employee who can fill that gap for you. Privilege escalation vulnerabilities in the kernel is not an edge scenario, it's not down the security pissing match rabbit hole at all, this is sysadmin 101. The words "privilege escalation" should have even the least security conscious among us jumping out of bed at 3AM to perform an emergency update.
I'm not insulting your intelligence, I'm being brutally honest. For the sake of your customers, I hope you are able to dial down the pride just a bit and recognize your responsibility here.
Ok 2 dumb questions: uptdated kernel on VPS and a dedicated both rrunning CENTOS.
Reboot server and kill my sexy uptime or am I good to go?
I also have a question with SolusVM KVM nodes, if all the KVM VPS's themselves are patched up but the node itself isn't patched up but in the node itself there are no other users other than root user can the security vulnerability still be exploited?
The answer is still no. See below:
Ok thanks for clarifying, I was 99% sure that it was the case and now its 100%
I think we need to stop feeding the troll here guys
Well yeah you need to reboot if your not using kernel care.
This place isn't interesting without them though