2 ms·
> That seems contrived and kind of stupid? So do most bugs and seemingly safe assumptions that lead to privilege escalation. In practice, it's unlikely an unt
by chatmasta 3y ago
> That seems contrived and kind of stupid?
So do most bugs and seemingly safe assumptions that lead to privilege escalation.
In practice, it's unlikely an untrusted user would have access to calling logrotate directly, but would instead call it through a chain of mechanisms that each individually seem innocuous, but become dangerous when combined together. Maybe they've got a foothold through parameter pollution allowing them to execute shell scripts as the apache user, which has sudo privileges for logrotate. Combine that with the ability to write relatively arbitrary data to logs, and you can see how things might begin to fall apart.
For example, here's a HackTheBox writeup [0] that exploits a race condition in logrotate on the path to getting root. It's not the exact same scenario as in OP, but it's a similar idea.
[0] https://0xdf.gitlab.io/2020/07/11/htb-book.html https://0xdf.gitlab.io/2020/07/11/htb-book.html
- jchw 3y agoIMO it's not very interesting if you start with a blatantly unsafe assumption like putting a wildcard NOPASSWD line in sudoers. This would be interesting if it was somehow a default configuration, but it's blatantly weird to add it and then break it, given that it is a contrived configuration that I don't think you could easily convince sysadmins to add. I assume the point of this is as a practice exercise for a potentially less contrived use case. That's cool, but it's still not particularly interesting...