Quickly dove into the copy.fail exploit.
-
@q3k I don't think you need any suid binary though; I mean, if you can modify an arbitrary file that you're allowed to open, you could change /etc/passwd or libc.
@penguin42 Right, I'm just talking about the current exploit. I just managed to inject code into an arbitrary process by opening its file, too.
-
@q3k would this primitive also work for overwriting code of an already-running privileged process?
@wolf480pl Yes.
-
@q3k would this primitive also work for overwriting code of an already-running privileged process?
@wolf480pl @q3k
If you managed to get the page swapped out first (with an oom condition or sth), then probably yes, but idk how the page cache interacts with .text mappings to be sure.
If that is possible, then there should be plenty of tasty targets in pid1 - systemd is a pretty thicc binary -
@wolf480pl @q3k
If you managed to get the page swapped out first (with an oom condition or sth), then probably yes, but idk how the page cache interacts with .text mappings to be sure.
If that is possible, then there should be plenty of tasty targets in pid1 - systemd is a pretty thicc binary@implr @wolf480pl You can just write to any running process' .text if you have access to the binary.
You should just be able to write a better implementation of close() into /lib/libc.so.6 - one that also drops you a +s, no questions asked su in /tmp before actually closing the file, and wait until a privileged process bites.
-
@implr @wolf480pl You can just write to any running process' .text if you have access to the binary.
You should just be able to write a better implementation of close() into /lib/libc.so.6 - one that also drops you a +s, no questions asked su in /tmp before actually closing the file, and wait until a privileged process bites.
@q3k
@implr
people have done that with dirtypipe before https://github.com/polygraphene/DirtyPipe-Android/blob/master/TECHNICAL-DETAILS.md -
Quickly dove into the copy.fail exploit.
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).@q3k working around the broken execve is trivial enough like you said; https://social.treehouse.systems/@astraleureka/116490148181953204
it's pretty amusing seeing the trodden pagecache results persist afterwards -
Quickly dove into the copy.fail exploit.
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).@q3k So I guess you can disable it by a seccomp or bpf that blocks hmm, socket(2) with AF_ALG ?
-
@q3k So I guess you can disable it by a seccomp or bpf that blocks hmm, socket(2) with AF_ALG ?
@penguin42 Yeah, or just yeet the vulnerable module (`algif_aead`).
-
@penguin42 Yeah, or just yeet the vulnerable module (`algif_aead`).
@q3k ..if your distro hasn't built that in.
-
@kasperd @penguin42 While I am a security consultant I am not _your_ security consultant, so the best I can offer you is an enthusiastic 'yeah, I guess so!'.
-
R relay@relay.mycrowd.ca shared this topic
