9 ms·

root with a single command: sudo logrotate

123 points by skilled 3y ago

cornholio 3y ago
If you can sudo, you already have root, albeit limited. It's more of an ergonomic feature to discourage users logging in as root and destroying the system, than any kind of reliable security compartmentalization. Realistically speaking, most applications you would want to allow others to run as sudo were never designed to withstand such attacks and will likely fail in the hands of a competent attacker that is free to use any command line, feed any input etc.
- deleted 3y ago
  [deleted]
- Jenk 3y ago
  > If you can sudo, you already have root, albeit limited. It's more of an ergonomic feature to discourage users logging in as root and destroying the system, than any kind of reliable security compartmentalization. I figured it was so you can identify the user who ran the command in an audit, instead of everyone just appear as "root"
  - Guvante 3y ago
    Most use it like that the post uses a limited form where only certain commands can be ran.
  - LinuxBender 3y ago
    I figured it was so you can identify the user who ran the command in an audit, instead of everyone just appear as "root" This goal can still be performed if auditd is enabled. The transition from non-root to root is tracked with the right rules in place. In my opinion it is best to rely on auditd and immutable after being tested rules as there are many ways to elevate privileges and many ways to improperly configure or bypass sudo. Auditd has a plugin to log directly to syslog and/or forwarded to ELK, Splunk or other tools. Auditd is also important when applications are exploited and someone then uses a privilege escalation vulnerability otherwise the person will just run it again after the machine/VM/container is re-imaged. Sudo was never intended to be a security control as much as it was to give a non sysadmin the ability to restart something or launch an on-demand process that required root or other accounts despite people using it in their documented controls. Many people will disagree with me on this as has been the case since the inception of sudo. One caveat being auditd with the most useful rules in place can get rather noisy and more to the point, costly in terms of storage and/or Splunk license. It comes down to the priorities of an organization or business.
    - Jenk 3y ago
      Yeah I meant more when folk `ssh root@host` over `su - root` But I do recall it being a lot more pleasant tracing who ran what sequence of commands, on a host used by many people in concurrent workflows, when it's sudo over su. It's also been some ~20 years since I've been in a role that required I do this so I (most probably) have forgotten a lot.
  - orev 3y ago
    One of the main benefits of sudo is that nobody needs to know the root password to switch to root (like one would need when using su). The actual root password can be saved in some break glass system, and admins only need to manage their own passwords.
    - Jenk 3y ago
      That is a penny drop moment for me. You are absolutely right that that is the primary purpose.
- crtasm 3y ago
  > the user cannot run anything other than sudo logrotate Very limited!
jchw 3y ago
Sigh. It's disappointing to hear that this is the default in Ubuntu Server. As long as I'm understanding it, it doesn't appear to be an immediate concern, but it does demonstrate that the security design is quite a bit half-baked at least in this specific area. I don't think every Linux distribution needs to aspire to be as proactive about security as OpenBSD, but it would be nice to see better care put into features like this to make sure they're restricting capabilities as expected, with at least more than one mechanism protecting the system from compromise. Unfortunately my kneejerk reaction is to assume that most of the work on Ubuntu Server is going into development of Snap-based Ubuntu Core, wherein the security model is completely different and none of this applies, perhaps? But a ton of people deploy ordinary Ubuntu Server today, possibly more than Core... so that doesn't bode well. (OK, maybe I really do just want OpenBSD.) edit: Wait a minute. This post says "brand new", which made me think this was stock configuration. However, is it? I would feel immediately relieved, and my entire comment would be irrelevant, if that wasn't the case.
- richbell 3y ago
  The post doesn't do a good job explaining whether this is the stock configuration or purely a hypothetical. My initial reaction was the same as yours, but upon further reflection I get the feeling it's just a thought exercise.
  - dale_glass 3y ago
    Not stock in 23.10, as far as I can tell.
  - jchw 3y ago
    I'm a bit miffed that people are getting downvoted for not realizing this is not the default behavior, when I have no idea how you were supposed to gather that from reading the article. I did actually check to see (in Ubuntu 23.04) but honestly, that doesn't clear up much given that I have no idea what different installation modes of Ubuntu may yield. Yeah, it's fair enough that it completely negates all of the points to be made about distro security, but also, it's not really our fault that the article is unclear.
fuzzybear3965 3y ago
I think PolKit can be used to delegate fine-grained control to users. Which other tools are available on Linux to control users' access to fs and network resources? File permissions, systemd-nspawn?
- spmurrayzzz 3y ago
  > Which other tools are available on Linux to control users' access to fs and network resources selinux is the primary one that comes to mind, it definitely ticks the "fine-grained control" checkbox for sure
- orange-mentor 3y ago
  One could write a very small custom binary in C/C++/Rust that runs the command, and then give that binary setuid permissions. That binary can simply run a subprocess, and nothing else.
  - blibble 3y ago
    you could call it "sudo"
