linux 0-day, access root-owned files as an unprivileged user
37 points by dzwdz
37 points by dzwdz
Please note that disabling ptrace isn't sufficient, despite the commit message and the function involved: ptrace_may_access is called from all over the place and indeed this PoC doesn't use ptrace.
In terms of mitigations, there's not great options. AFAIK it's really down to:
/usr/lib64/misc/ssh-keysign as a very weak mitigation for this specific PoC only (only do this if you need to go to bed right now and you can't patch your kernel or shutdown the machine) (*);pidfd_getfd with eBPF or the like (systemtap would be another option). Not much uses it and there's often a fallback.I haven't reviewed the PoC, usual caveats apply w/ running random PoCs from the net.
The Qualys advisory hasn't been published yet, they recently said they'd stop doing linux-distros with heavy regret because of the Linux kernel security policy. LLMs being able to go from some fix commit that is possibly suspicious to a PoC most rapidly has made things rough. Otherwise you could get away with waiting a few days in normal times.
Qualys are real legends and it's unfortunate that they don't get a proper moment to announce this themselves now. I'm confident that when it does appear, it'll be excellent though.
(*) openssh is a convenient target for this and not to blame. There will be other (suid) binaries to pick on.
This is a Linux issue, not an ssh issue. The title should reflect this.
The proof-of-concept is pleasantly short, and my boxes are indeed vulnerable.
It seems that this lets you access file descriptors opened by setuid executables under some conditions. I... see no reason why this would be only limited to reads. Surely you can twist this into an LPE that doesn't require cracking a hash.
You can break this poc in particular with chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage (you might need to change the path to ssh-keysign. see also the manpage), but that doesn't fix the core issue, and it can probably be worked around. There are no other mitigations available that I know of.
edit: this was fixed (and thus publicized) in ptrace: slightly saner 'get_dumpable()' logic (excuse the github link). 10 fucking hours ago.
edit 2: Here's a public announcement from Qualys sent to oss-security.
We are not publishing our advisory yet, to give distributions and users a chance to patch.
This is going to be good, I'm looking forward to it. In the meantime, here's Brad Spengler's (of grsecurity) commentary. It seems like that's the tweet that drove the development of this PoC.
I tried running the PoC and wasn't able to get it to win the race, but the exploit_vuln_target/vuln_target pair worked fine. Bleh.
Can the kernel please stop 0-daying itself by just publicly committing fixes to the main branch? It even says ““Reported-by: Qualys” in the commit, so it's obviously a security fix.
What should they do instead?
Ideally, send a patch to the distros' security mailing lists, tell them to have the packages ready to ship in 24h, and merging to main at the same time the distros release the patched kernels.