Lots of "use of privileges results in use of privileges"

[jkaivo]

There are a lot of things listed here that are examples of "use of privileges results in use of privileges". As an example, your listing for cat includes:

File read - "It reads data from files," - It sure does! "it may be used to do privileged reads" - Iff the parent process is privileged, in which case, the cat (no pun intended) is out of the bag. "or disclose files outside a restricted file system." - What does that even mean?

This applies to all instances of "File read", not just cat.

SUID - "It runs with the SUID bit set" - Not on my box. Not any anybody's box (within experimental error). "This example creates a local SUID copy of the binary and runs it to maintain elevated privileges." - If you have the capability to add SUID to cat, you don't need to add SUID to cat.

This applies to all instances of "SUID", not just cat.

Sudo - "It runs in privileged context and may be used to access the file system, escalate or maintain access with elevated privileges if enabled on sudo." - That's literally what sudo is designed to do. Running sudo results in elevated privileges, by design.

This applies to all instances of "Sudo", not just cat.

[cyrus-and]

"It reads data from files," - It sure does!

There are several examples that are a bit of a stretch but we added them anyway for the sake of completeness,cat is one of those.

"or disclose files outside a restricted file system." - What does that even mean?

One possible scenario is also, for example, one web application that exposes one endpoint that uses one of the listed binaries where some form of argument injection is possible, "restricted file system" is an attempt to keep it general. A better wording can be used admittedly...

"It runs with the SUID bit set" - Not on my box. Not any anybody's box (within experimental error).

This means, it can run with the SUID but set, i.e., it will not drop privileges. Ad hoc solution may include uncommon binaries with the SUID bit set.

"This example creates a local SUID copy of the binary and runs it to maintain elevated privileges." - If you have the capability to add SUID to cat, you don't need to add SUID to cat.

Obviously... this is just a convenience command to test the SUID behaviour of the binary locally. The idea is: if you find a SUID version of <binary> then you can...

"It runs in privileged context and may be used to access the file system, escalate or maintain access with elevated privileges if enabled on sudo." - That's literally what sudo is designed to do. Running sudo results in elevated privileges, by design.

Similar to the above: if you find that you're allowed to run <binary> via sudo then you can... And that's basically always the case.

---

So what's the issue here? What's the question exactly?

[kbknapp]

I'm not the OP, but share the OP's concerns. This project is a great idea, so it'd be great to get the real issues front and center, or at least highlight them better.

orib on Lobsters said it better than I can in their comment

[..] listing ‘cat’ as a program that when run with the suid bit set, will read privileged files is.. erm.. noise. ‘It runs with elevated privileges under sudo’ is also similarly applicable to basically everything. And as a result, programs that give surprising shell access, like patch(1), which can invoke ed(1), which has the ability to filter text through the shell, may go unnoticed in this list, when they should be ringing alarm bells.

I wouldn't be in favor of out-right removing the "noise" binaries, as you're correct they could be an issue. Perhaps there is a better way to tag/display them so they can be easily filtered, or stand out from more serious vulnerabilities?

[epinna]

@kbknapp

I think the fallacy here is considering this a list of "vulnerabilities", while it is just a collection of legitimate functions that could be used legitimately or less. It's written in the project readme. It's to the user to filter depending or what's his need.

@jkaivo

SUID - "It runs with the SUID bit set" - Not on my box. Not any anybody's box (within experimental error). "This example creates a local SUID copy of the binary and runs it to maintain elevated privileges." - If you have the capability to add SUID to cat, you don't need to add SUID to cat.

As @cyrus-and said, it just means it doesn't drop the privileges when SUID. The main audience are pentester/red teamer who want to backdoor the binary to maintain elevated privileges (and threat hunters trying to catch em). I agree it can be phrased clearly, we'll do that.

"or disclose files outside a restricted file system." - What does that even mean?

If you are on a restricted shell e.g. bash --restricted bound on a specific folder with a small subset of callable binaries, it is good to know that some of those binaries (including the boring cat) can be used to interact with outside the restricted filesystem to try the break out. That's even in the project's name pun in the readme: "can be abused to get the f**k break out restricted shells".

[roman-mueller]

I think the use case of the repository should be made clearer.

This applies to all instances of "File read", not just cat.

This applies to all instances of "Sudo", not just cat.

To show you a valid use case here, I primarily use this repository when I analyze the configuration of hosts and more specific sudo rules.
It's a great resource to point out that giving sudo rights to date is not only allowing that account to change the time (for whatever crazy reason that may be needed for) but also allows that user to read /etc/shadow.
I wouldn't call that a vulnerability, but it's certainly not noise either.
And exactly for that those sections make sense.

[NightMachinery]

It would also be good if you provide some copy-pasteable examples of the attacks. For example, I looked at the less page, and tried:

eva@lilf ~
❯ LESS= VISUAL="/bin/sh -c '/bin/sh'" less /etc/profile
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

    # The file bash.bashrc already sets the default PS1.
      PS1='$ '
    fi
  done
  unset i
fi

eva@lilf ~
❯ less /etc/profile
!/bin/sh

eva@lilf ~
❯ less !/bin/sh
zsh: event not found: /bin/sh

eva@lilf ~
❯ LESS= VISUAL="/bin/sh -c '/bin/sh'" less /etc/profile

eva@lilf ~
❯ less 'less /etc/profile
!/bin/sh'
less /etc/profile
!/bin/sh: No such file or directory

eva@lilf ~
❯ less '!/bin/sh'                                                                                                            1
!/bin/sh: No such file or directory

