3 ms·

> 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 expansio

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

mmsc 3y ago
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).
- gorkish 3y ago
  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.
  - mmsc 3y ago
    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/11cd746a0efb0279511238cc92d9c4d6eef191f6 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.

mmsc 3y ago

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).

gorkish 3y ago
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.
- mmsc 3y ago
  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/11cd746a0efb0279511238cc92d9c4d6eef191f6 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.