[HN Gopher] root with a single command: sudo logrotate
___________________________________________________________________
root with a single command: sudo logrotate
Author : skilled
Score : 105 points
Date : 2023-10-03 12:31 UTC (10 hours ago)
(HTM) web link (joshua.hu)
(TXT) w3m dump (joshua.hu)
| jchw wrote:
| 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.
| jbstack wrote:
| I don't think it's really fair to say that this has anything to
| do with Ubuntu Server at all, or that it reflects on Ubuntu's
| security. After all, this issue only occurs if you decide to
| enable a sudo command for a user and, if you're doing that,
| it's on you to understand the risks; risks which you'd have to
| take into consideration regardless of the distro.
|
| For example, if I told you that I've identified a security risk
| in giving sudo access to a user for the command "rm -rf /",
| would you conclude that Ubuntu is an insecure distro?
| phone8675309 wrote:
| If Ubuntu Server shipped with a configuration out of the box
| that let a user run 'sudo rm -rf /' _by default_ then yes, I
| would conclude that Ubuntu is an insecure distro.
|
| Would you not?
| richbell wrote:
| 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.
| jchw wrote:
| 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.
| c22 wrote:
| People don't get downvoted. Posts get downvoted, sometimes
| for inaccuracy. Tough break.
| jchw wrote:
| Yeah, nobody really cares about the dumb number next to
| the posts anyway. What's actually annoying is being
| misunderstood, because the article seems to have produced
| mainly two comments:
|
| 1. "That's a pretty bad default." (it would be, after
| all.)
|
| 2. "That scenario is quite contrived."
|
| The former is just a misunderstanding, but I think the
| reason why it happened is simple: the article is written
| in a way that doesn't really make it clear whether it is
| a condition they added or a condition they observed. On
| the other hand, giving someone the benefit of the doubt,
| I personally assumed that it was unlikely someone would
| intentionally add this, since it's, well, you know...
| Quite contrived.
|
| I think I understand the purpose now (it's intentionally
| contrived, merely for practice with probably a less
| contrived setup in the future) and I hate to be overly
| harsh on the article, since it's perfectly fine for
| someone's personal blog, but when I see something on HN's
| frontpage, I generally have some expectation for how
| interesting it is. After all, plenty of genuinely very
| interesting things die in new, why would this make it
| out? Alas, sometimes it just happens.
| TrickardRixx wrote:
| My takeaway from reading all this is that there is no
| reason this article should have made it to the front page
| of HN, as all it did was create confusion and burn 10
| minutes of my time trying to clarify what was happening.
| Nothing about this article or the discussion it has
| created is interesting, just frustrating.
| wgjordan wrote:
| "Please don't comment about the voting on comments. It
| never does any good, and it makes boring reading."
|
| https://news.ycombinator.com/newsguidelines.html
|
| It's also a bit disingenuous to make a third-person
| reference to your own post ('people are getting
| downvoted').
| [deleted]
| dale_glass wrote:
| Not stock in 23.10, as far as I can tell.
| fuzzybear3965 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| you could call it "sudo"
| gorkish wrote:
| 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 wrote:
| This is what Raymond Chen describes as "being on the other side
| of this airtight hatchway".
| https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
| charcircuit wrote:
| 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 wrote:
| 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/ and
| 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.
| singlow wrote:
| Your opening line can easily be interpreted as stating that
| the stock 22.04 server install has an account with this
| privilege:
|
| > The scenario is this: a brand new Ubuntu 22.04 server has
| an account which is restricted to running sudo logrotate _.
|
| It might have been better to say:
|
| > The scenario is this: take a brand new Ubuntu 22.04 server
| and create an account which is restricted to running sudo
| logrotate _.
| Retr0id wrote:
| last time I checked (several years ago), rbash is full of
| security holes, and while those may have been patched now I
| really would not trust it to lock down a privileged shell
| session.
| charcircuit wrote:
| Why does logrotate even have permission to read or write any file
| in /etc?
|
| When will distros take security seriously?
| cgijoe wrote:
| Let me correct that title for you: "root with a single command:
| sudo"
| blueflow wrote:
| 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 wrote:
| 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.
| xorcist wrote:
| 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.)
| cornholio wrote:
| 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.
| crtasm wrote:
| > the user cannot run anything other than sudo logrotate
|
| Very limited!
| [deleted]
| Jenk wrote:
| > 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 wrote:
| Most use it like that the post uses a limited form where only
| certain commands can be ran.
| LinuxBender wrote:
| _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 wrote:
| 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 wrote:
| 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 wrote:
| That is a penny drop moment for me. You are absolutely
| right that that is the primary purpose.
| Levitating wrote:
| There's a whole site dedicated to commands like this:
|
| https://gtfobins.github.io
| skilled wrote:
| Nice!
|
| Some previous discussions about it on HN,
|
| _GTFOBins_ (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) - July 2023 (99
| comments)
|
| _Living Off the Land in Linux_
| (https://news.ycombinator.com/item?id=20648329) - August 2019
| (35 comments)
| forgotpwd16 wrote:
| And for argument injection: https://gtfoargs.github.io &
| https://sonarsource.github.io/argument-injection-vectors
| [deleted]
| dale_glass wrote:
| 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.
| fullspectrumdev wrote:
| 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 wrote:
| > 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
| jchw wrote:
| 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-10-03 23:01 UTC)