181–190 of 545 posts
LPE = local privilege escalation Too many darn acronyms. This one wasn't too hard to figure out from context but I wish people would define acronyms before using them!
Good writing for a broad audience requires it. Unfortunately the LLMs don't tend to adopt this guideline.
For mitigation, the page currently basically just says: > Update your distribution's kernel package to one that includes mainline commit a664bf3d603d But it isn't very clear to me what Kernel version you can expect that to be in. For Arch/CachyOS, the patch seems to be included in 6.18.22+, 6.19.12+ and 7.0+. If you're on any of the lower versions in the same upstream stable series, you're likely vulnerable right now…
On a git repo that has as remotes https://github.com/torvalds/linux.git https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git as remotes: running a search for commit a664bf3d603d's commit message: git log --all --grep 'crypto: algif_aead - Revert to operating out-of-place' '--format=%H' | xargs -I '{}' git tag --contains '{}' | sort -u outputs these tags as having the fix: v6.18.22 v6.18.23 v6.18.24 v6.18.…
For this crowd, I highly suggest checking out the technical writeup https://xint.io/blog/copy-fail-linux-distributions
1. Yes, it's real.
2. Current chain can write any arbitrary content to any user-readable file (into the page cache).
3. Current chain relies on an available target suid binary that you can open() as a lowpriv user.
4. Current exploit relies on that binary being /bin/su and then being able to execve(/bin/sh, 0, 0) (which doesn't work on alpine, etc.). The former is easily replaced in the code. The latter needs a rebuilt payload ELF (also easy).
5. The authors say they have other chains (including ones that allow container escapes). I believe them.
6. A mildly de-minified PoC for Alpine with a new payload ELF is at hackerspace[pl]/~q3k/alpine.py . You'll need /bin/ping from iputils. This should be now somewhat reliable on any distro that has a `/bin/sh` and any setuid-and-readable binary (you'll just need to find it on your own).
Earlier quoted context omitted.
ugh sorry should be fixed. There was some scrambling to get more info together to explain the issue (and yes, obviously marketing), so there are some minor mistakes. Thanks for pointing it out!
> obviously marketing Why marketing though?
Earlier quoted context omitted.
ugh sorry should be fixed. There was some scrambling to get more info together to explain the issue (and yes, obviously marketing), so there are some minor mistakes. Thanks for pointing it out!
> obviously marketing Why marketing though?
Earlier quoted context omitted.
I don't see it as fetishizing byte count. I think of it as a proxy measure for how complicated or uncomplicated the exploit might be. They could just as well have said "we can do it in 3 lines of python" or "the Shannon entropy of the script implementing the exploit is really small" and I would have interpreted it similarly. Where do you see this "fetishizing" happening most often? It's a strange thing to counter-fet…
> I think of it as a proxy measure for how complicated or uncomplicated the exploit might be. From a Busy Beaver, 256-bytes compo, or Dwitter perspective, 732 bytes isn’t really that meaningful. And the sample exploit is even optimizing the byte size by using zlib compression, which doesn’t make much sense for the purpose. It just emphasizes the byte count fetishization.
Earlier quoted context omitted.
I have no idea about this page, but Theori/Xint has a staff of veterans, they are a serious thing.
Dropping a public exploit on github before distros have patches available isn't very cool, or is that just how veterans roll these days?