3 ms·
Well, that's mind-bending. I couldn't figure out how/where the actual exploitation of su happened since it seemed to require some careful synchronization, unti
by a1k0n 15y ago
Well, that's mind-bending. I couldn't figure out how/where the actual exploitation of su happened since it seemed to require some careful synchronization, until it hit me: His exploit essentially starts up a process which, when it writes to stderr, is writing to its own memory. Then, it lseeks to the correct position which would cause su, when writing its error message, to overwrite its own exit() with shellcode. And then it just exec()s su with these preconditions, and it works. Dang.
- Animus7 15y agoMakes sense. But this strategy for me begs an important question: why the <bleep> is it even possible to write directly to memory over an fd? I get that "everything is a file", sure, but you've already got ptrace for insane use cases that require trashing another other process's memory (i.e. a dev toolchain). I've been twiddling bits in C(++) almost every day for over a decade and I've never once felt the need for such a feature, except when theorizing about exploits. Alas.
- forgotusername 15y agoptrace() lets you read a word at a time per syscall (slowwww), presumably /proc/pid/mem allows mmap'ing full regions in a single syscall.
- seclorum 15y agoI have used the ability to write to /proc/pid/mem to TEST safety-critical software intended for deployment on Linux systems. The apps I wrote were designed to ensure that altered binaries were not being run on the target system - in order to test the effectiveness of this "TEXT Segment check", I wrote many test cases to overwrite memory using this mechanism. Its useful in that context.
- gcb 15y agoI'm still clueless how su gets the same pid as his exploit... Maybe i will get it when it's not 4am
- caf 15y agoPID does not change on execve().