Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

root with a single command: sudo logrotate

joshua.hu

Post reply on HN
Print view View original

41–50 of 51 posts

Re: root with a single command: sudo logrotate

#41

Post by [deleted] »

wgjordan wrote: post #34
jchw wrote: post #26

Earlier quoted context omitted.

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 point…

"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]

Re: root with a single command: sudo logrotate

#42

Post by charcircuit »

burnte wrote: post #25
gorkish wrote: post #24

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 o…

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

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.

Re: root with a single command: sudo logrotate

#43

Post by rjh29 »

fragmede wrote: post #29
dale_glass wrote: post #11

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 ra…

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

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.

Re: root with a single command: sudo logrotate

#44

Post by jbstack »

jchw wrote: post #5

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…

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?

Re: root with a single command: sudo logrotate

#45

Post by phone8675309 »

jbstack wrote: post #44
jchw wrote: post #5

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…

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 r…

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?

Re: root with a single command: sudo logrotate

#46

Post by singlow »

mmsc wrote: post #35
gorkish wrote: post #24

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 o…

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…

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 .

Re: root with a single command: sudo logrotate

#47

Post by jchw »

jbstack wrote: post #44
jchw wrote: post #5

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…

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 r…

The missing context is that I misinterpreted the article to mean that this sudoers rule was here by default. It's not... which makes this an entirely different story. I had an inkling that this was the case, but I was too busy to verify personally and by the time I had actually realized, it was too late to delete/edit the comment.

Which makes this whole thing annoying. The article shouldn't be flagged, because there's nothing technically wrong with it. I just found it confusing, and I wonder if maybe part of the reason why it was deemed interesting enough to be propelled to the frontpage is due to similar misinterpretation. (After all, I would find it VERY interesting if this WAS a default.)

Re: root with a single command: sudo logrotate

#48

Post by gorkish »

mmsc wrote: post #35
gorkish wrote: post #24

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 o…

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…

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

Re: root with a single command: sudo logrotate

#49

Post by mmsc »

gorkish wrote: post #48
mmsc wrote: post #35

Earlier quoted context omitted.

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…

> 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 ca…

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

Re: root with a single command: sudo logrotate

#50

Post by gorkish »

mmsc wrote: post #49
gorkish wrote: post #48

Earlier quoted context omitted.

> 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 ca…

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…

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.
Post reply on HN