29

There are two ways I can think of doing this:

  1. On a system with sudo, by modifying /etc/sudoers.

  2. On a system without sudo (such as a Docker environment), by writing a program similar to the below and setting the setuid bit with chmod u+s. apt-get checks real uid, so a setuid call is necessary.

...
int main(int argc, char **argv) {
    char *envp[] = { ... };
    setuid(0);
    execve("/usr/bin/apt-get", argv, envp);
    return 1;
}

I have two questions:

  1. What are the potential vulnerabilities of allowing non-root users to run apt-get?
  2. My goal is to allow people to install/remove/update packages, given that apt-get lives in a custom non-system refroot and installs from a custom curated apt repository. Are there safer ways to allow non-root users to run apt-get on a system without sudo?
  • 5
    This blog post comes to mind: 0x90909090.blogspot.com/2015/07/… Apt in particular is not listed there, but I would not be expected at all if it allowed command execution somehow. Perhaps through specifying a repository on the command line (which would be under the attacker's control), perhaps there is a flag for a local deb file... and all of that is ignoring that one could remove system packages or keep packages out of date by maintaining a lock file. – Luc Jun 11 at 23:38
  • 4
    A suggestion for a safer way depends on what you want to do. Do people need to install packages? Only update packages? Or do you merely just want an audit trail? What's the goal here? – Luc Jun 11 at 23:39
  • 7
    If users need to be able to remove packages, they can always kill the system by removing system packages. A safer way might be to write a script that accepts a package name, filters and escapes it, and calls apt install / upgrade. For removing, perhaps that script could keep track of packages the user installed and allow removing only those? It's is not trivial to make certain something custom like this is secure: if this is important, you might want to get someone to test the solution. Or perhaps there are solutions out there that I haven't heard of (I haven't ducked/googled it). – Luc Jun 11 at 23:59
  • 1
    Users should almost certainly be creating containers instead of doing...whatever this is. Look into rootless container solutions such as podman. – Michael Hampton Jun 12 at 19:54
  • 1
    While the negative answers are all good and correct, in principle what OP wants can be done securely, by disallowing anything except request of a new package in the preexisting trusted repo set. That still has threats like causing an insecure daemon to get started with privileges, but it's closer to reasonable than allowing arbitrary apt-get commands. – R.. GitHub STOP HELPING ICE Jun 13 at 6:23
65
apt-get update -o APT::Update::Pre-Invoke::=/bin/sh

From GTFOBins

This gives you a root shell on the system. No creating packages and adding fake repos; this will give the user who runs this command easy and simple access to root.

So, in answer to your question, you are effectively giving root to every user who has access to this binary. If you are willing to do this, then you might as well just give them sudo access or the root password.

| improve this answer | |
  • 2
    This really should be a accepted answer, IMO; it's a much more elegant solution that more clearly answers the question of "what can a user do with apt. You don't even need a sources list, a package file, Internet access, or anything else... it just instantly drops you into a shell. – CBHacking Jun 14 at 0:01
  • @CBHacking I changed it to accepted answer per your suggestion - thanks. This is probably the answer that most people would be interested in, though it does not address how to mitigate this risk, as Arminius's answer below does. security.stackexchange.com/a/233162/236489 – kzl Jun 14 at 0:49
  • 2
    @CBHacking Thank you very much! Your exploit is more applicable in the real world from my experience: I have seen quite a few management panels that allow users to change repos and install packages, but do not expose the actual apt-get command itself. – Cyclic3 Jun 14 at 16:41
  • Providing them with a root shell (or system access to apt-get) is the most stupid thing one could do. When this is some classroom or similar environment, rest assured there is at least one guy able to use it. What exactly is the point of having a security system, only to undermine it's authority? If you go any of these two ways, rest assured that bothered students might understand it as: the challenge is on. Such a configuration should better be kept in an isolated network segment. – Martin Zeitler Jun 15 at 15:17
46

You say you're using a "custom curated apt repository" but there's no way to enforce that. Any user that can invoke apt can specify their own source list, for example apt install root-backdoor -o Dir::Etc::Sourcelist=~/apt/my-own-sources.list. This can be done for all the other config settings as well, which means you can also have apt overwrite arbitrary files with content you choose (e.g. by setting the cache directory for retrieved packages).

Packages can (and often do) execute arbitrary commands during installation. Since the attacker can control the sourcelist, they can create malicious packages that either give unprivileged users a privileged backdoor, or simply execute (as root) any command the attacker desires as part of the "install" process.

apt is absolutely not a safe program to let people run (with root privileges) if you want to prevent them from running arbitrary code with root privileges.

EDIT: I want to call attention to this answer as a much cleaner way to get arbitrary execution (as root) out of apt.

| improve this answer | |
  • 1
    Thanks for the answer! I appreciate your insight. Would preventing users from specifying their own sourcelists (e.g. by making a wrapper that specifically calls apt-get install -- <packages> with root privileges) be sufficient to prevent users from installing arbitrary packages (and thus prevent arbitrary code execution as root)? – kzl Jun 12 at 9:16
  • 6
    @kzl: You don't need to "make a wrapper," sudoers(5) already supports that sort of thing natively. However, I cannot recommend that because apt-get allows the user to specify the version of a package, so an attacker could downgrade a package to enable a security vulnerability. – Kevin Jun 12 at 16:32
  • 5
    Note, that since apt ~1.2 you can install packages directly without referencing a repository, using ./ to point to a deb file. – Braiam Jun 12 at 20:36
  • 1
    @Kevin Thanks for the reply. The constraints I listed above were 1) no sudo 2) custom refroot (non-system apt-get) and 3) custom curated apt repository. Armenius's answer below, suggesting a whitelist, addresses this question. security.stackexchange.com/a/233162/236489 – kzl Jun 13 at 10:11
