Comment by mmsc | Hacker News Reader

Comment by mmsc | Hacker News Reader

Parent Full thread

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.

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 .

> Passing arbitrary strings to bash as root? It's about passing arbitrary arguments to logrotate.

No it's not; you are just exploiting bash's argument expansion in a badly written script you wrote to feed some additional shell stuff to bash /after/ the logrotate command. You could have done this as easily with 'sudo /bin/false' in there. Yes, you made logrotate do some things, but that's just a red herring in this case. The entire security issue is with the dumb bash script; it has nothing to do with anything else.

Nothing in ubuntu's documentation anywhere tells you to "use this insecure bash script" to restrict a user to running a single command. It doesn't tell you to give global passwordless sudo privileges to the user that you want to do this either. Your configuration is cobbled from suggestions you found online and proceeded to implement incompletely/poorly.

  you are just exploiting bash's argument expansion

/etc/sudoers does not use "bash's argument expansion".

  to feed some additional shell stuff to bash /after/ the logrotate command

Wrong. It's clearly about a sudoers rule which uses wildcards (see sudoers(5) "Wildcards" section.

  The entire security issue is with the dumb bash script; it has nothing to do with anything else.

The security issue is that a sudoers(5) rule allows a nonprivliged user to run logrotate with any arguments, and as it turns out, those arguments can be used to achieve root.

  It doesn't tell you to give global passwordless sudo privileges

A /etc/sudoers rule of

  user ALL=(ALL:ALL) NOPASSWD: /usr/sbin/logrotate \*

does not provide the user with "global passwordless sudo privileges".

rtfm of sudoers(5).

It's ok to be wrong; it's not ok to change your original writeup and continue to insist that you have been right all along. To the extent there is a security issue here, it does not lie with any of the software in question. You have not exploited sudo, ssh, bash, logrotate, wget, or anything else in the system.

The failure is instead a systemic one that allowed an ineffective and insecure configuration to be applied to a system. Some process (or maybe no defined process) 1) led "the administrator" of the system in question to do it and 2) didn't provide any verification or review of the configuration change.

  > rtfm of sudoers(5).

OK; it literally tells you to watch your ass with a glob and to do your commandline security elsewhere. Then it gives an actual practical example of argument stuffing:

  Wildcards in command line arguments should be used with care.

  Command line arguments are matched as a single, concatenated string.  This mean a wildcard character such as ‘?’ or ‘*’ will match across word boundaries, which may be unexpected.  For example, while a sudoers entry like:

        %operator ALL = /bin/cat /var/log/messages*

    will allow command like:

        $ sudo cat /var/log/messages.1

    It will also allow:

        $ sudo cat /var/log/messages /etc/shadow

    which is probably not what was intended.  In most cases it is better to do command line processing outside of the sudoers file in a scripting language.

It's ok to be wrong; it's not ok to change your original writeup and continue to insist that you have been right all along

I removed the section about the bash restriction (which was not particularly important), but the content of the post did not change: https://github.com/MegaManSec/JoshuaHu/commit/11cd746a0efb02...

The failure is instead a systemic one that allowed an ineffective and insecure configuration to be applied to a system. Some process (or maybe no defined process) 1) led "the administrator" of the system in question to do it and 2) didn't provide any verification or review of the configuration change.

Almost as if the post is therefore detailing _how_ it is an ineffective and an insecure configuration.

Reply on news.ycombinator.com