Linux PIE/stack corruption
qualys.com
Linux PIE/stack corruption
1–10 of 11 posts
Re: Linux PIE/stack corruption
#2> the loader can allow part of that application's data segment to map over the memory area reserved for its stack resulting in corruption of the stack, with possible privilege escalation
So if you can craft and execute an executable, and you can write to things that you already have write access to, how does that result in a privilege escalation?
If you could overlap with things you shouldn't be able to access, e.g. your kernel stack, then that makes sense. But how does being able to overlap your own user-space result in you being able to do anything you previously couldn't?
Re: Linux PIE/stack corruption
#3> the loader can allow part of that application's data segment to map over the memory area reserved for its stack resulting in corruption of the stack, with possible privilege escalation So if you can craft and execute an executable, and you can write to things that you already have write access to, how does that result in a privilege escalation? If you could overlap with things you shouldn't be able to access, e.g.…
You can exploit existing binaries such as ping that have special capabilities or are setuid to get privilege escalation.
A better link would have been https://www.qualys.com/2017/09/26/cve-2017-1000253/cve-2017-... which also explains an actual exploit.
Re: Linux PIE/stack corruption
#4Here's the actual advisory: https://www.qualys.com/2017/09/26/cve-2017-1000253/cve-2017-...
Most (all?) major distributions (that were affected) have already released patched kernel packages.
Re: Linux PIE/stack corruption
#5> the loader can allow part of that application's data segment to map over the memory area reserved for its stack resulting in corruption of the stack, with possible privilege escalation So if you can craft and execute an executable, and you can write to things that you already have write access to, how does that result in a privilege escalation? If you could overlap with things you shouldn't be able to access, e.g.…
You can exploit existing binaries such as ping that have special capabilities or are setuid to get privilege escalation. A better link would have been https://www.qualys.com/2017/09/26/cve-2017-1000253/cve-2017-... which also explains an actual exploit.
Fair enough.
(But e.g. ping doesn't >128MB .data+.bss? ;) )
Re: Linux PIE/stack corruption
#6> the loader can allow part of that application's data segment to map over the memory area reserved for its stack resulting in corruption of the stack, with possible privilege escalation So if you can craft and execute an executable, and you can write to things that you already have write access to, how does that result in a privilege escalation? If you could overlap with things you shouldn't be able to access, e.g.…
It seems like the idea is that if you pass a very large number of arguments to the process you can force the size of the initial stack to be sufficiently large as to trigger this bug with extremely high probability even on binaries where you otherwise would not have expected the issue; like: it isn't a bug that is being exploited by a weird executable file, it is a true bug in the kernel that can be coaxed to mess with random PIE binaries to gain access to their setuid user access of special capability bits.
Re: Linux PIE/stack corruption
#7I dont understand how a potential exploit would work.
>he loader could allow part of that application's data segment to map over the memory area reserved for its stack, potentially resulting in memory corruption
do they expect an attacker to redirect code execution to an address on the stack which they previously wrote when loading the binary, so they can make use of suid to escalate priveliges ?
Re: Linux PIE/stack corruption
#8Earlier quoted context omitted.
You can exploit existing binaries such as ping that have special capabilities or are setuid to get privilege escalation. A better link would have been https://www.qualys.com/2017/09/26/cve-2017-1000253/cve-2017-... which also explains an actual exploit.
Fair enough. (But e.g. ping doesn't >128MB .data+.bss? ;) )
The article also explains this. It seems to be possible to get a much smaller distance if you eat up a lot of stack space using large execve arguments for example (this might be wrong, I haven't 100% understood all details yet). But the article has a POC for ping.
Re: Linux PIE/stack corruption
#9This was/is really interesting work but should maybe be marked [April 2017] or something so waking sysadmins don't get a fright.
Re: Linux PIE/stack corruption
#10This was/is really interesting work but should maybe be marked [April 2017] or something so waking sysadmins don't get a fright.
The fix was committed in April, but some distros never pulled it in because it wasn't marked as a security fix. Sysadmins should make sure all kernels are updated since as of a couple days ago there was no Cent6 kernel with the fix.