eva@lilf ~
❯ less '/etc/profile                                                                                                         1
… quote ❯ !/bin/sh'
/etc/profile
!/bin/sh: No such file or directory

eva@lilf ~
❯ less '/etc/profile !/bin/sh'                                                                                               1
/etc/profile !/bin/sh: No such file or directory

None of which opened a shell.

[roman-mueller]

None of which opened a shell.

less is a interactive program, for the first example on that page run less /etc/profile then in the spawned less paste !/bin/sh and press enter.
Could be better documented, but also sort of off-topic here.

[cyrus-and]

It would also be good if you provide some copy-pasteable examples of the attacks.

@NightMachinary This is offtopic... but they are, in most if not all the cases, the only exception is when there is tome timing issue and when you paste the whole code you're feeding it too fast. In general the terminal cannot distinguish pasted and typed text.

The less examples works fine, if you paste the following in a terminal:

VISUAL="/bin/sh -c '/bin/sh'" less /etc/profile
v

It will pop a shell:

user@playground:~$ VISUAL="/bin/sh -c '/bin/sh'" less /etc/profile
$

Sometimes you just need a trailing newline (return) to make them work.

[cyrus-and]

@NightMachinary OK I see you're using zsh... just use (Ba)sh or type/paste each line separately, for example:

1. VISUAL="/bin/sh -c '/bin/sh'" less /etc/profile (press enter)
2. v

[jkaivo]

As others have mentioned, it adds a lot of noise to the signal on this page. Any program with the SUID bit is a potential route to escalation or escape. Listing every program that could possibly have SUID set is not helpful. Any access to sudo is a potential vulnerability. Those generic warnings should be put somewhere else to be useful, so the list of programs can focus on things that might actually be surprising (like the fact that patch can be made into a front-end for ed scripting, which in turn can run arbitrary commands).

[cyrus-and]

Any program with the SUID bit is a potential route to escalation or escape.

Well, kind of... that's the point, there are programs that usually ship and are perfectly safe to exist as SUID binaries, e.g., passwd, sudo, newgrp, ping, mount, etc.

Those generic warnings should be put somewhere else to be useful

But our goal is not to warn people, nor our target users are sysadmins; yet they can also make good use of this resource by playing the role of the attacker, as usually happens.

GTFOBins can be a tool where you lookup the SUID binaries that you find to see if you can make something out of them. (Actually there are third-party tools that do exactly that, but I cannot recall their name.) Same goes for Sudo rules as @roman-mueller pointed out.

To put it in other words, we could've also omitted the table in the home page and only provide a direct lookup to the binaries, there's really no use in walking the list manually. But having a list is a fun thing to have so we decided to implement it.

Those that think that there's some noise in the list should clarify their use case. Do you really walk the list manually on a repeated basis?

[jkaivo]

Maybe I'm missing something.

GTFOBins is a curated list of Unix binaries that can be exploited by an attacker to bypass local security restrictions.

The authorized use of any binary with SUID does not bypass local security restrictions. The authorized use of sudo does not bypass local security restrictions. If you look at it sideways enough, I'll grant that use of cat with an absolute path can potentially leak information not meant to be accessible from a restricted shell, but the use of restricted shells has never been an effective security restriction. The attacker still has to have file-system permission to read the target file - that is the security boundary.

So regardless of whether someone is looking at the table, or searching explicitly for binaries on a system they're trying to attack (approximately 100% of which include cat), you're presenting the use of a granted privilege as an example of escalated privileges, which is misleading at best.

[cyrus-and]

The authorized use of any binary with SUID does not bypass local security restrictions. The authorized use of sudo does not bypass local security restrictions.

I totally agree and never said that, I'm not sure about the point you're trying to make here, since you also previously said that:

Any program with the SUID bit is a potential route to escalation or escape. [...] Any access to sudo is a potential vulnerability.

approximately 100% of which include cat

As a SUID binary or allowed to run as root via Sudo? No. The idea is not looking up cat just because it exists on a system...

you're presenting the use of a granted privilege as an example of escalated privileges, which is misleading at best.

So don't you agree that granting Sudo permission or setting the SUID bit to cat is an example of escalated privileges and something worthy of note?

We'll rephrase and clarify some of the function descriptions that admittedly can be mislead, but that's it.

[jkaivo]

I think two things have gotten conflated here.

1) The purpose of this page, per the page itself, is to provide "a curated list of Unix binaries that can be exploited by an attacker to bypass local security restrictions." With that stated purpose in mind, the use of SUID binaries or sudo can not be included on the list. The use of any SUID or an authorized invocation of sudo does not "bypass local security restrictions." This use is explicitly permitted by the local security configuration. By a strict reading, SUID binaries and the use of sudo have no place on this list at all.

2) Taking a step back, maybe the actual purpose is to provide a list of binaries that provide access to a system in a way that is not expected by the sysadmin. In that case, it is worth pointing out the risk of SUID binaries or liberal access to sudo. But in those cases, specifically calling out binaries like cat or sed doesn't add a lot of value, since the net effect (the user can gain read or write access to files they wouldn't otherwise have) is the same, and applies across all binaries. There is a case for calling out particularly surprising binaries (such as the aforementioned patch) that could result in arbitrary command execution or network connections.

[cyrus-and]

1. The use of any SUID or an authorized invocation of sudo does not "bypass local security restrictions." This use is explicitly permitted by the local security configuration.

Which may also be home-made and wrong...