Hacker News Reader

Comment by gumballindie | Hacker News Reader

I am not entirely sure what to make of this list. Naturally if a binary or script are given sudo rights then that will elevate privileges, and by default anything should be considered as potentially vulnerable, malicious or misuse-able, particularity tools that can write or read files or execute other binaries or scripts, making this list ... obvious?

View on HN

No. If you have a program that does a particular task you may be inclined to let users run it with sudo rights. This list shows how these rights can be used to - for example - read arbitrary files and show them to the unprivileged user.

The "mail" entry is a good example:

https://gtfobins.github.io/gtfobins/mail/

Did you know you can get a shell easily by letting users use "mail"?

I still don't get the issue, that's going to be true for any program you run, unless it explicitly check if it's running using sudo. That however assumes that the program should never run with elevated privileges, which may be equally wrong.

Unless a program is designed for a very specific task and should always run as a given user, I'd argue that having it check privileges is both surprising and wrong. It's not the job of the individual programs to check permissions.

Edit: I see what you're saying. Having mail being a program that a user is allowed to run with sudo, it basically the equivalent for giving them a sudo access to a shell, because mail can spawn a shell, but with the same privileges as the mail command had.

The lesson here is just don't rely on sudo to give restricted permissions. I have been a Linux admin for 6 years and never had to do this, and pretty much every use case I've heard of has easily solved with a better method. If you need to give people access to certain files, make a group. If you need them to have certain capabilities of another user, let them switch to that user but not run privileged commands.

> The lesson here is just don't rely on sudo to give restricted permissions

But that is one of the headline features of sudo! For example it is the first item on its feature list here https://www.sudo.ws/about/intro/

And sudo does its job, executing only that program as root. If the sysadmin turns out to not want users to be able to use all features of the program as root, that is their responsibility. Sudo is just a command executor, not a sandbox

It's essentially the same as setuid, which has a well-deserved reputation for being a very dangerous tool if used on a program without thorough scrutiny

> > But that is one of the headline features of sudo! For example it is the first item on its feature list here https://www.sudo.ws/about/intro/

> The ability to restrict the commands a user may run on a per-host basis.

Is it? sudo is literally "substitute user [and] do" and it does exactly that: runs a certain program in the context of certain user. The only permissions sudo is concerned with is which user on what host is to be allowed to switch to which user, i.e. invocation permissions. Sudo simply does not care what permissions user+program combo may have.

Without additional hardening, in unix-like systems local user account is the capability boundary and `sudo` is a tool to escape those boundaries. Sudo is just doing what it was designed to do here

> The only permissions sudo is concerned with is which user on what host is to be allowed to switch to which user

And, critically, what commands that user is allowed to execute. That is pretty crucial aspect of sudos use-case. The intent is to have ability to restrict what code the user is allowed to run as the target user, and not allow arbitrary code execution.

> The intent is to have ability to restrict what code the user is allowed to run as the target user, and not allow arbitrary code execution.

No, that's not the intent. The intent is at best to limit binaries that are being run, but actual implementation is to limit invocation string.

> That is pretty crucial aspect of sudos use-case.

Agreed. Unless you 100% vet and control all sudo`able binaries in your system (probably 99.9% sysadmins don't), it is pretty crucial to understand that effectively sudo grants arbitrary code execution under x user permissions.

That's by design. Executed code runs "natively", not in any form of sandbox, without any restrictions on permissions besides local user account. Some applications are explicitly designed to allow arbitrary code execution, some applications may have bugs allowing arbitrary code execution.

Sudo is insecure by design. The main use of sudo is to protect against willingly cooperating users.

If user can run _only_ mail he won't be able to normally run sh. Of course you need to play a bit with permisions.

One of the listed binaries is `cat` and that `sudo cat file` is problematic because "it may be used to do privileged reads or disclose files outside a restricted file system."

Like, duh, that is what `cat` does. It's not the problem, it's the `sudo` is the problem. WAI?

I think the listing of "non-obvious" functionality is interesting. For instance, would you have expected to be able to use gimp to get a reverse shell? Would you have thought of using lp as an exfil tool? Or just bashing your exfil into base64-encoded whois requests?

Living off the land is always a fascinating topic, at any level.

In a previous role we had some access to production web servers but definitely not root access. Except for sudo access to vim which was widely abused as a way of getting a root shell when necessary. Fun times.

If it can perform arbitrary file writes (or even reads) then sure, I'm not at all surprised. A program with root access to the filesystem should be assumed to be a latent portal to arbitrary root execution, unless very thoroughly proven otherwise

There's a reason setuid is considered such a dangerous bit, and why "get root via this secure-looking setuid program" is a common exercise in computer security courses. Gotta look out for path traversals, TOCTOU, untrusted environment variables etc.

Part of the logical problem is the clash of security models. The program may well have been written to guard against untrusted input, but considers that to only be input files, not the commands the user gives. On the basis that "well if the user wants to hurt themselves by writing to /etc/shadow then it's their choice". But the situation in practice is a confused deputy problem, where the sysadmin wants the user to be restricted (despite the process not being restricted) but the program doesn't "know"

It was originally compiled for penetration testers/offensive security people. You land on a box with low priveleges, check around for commonly misconfigured binaries, and get root.

For the sake of this argument, lets suppose you run a git server. Users $(ssh) into your host and are only allowed to execute the command $(git), for instance for submitting a copy of their repository. You think: It's fine, the user cannot mess up anything on this system since he is restricted to run git.

Allowing any user $(git) access is as powerful as providing the user a $(bash)

Suppose you've got a build pipeline. The pipeline executes $(zip) at some point. Executing zip is as powerful as providing any of the pipelines users a $(bash).

....except it isn't if you set up the git user with authorized_keys (user public key), and set the login shell for the system git user to nologin.

Congratulations. Git without bash. Unless there's another escape I'm not aware of.

And that is the whole idea of having a list like this. These tools by default have some capabilities which can easily be executable. You need to mitigate each of those. Because they are insecure by default.

Reply on news.ycombinator.com