10

Would preventing users from specifying their own sourcelists (e.g. by making a wrapper that specifically calls apt-get install -- <packages> with root privileges) be sufficient to prevent users from installing arbitrary packages (and thus prevent arbitrary code execution as root)?

Nope, apt-get can also pick up packages from paths. An attacker could create a malicious .deb package that patches /etc/<something> for root access upon installation via e.g. apt-get install -- /path/to/foo.deb.

You might be able to make it work securely if your custom wrapper script only accepts what's on a whitelist of package names, and if you can guarantee the packages are only picked up from your sources list - and can never be supplied via custom configs, environment variables, etc.

| improve this answer | |
  • Thanks, this is also very helpful to me. I wish I could accept multiple answers. – kzl Jun 12 at 17:10
7
  1. What are the potential vulnerabilities of allowing non-root users to run apt-get?

Full system compromise; Persistent privilege escalation from the user allowed to run apt-get to root.

  1. My goal is to allow people to install/remove/update packages, given that apt-get lives in a custom non-system refroot and installs from a custom curated apt repository. Are there safer ways to allow non-root users to run apt-get on a system without sudo?

As explained here, you cannot guarantee this.

| improve this answer | |
  • Of course one can guarantee this, while not undermining the security system. – Martin Zeitler Jun 15 at 15:46
0

I actually strongly disagree with the answers so far, that's why I've added another perspective. My solution approach is roughly based upon one of @ Cyclic3's comments, but amended as required.


The actual attack vector:

When there already is a root shell, why deliver the payload by package manager? apt-get is not the main problem (as it is not essential to install software), but inappropriate software provisioning by unauthorized users is, which should better request the packages to be installed for them. Letting them surf the internet with a root account would be about the same idiocy, when looking at it from a security perspective.

On a side note, independent from apt-get, they always could wget some 0-day exploit, which performs privilege escalation. This would require white-listing destinations on the firewall to prevent, which does not amuse users in general, because this shuts down all of their random internet usage (which may also include job-related web research). This aspect is often being completely ignored.


One simple self-service solution:

Since nobody wants to play the server serf ...why not write a simple web UI, which let's them select the packages and then provision them to the machine they've requested from? Then just ssh into and run apt-get. This is a method of white-listing (I only know yum in detail, which does support black-listing but not white-listing). In general, this is a very simple way to almost guarantee zero risk, as the root shell & apt-get install are being kept outside of their reach. When triggering this as a batch job from the root crontab (assuming the root SSH keys match on all machines), one does not even have to switch the user account to do so. Just push a notify when done and they'll be amazed.

As I used to say, when working in user support: What they cannot click, they cannot mess up.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.