Hacker News Reader

Comment by StreamBright | Hacker News Reader

Some admins allow only certain command to be executed with sudo vs root can execute anything with root.

I have never seen anyone implement such a policy for sysadmins that actually prevents an attacker from running arbitrary commands. As soon as you permit running e.g. vi on some file, you can just shell out from vi. Or if you can sudo apt-get install, you can downgrade a package to a vulnerable version and then exploit it. Or if you can sudo tcpdump, you can write a dump file to /etc/cron.d and send a valid cron command surrounded by newlines over the network. Or lots of other things.

sudo is useful for allowing generally non-root users to run specific commands or better yet specific scripts (that they can't write to) with elevated privileges - e.g., letting someone "sudo systemctl restart apache2" but nothing else. But it's not particularly useful for auditing people that you want to have mostly-full control over the machine. It can keep honest people honest, sure, but so can .bash_history.

10+ years ago I was setting up a new web server, Apache running on a Linux box.

I was not in the sysadmin team, I was in the web team, so I was not allowed root access, even though the box belonged to the web team.

I asked for root access (via sudo) so I could do stuff like restart Apache.

The manager of the sysadmin team said no way was I getting full access to root, but I could get sudo to run specific commands.

So one of the sysadmins wrote a helper script to do the things I needed, and I could use sudo to run that script (and that script alone) as root.

I told him, it wasn't secure, I could use his helper script to get full root access. He challenged me to prove it.

So I wrote a program which dropped a setuid root shell in my home directory. I used the CustomLog directive in Apache to pipe Apache's logs to that program. Then I used his helper script to restart Apache.

When Apache started, it ran my program as root. I then used the setuid binary it had dropped to become root, and created a file in the sysadmin's home directory to prove it.

When I showed this to the sysadmin, he decided to abandon the helper script. Instead, he just told me the root password.

Shouldn't apache have been running under the "apache" user instead of root?

Apache starts as root so it can bind ports 80 and 443, then switches to the apache user. But the logging subsystem starts before the setuid to apache, so a piped CustomLog binary runs as root.

More secure options would be to use CAP_NET_BIND_SERVICE instead of root, or to make Apache bind an unprivileged port and then use something like iptables (or an external load balancer) to redirect 80/443 to the privileged ports. But, for reasons I can't quite recall (it was 10+ years ago) we didn't take up any of those more secure options.

When the binary in question is setuid, it doesn't matter what user runs it. It'll run as the owner and group of the file itself.

The setuid binary was created (indirectly) by the Apache CustomLog directive, which is able to spawn programs to use as log targets. So it matters which user Apache runs as, because that controls which user creates the setuid binary and thereby which privileges you can gain.

Rereading the comment it also seems more like Apache is starting something that can become root somehow, I really don't think it is implied Apache is running as root.

Apache usually starts up as root so it can do setup that requires root, and then drops privileges to a user/group specified in Apache configuration. Most commonly the required setup is just binding to privileged ports, but one of the supported setup steps is opening log pipes. See the security note here:

http://httpd.apache.org/docs/current/mod/mod_log_config.html...

By default, only root can bind to ports 80 and 443. You can change this policy, but that's considered unsecure because then any program can bind to the so called "privileged ports."

You can be more specific than that and allow only a specific user/program to bind a specific privileged port. This is accomplished with a combination of SELinux and the capabilities API in 2.6.24 and newer.

Even if you do that, I think Apache still starts as root to do things like open SSL certificates and log files (and logging configuration is the thing exploited here). Is there a common config - e.g. an initscript / systemd unit on an SELinux distro - that starts Apache as a dedicated user?

I know Apache supports being started as an unprivileged user (I do this myself a lot when I need something a little more featureful than SimpleHTTPServer) but my impression was that that's not very common for production deployments.

Or alternatively, rewrite incoming traffic with iptables, https://www.cyberciti.biz/faq/linux-port-redirection-with-ip...

On macOS an administrator (someone in the admin group) cannot create, delete, or move files in the system domain. That makes it harder to completely fuck up the computer, but as you say it won't really stop an attacker from running almost any arbitrary command.

Hopefully all admins does that. Never allow a user to run any command if you intend for them to run just one.

SSH public keys have the exact same feature however. Look at "command=" under "Authorized Keys File Format" in the man page. This is a good idea for batch jobs that uses SSH to execute on remote machines.

With SSH keys you even have the option of limiting keys not just to certain commands but to certain IP addresses. By limiting the SSH keys you also don't have to give your keys access to an unprivileged shell where you don't need it.

Reply on news.ycombinator.com