blueflow 3y ago
sudo /usr/sbin/$SSH_ORIGINAL_COMMAND By the way: SSH_ORIGINAL_COMMAND is a command like you would give to sh -c, basically a tiny snippet of sh code. Its not an argument vector! You either need a shell to kind of eval it or parse it with wordexp(3) before you can reliably tell which executable name it refers to. Mean people might send one starting with '$(' or another expansion. Remember this is valid: ssh host '$(echo id)'
- mmsc 3y ago
  With the following test.sh: #!/bin/bash case "$SSH_ORIGINAL_COMMAND" in *) sudo $SSH_ORIGINAL_COMMAND ;; esac and the ssh-based restriction: command="/tmp/test.sh" $ ssh user@server 'uname > /tmp/123' uname: extra operand ‘>’ Try 'uname --help' for more information. $ ssh user@server 'uname $(ls)' uname: extra operand ‘$(ls)’ Try 'uname --help' for more information.
charcircuit 3y ago
Why does logrotate even have permission to read or write any file in /etc? When will distros take security seriously?
dale_glass 3y ago
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
xorcist 3y ago
The example contains an asterisk in the allowed commands field. That's not something you would normally do with users who would not otherwise have root privileges. There are (figuratively) an unlimited number of ways to compose commands that do arbitrary things. Security audits explode in complexity. Always list every literal command that is allowed. Make a command wrapper if necessary. (Also, never allow arbitrary environment variables.)
deleted 3y ago
[deleted]
gorkish 3y ago
I too can break into my own house when I leave a door wide open for myself. There is nothing wrong with logrotate, ubuntu, ssh, or sudo here. Once you are passing arbitrary strings to bash as root -- yeah it's gonna be game over. This reminds me of the time a pentester found an XSS vuln and spent the entire rest of the engagement stuffing a keylogger into it. Like, OK, thanks, we already understand the implications of XSS. The solution provided is suboptimal because all the focus is spent in making a good exploit demo instead of considering the root cause(s): the configuration of ssh, sudo, and the godawful shell script the author dredged up from parts unknown. As I have seen this style of script being used with forced commands in authorized_keys, my conclusion is that the author loosely followed some online guide for restricting SSH access to certain commands and either inherited the flawed original script or made the error adapting it to the local requirements. Proper options for restricting the shell abound. From the top of my head: rssh, sshdo, PolicyKit, rbash, rush
- burnte 3y ago
  This is what Raymond Chen describes as "being on the other side of this airtight hatchway". https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
  - charcircuit 3y ago
    That is different. The user is intended to have privilege to rotate logs as root, but after the exploit the user is elevated to have full root.
- mmsc 3y ago
  OP here: I never said it's something wrong with logrotate, ubuntu, ssh, or sudo. It's a thought challenge with a guide, and could be a stage in a CTF challenge to get root. It's "something wrong" with the configuration chosen by a system administrator to allow "/usr/sbin/logrotate *" to be run as root without consideration of what the logrotate binary may do with certain arguments. It's just an explanation of how to exploit this situation if you find a server using this type of configuration. That's the whole basis of projects like https://gtfobins.github.io/ https://gtfobins.github.io/ and https://gtfoargs.github.io/ https://gtfoargs.github.io/. As I have seen this style of script being used with forced commands in authorized_keys, my conclusion is that the author loosely followed some online guide for restricting SSH access to certain commands and either inherited the flawed original script or made the error adapting it to the local requirements. Proper options for restricting the shell abound. From the top of my head: rssh, sshdo, PolicyKit, rbash, rush Did you actually read the article at all? If you use rbash or rshell and logrotate can be run as root, this issue still persists. The logrotate binary is the one performing these actions, not bash. Once you are passing arbitrary strings to bash as root Passing arbitrary strings to bash as root? It's about passing arbitrary arguments to logrotate.
