Can someone explain this a bit? While I can understand how these bugs arise, I'm not the best at exploiting them.<p>The summary states,<p>> disclosed a glibc NUL byte off-by-one overwrite into the heap.<p>> a full exploit (with comments) for a local Linux privilege escalation.<p>Normally, I wouldn't see how such a bug could lead to privilege escalation. (glibc runs in userspace, after all.) But it is glibc, and glibc is everywhere.<p>I <i>think</i> the key is in the source code, where they state,<p><pre><code> // It actually relies on a pkexec bug: a memory leak when multiple -u arguments are specified.
</code></pre>
pkexec is setuid, so if it has a bug, then it's a great target for privilege escalation. Is the exploit the fact that they're passing bogus arguments to pkexec in such a way as to trigger this bug, corrupt the heap, and cause pkexec to either execute a binary of their choice or execute arbitrary code?
I was interested to learn that the kernel actually allows you to pass 15 <i>million</i> arguments via execve(), with each one allowed to be enormous.<p>It seems very much like asking for trouble - I can't offhand think of a good reason why this would be required.<p>I'm sure there are plenty of programs that have similar memory leaks with commandline args, as many authors might, not unreasonably, think that abuse would be prevented by the shell ARG_MAX, which is 2621440 bytes on many systems. Perhaps some sort of adjustable lower limit might be appropriate here.
I just want to join the choir and thank the author/poster. Really great article. I managed to learn quite a few things and there was just enough detail given to go and look up any background information necessary to complete understanding.