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
True. It is a local privilege escalation bug. But if you look at the vDSO exploit, it didn't need anything beyond PTRACE_POKEDATA. vDSO is in the address space of nearly every binary.
Does anyone know if this affects CentOS v6 ?
It does - https://access.redhat.com/security/vulnerabilities/2706661
No fix for RHEL6 yet.
Yes it is. I can't find if there's a patch for it yet though. This is why I love KernelCare because it patches kernels before the distros do.
Reason I asked was because they said it doesn't affect RHEL5 and RHEL 6 at https://bugzilla.redhat.com/show_bug.cgi?id=1384344
There's another variant that uses POKE
monTEXT instead of writing to /proc/self/mem, I tested the PoC (https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c) and it worked on CentOS 6 default install.That systemtap thingy seems to mitigate the issue but it's very cumbersome and obviously I did not test all possible cases.
I see, thanks for the confirmation
hopefully there is patch soon then!
Maybe a silly question, but is this exploitable on shared servers running CloudLinux? As in users with jailed (ssh) access can escalated themselves to root?
Cheers!
There are two known classes of exploits:
/proc/self/mem(mem_write) andptrace(PTRACE_POKEDATA).From what I gather:
CentOS 5/6 have mem_write disabled by default, but not so in CentOS7.
The OCI standard blocks
ptracefor containers/jails by default. I am guessing here but newer-style docker/lxd may disallow ptrace by default, but not the older OpenVZ.If you cant use a patched kernel, then the systemtap mitigation blocks known exploits (both mem_write and ptrace are disabled).
Caveats: Blocking
ptracewill mess with debuggers, virus scanners. It may also impact self-protection/obfuscation code present in commercial software like games.List of published exploits here. Some of them will crash the kernel, so don't try on a production system.
Indeed that was the point of this thread...
... It'll be a havoc otherwise!
Want to know the possibility of this too
Well cloudlinux provided a patched kernel so you can be pretty certain it does yes.
>
I suppose the non-patched exploit implementations have not been magically resolved though
maybe I am wrong but my understanding was the the CL kernels and kernels with Kcare patches are not vulnerable, if I am wrong this is the very least anyone should have done by now as it is as protected as you can be.
Official updates for CentOS 6 and 7
Resolve tab
Kernel scanner for Dirty Cow: https://github.com/aishee/scan-dirtycow.
Kernel patch fix Dirty Cow: https://github.com/aishee/fix-dirtycow.
@Aishee the scanner will mark kernels updated by kcare as vulnerable will it not? (did a 10 second code scan) ?
bookmarked ..
For people running Ubuntu LTS, Dirty Cow was livepatched within only a few hours of it's publication so if you have any servers running Ubuntu LTS you should try out their new kernel livepatching that is free for up to 3 desktops/servers.
http://blog.dustinkirkland.com/2016/10/dirty-cow-livepatched-in-ubuntu.html
What I appreciated about Ubuntu was the fact they even patched the EOL LTS versions within hours along with non-EOL LTS versions.
Yup! I remember receiving a kernel update extremely fast.
So is OpenVZ vulnerable via container or not? I read this whole thread and it's still not clear to me.
Nobody has console access to the node. They do have console access to the container (SolusVM).
No, it requires a local account on the node. A VPS will not work unless they "break out" of the VPS through another exploit.
If someone has a local account on a container then only the container is vulnerable since it shares the node's kernel.
Ok thanks, as long as they cannot break out of the container or crash the node that is all I care about.
You're still leaving your client(s) vulnerable because they can't upgrade the kernel or apply a patch. Only you can.
How are they vulnerable? If an unauthorized person gains console access to their servers somehow then that person already has root access (the only console access they get with SolusVM). So unless I am missing something, that would be a bigger problem and it wouldn't matter if this vulnerability existed or not at that point.
They are as vulnerable as you are if you have a local account on your node since they share the same kernel.
If they have a local user account on their container, that user can escalate their privileges.
I don't see that as a problem the way we do things because only authorized root users have access to the console before they ever get to it regardless of who they try log in as. We disable public access to SolusVM.
I don't think you understand then. Let me create a scenario for you:
Customer orders container.
Gives user accounts (adduser/useradd) to someone.
That someone uses the exploit to escalate their privilege (SU/root).
Damage can be done to the container.
I've already tested it; hence I updated my OpenVZ kernel to 042stab120.6