Today I learned that unprivileged users can run "systemctl show servicename" to see all the environment variables set in the .service file.

This means if someone sets their AWS_SECRET_ACCESS_KEY in there (or any other secret), it can be read by an attacker even if they don't have read privileges to read the .service file.

For defenders, use EnvironmentFile= instead of Environment= and as long as your environment file has the correct privileges, you will be fine on this front.

I didn't specifically mention it before, but the assumption here is that the attacker can run commands on your server as an unprivileged user. So they did something like exploit this:

The impact is that they may then be able to elevate privileges or pivot to other parts of the infrastructure using any secrets they find.

@adam Don't you need to be in a specific group (wheel for example)? Because you can't use journalctl without this for example.

@breizh Nope, anyone can use journalctl, it's just certain commands that require higher privs. For example, "status" works just fine as a regular user. It seems that if one is just looking around and not restarting/reloading things, a normal user is sufficient.

@breizh Oh wait, you said journalctl, not systemctl. Yeah, as far as I know journalctl requires root access (or possibly some other level of non-standard priv).

@adam Yeah, I was assu|ing that systemctl is maybe the same as journalctl. The fact that anyone can see the status of every other services is a bit… strange. Even more when the logs needs some other privileges…

systemd and its consequences have been a disaster for the human race

@adam Isn't systemd great? Bravo Lennart Poettering! Superior autistic German programming.
@adam I really wonder how many *nix machines out there in the world actually allow shell login to people who shouldn't have root access.

I guess in some corporations it might be used that way, but most often you either own the thing, or it implements a service offered to you so you only interact with it via APIs.

@taylan I've seen some places where administrators are not allowed to be root under any circumstances (and that was technically enforced, not just a company rule), but I agree that it's rare.

In either case, it could allow an unprivileged internet attacker who gained remote code execution to elevate from an untrusted user (apache, www-data, etc.)

Come to think of it, looking at service info might be a good thing to alert on. Seems like an uncommon command

Sign in to participate in the conversation

Mostly hackers, mostly in Urbana, IL, talking to each other & our friends on like-minded servers without giving our personal data to the marketing machine.