Levitating 3y ago
There's a whole site dedicated to commands like this: https://gtfobins.github.io https://gtfobins.github.io
- skilled 3y ago
  Nice! Some previous discussions about it on HN, GTFOBins (https://news.ycombinator.com/item?id=28849101 https://news.ycombinator.com/item?id=28849101) - October 2021 (54 comments) List of Unix binaries that can be used to bypass local security restrictions (https://news.ycombinator.com/item?id=36628976 https://news.ycombinator.com/item?id=36628976) - July 2023 (99 comments) Living Off the Land in Linux (https://news.ycombinator.com/item?id=20648329 https://news.ycombinator.com/item?id=20648329) - August 2019 (35 comments)
- forgotpwd16 3y ago
  And for argument injection: https://gtfoargs.github.io https://gtfoargs.github.io & https://sonarsource.github.io/argument-injection-vectors https://sonarsource.github.io/argument-injection-vectors
cgijoe 3y ago
Let me correct that title for you: "root with a single command: sudo"

123 points by skilled 3y ago

If you can sudo, you already have root, albeit limited. It's more of an ergonomic feature to discourage users logging in as root and destroying the system, than any kind of reliable security compartmentalization. Realistically speaking, most applications you would want to allow others to run as sudo were never designed to withstand such attacks and will likely fail in the hands of a competent attacker that is free to use any command line, feed any input etc.

deleted 3y ago
[deleted]
Jenk 3y ago
> If you can sudo, you already have root, albeit limited. It's more of an ergonomic feature to discourage users logging in as root and destroying the system, than any kind of reliable security compartmentalization. I figured it was so you can identify the user who ran the command in an audit, instead of everyone just appear as "root"
- Guvante 3y ago
  Most use it like that the post uses a limited form where only certain commands can be ran.
- LinuxBender 3y ago
  I figured it was so you can identify the user who ran the command in an audit, instead of everyone just appear as "root" This goal can still be performed if auditd is enabled. The transition from non-root to root is tracked with the right rules in place. In my opinion it is best to rely on auditd and immutable after being tested rules as there are many ways to elevate privileges and many ways to improperly configure or bypass sudo. Auditd has a plugin to log directly to syslog and/or forwarded to ELK, Splunk or other tools. Auditd is also important when applications are exploited and someone then uses a privilege escalation vulnerability otherwise the person will just run it again after the machine/VM/container is re-imaged. Sudo was never intended to be a security control as much as it was to give a non sysadmin the ability to restart something or launch an on-demand process that required root or other accounts despite people using it in their documented controls. Many people will disagree with me on this as has been the case since the inception of sudo. One caveat being auditd with the most useful rules in place can get rather noisy and more to the point, costly in terms of storage and/or Splunk license. It comes down to the priorities of an organization or business.
  - Jenk 3y ago
    Yeah I meant more when folk `ssh root@host` over `su - root` But I do recall it being a lot more pleasant tracing who ran what sequence of commands, on a host used by many people in concurrent workflows, when it's sudo over su. It's also been some ~20 years since I've been in a role that required I do this so I (most probably) have forgotten a lot.
- orev 3y ago
  One of the main benefits of sudo is that nobody needs to know the root password to switch to root (like one would need when using su). The actual root password can be saved in some break glass system, and admins only need to manage their own passwords.
  - Jenk 3y ago
    That is a penny drop moment for me. You are absolutely right that that is the primary purpose.
crtasm 3y ago
> the user cannot run anything other than sudo logrotate Very limited!

jchw 3y ago

Sigh. It's disappointing to hear that this is the default in Ubuntu Server. As long as I'm understanding it, it doesn't appear to be an immediate concern, but it does demonstrate that the security design is quite a bit half-baked at least in this specific area. I don't think every Linux distribution needs to aspire to be as proactive about security as OpenBSD, but it would be nice to see better care put into features like this to make sure they're restricting capabilities as expected, with at least more than one mechanism protecting the system from compromise. Unfortunately my kneejerk reaction is to assume that most of the work on Ubuntu Server is going into development of Snap-based Ubuntu Core, wherein the security model is completely different and none of this applies, perhaps? But a ton of people deploy ordinary Ubuntu Server today, possibly more than Core... so that doesn't bode well. (OK, maybe I really do just want OpenBSD.) edit: Wait a minute. This post says "brand new", which made me think this was stock configuration. However, is it? I would feel immediately relieved, and my entire comment would be irrelevant, if that wasn't the case.

richbell 3y ago
The post doesn't do a good job explaining whether this is the stock configuration or purely a hypothetical. My initial reaction was the same as yours, but upon further reflection I get the feeling it's just a thought exercise.
- dale_glass 3y ago
  Not stock in 23.10, as far as I can tell.
- jchw 3y ago
  I'm a bit miffed that people are getting downvoted for not realizing this is not the default behavior, when I have no idea how you were supposed to gather that from reading the article. I did actually check to see (in Ubuntu 23.04) but honestly, that doesn't clear up much given that I have no idea what different installation modes of Ubuntu may yield. Yeah, it's fair enough that it completely negates all of the points to be made about distro security, but also, it's not really our fault that the article is unclear.

fuzzybear3965 3y ago

I think PolKit can be used to delegate fine-grained control to users. Which other tools are available on Linux to control users' access to fs and network resources? File permissions, systemd-nspawn?

spmurrayzzz 3y ago
> Which other tools are available on Linux to control users' access to fs and network resources selinux is the primary one that comes to mind, it definitely ticks the "fine-grained control" checkbox for sure
orange-mentor 3y ago
One could write a very small custom binary in C/C++/Rust that runs the command, and then give that binary setuid permissions. That binary can simply run a subprocess, and nothing else.
- blibble 3y ago
  you could call it "sudo"

blueflow 3y ago

sudo /usr/sbin/$SSH_ORIGINAL_COMMAND By the way: SSH_ORIGINAL_COMMAND is a command like you would give to sh -c, basically a tiny snippet of sh code. Its not an argument vector! You either need a shell to kind of eval it or parse it with wordexp(3) before you can reliably tell which executable name it refers to. Mean people might send one starting with '$(' or another expansion. Remember this is valid: ssh host '$(echo id)'

mmsc 3y ago
With the following test.sh: #!/bin/bash case "$SSH_ORIGINAL_COMMAND" in *) sudo $SSH_ORIGINAL_COMMAND ;; esac and the ssh-based restriction: command="/tmp/test.sh" $ ssh user@server 'uname > /tmp/123' uname: extra operand ‘>’ Try 'uname --help' for more information. $ ssh user@server 'uname $(ls)' uname: extra operand ‘$(ls)’ Try 'uname --help' for more information.

charcircuit 3y ago

Why does logrotate even have permission to read or write any file in /etc? When will distros take security seriously?

dale_glass 3y ago

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

xorcist 3y ago

The example contains an asterisk in the allowed commands field. That's not something you would normally do with users who would not otherwise have root privileges. There are (figuratively) an unlimited number of ways to compose commands that do arbitrary things. Security audits explode in complexity. Always list every literal command that is allowed. Make a command wrapper if necessary. (Also, never allow arbitrary environment variables.)

deleted 3y ago

[deleted]

gorkish 3y ago

I too can break into my own house when I leave a door wide open for myself. There is nothing wrong with logrotate, ubuntu, ssh, or sudo here. Once you are passing arbitrary strings to bash as root -- yeah it's gonna be game over. This reminds me of the time a pentester found an XSS vuln and spent the entire rest of the engagement stuffing a keylogger into it. Like, OK, thanks, we already understand the implications of XSS. The solution provided is suboptimal because all the focus is spent in making a good exploit demo instead of considering the root cause(s): the configuration of ssh, sudo, and the godawful shell script the author dredged up from parts unknown. As I have seen this style of script being used with forced commands in authorized_keys, my conclusion is that the author loosely followed some online guide for restricting SSH access to certain commands and either inherited the flawed original script or made the error adapting it to the local requirements. Proper options for restricting the shell abound. From the top of my head: rssh, sshdo, PolicyKit, rbash, rush

burnte 3y ago
This is what Raymond Chen describes as "being on the other side of this airtight hatchway". https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
- charcircuit 3y ago
  That is different. The user is intended to have privilege to rotate logs as root, but after the exploit the user is elevated to have full root.
mmsc 3y ago
OP here: I never said it's something wrong with logrotate, ubuntu, ssh, or sudo. It's a thought challenge with a guide, and could be a stage in a CTF challenge to get root. It's "something wrong" with the configuration chosen by a system administrator to allow "/usr/sbin/logrotate *" to be run as root without consideration of what the logrotate binary may do with certain arguments. It's just an explanation of how to exploit this situation if you find a server using this type of configuration. That's the whole basis of projects like https://gtfobins.github.io/ https://gtfobins.github.io/ and https://gtfoargs.github.io/ https://gtfoargs.github.io/. As I have seen this style of script being used with forced commands in authorized_keys, my conclusion is that the author loosely followed some online guide for restricting SSH access to certain commands and either inherited the flawed original script or made the error adapting it to the local requirements. Proper options for restricting the shell abound. From the top of my head: rssh, sshdo, PolicyKit, rbash, rush Did you actually read the article at all? If you use rbash or rshell and logrotate can be run as root, this issue still persists. The logrotate binary is the one performing these actions, not bash. Once you are passing arbitrary strings to bash as root Passing arbitrary strings to bash as root? It's about passing arbitrary arguments to logrotate.

Levitating 3y ago

There's a whole site dedicated to commands like this: https://gtfobins.github.io https://gtfobins.github.io

skilled 3y ago
Nice! Some previous discussions about it on HN, GTFOBins (https://news.ycombinator.com/item?id=28849101 https://news.ycombinator.com/item?id=28849101) - October 2021 (54 comments) List of Unix binaries that can be used to bypass local security restrictions (https://news.ycombinator.com/item?id=36628976 https://news.ycombinator.com/item?id=36628976) - July 2023 (99 comments) Living Off the Land in Linux (https://news.ycombinator.com/item?id=20648329 https://news.ycombinator.com/item?id=20648329) - August 2019 (35 comments)
forgotpwd16 3y ago
And for argument injection: https://gtfoargs.github.io https://gtfoargs.github.io & https://sonarsource.github.io/argument-injection-vectors https://sonarsource.github.io/argument-injection-vectors

cgijoe 3y ago

Let me correct that title for you: "root with a single command: sudo"