3 ms·

That seems contrived and kind of stupid? Why would a random user account have access to `sudo logrotate`? logrotate is presumably for rotating logs, and the on

That seems contrived and kind of stupid? Why would a random user account have access to `sudo logrotate`? logrotate is presumably for rotating logs, and the only need for root is to rotate system logs. So under what circumstances does it make sense for a random, otherwise unprivileged user to have ability to rotate system logs, but not the ability to do other administrative tasks? It's also a tool that operates on random user-specified files, so makes for an absolutely terrible choice of command to let an unprivileged user to run. I suppose the intent here is showing how a supposedly restricted sudo ability can be exploited into something bigger. That is a good point, but I think logrotate makes for a weird example of it. Also, use journald and just have it deal with that. If there's a need to deal with log rotation by hand something isn't setup quite right.

fragmede 3y ago
sudo less <root 0755 log file> is/was also escalatable, which is much more innocuous for a an untrusted user to read error.log files for their account.
- rjh29 3y ago
  There are so many. I know a perl script that opened a pager for its man page, which is then escalatable if run under sudo.
fullspectrumdev 3y ago
A lot of “appliances” make design choices like this - the web user has sudo access to a handful of commands so shit can be done from the webUI. Which makes things like this useful for when you get code execution in the web interface and want to break root
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 ago
  IMO 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...

fragmede 3y ago

sudo less <root 0755 log file> is/was also escalatable, which is much more innocuous for a an untrusted user to read error.log files for their account.

rjh29 3y ago
There are so many. I know a perl script that opened a pager for its man page, which is then escalatable if run under sudo.

fullspectrumdev 3y ago

A lot of “appliances” make design choices like this - the web user has sudo access to a handful of commands so shit can be done from the webUI. Which makes things like this useful for when you get code execution in the web interface and want to break root

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 ago
IMO 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...