5 ms·

>If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain

by kiryin 5y ago

>If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access. Wat. If you add someone to wheel, they may abuse those privileges. Is this really something that needs pointing out? There are many other useful tidbits that you may not necessarily know but this one struck me as a bit odd.

scandinavian 5y ago
It's not referring to having sudo ALL permissions, but to users having sudo permissions for individual applications. So if you are trying to privilege escalate a linux box and sudo -l returns: (root) /usr/sbin/tcpdump You check gtfobins for tcpdump and see that you can get a root shell with sudo access.
- pjmlp 5y ago
  If the server admin was dumb enough to allow executables on $HOME, or anywhere where the user has write access.
  - NavinF 5y ago
    Why would the attacker need to set the execute bit on the file they want to execute? Can't they just run "tcpdump -ln -i lo -w /dev/null -W 1 -G 1 -z /lib64/ld-linux-x86-64.so.2" and then swap the tcpdump savefile with the file they want to execute? That will run "ld-linux-x86-64.so.2 ./savefile" after a few seconds which is the same thing as running "chmod +x savefile; ./savefile" https://unix.stackexchange.com/questions/400621/what-is-lib64-ld-linux-x86-64-so-2-and-why-can-it-be-used-to-execute-file https://unix.stackexchange.com/questions/400621/what-is-lib6... Anyway this whole discussion of "What if the admin was silly enough to think the execute bit did something?" is academic. If the attacker can run any binary that's already on the system as root, you've already lost.
    - pjmlp 5y ago
      For that they have to have the rights to actually replace tcpdump, so it is already owned anyway.
      - NavinF 5y ago
        No, the stock tcpdump works just fine for this attack. You were replying to a guy talking about this scenario where the attacker can run tcpdump as root: >So if you are trying to privilege escalate a linux box and sudo -l returns: (root) /usr/sbin/tcpdump
        pjmlp 5y ago
        Except you missed the part "swap the tcpdump savefile", which one then needs to execute somehow. Complicated, when not given the rights to do so.
        creshal 5y ago
        The savefile is not the tcpdump executable.
        NavinF 5y ago
        Swapping the file is as easy as running "mv ./evil_binary ./savefile". This is all happening in the home directory. evil_binary can written using "echo -n -e" You can take as much time as you want to do the swap. tcpdump will only run the log-rotate program you specified after the time limit you specified has passed. I find it baffling that you think this is a complicated exploit. It's literally the first thing I thought of, and I'm just a random programmer. A real attacker would have a lot more tricks up their sleeve and all the time in the world to google solutions to problems like this. Does your threat model assume that the attacker doesn't know how to use a terminal?
        pjmlp 5y ago
        Home is mounted as noexec. Sure when there is a will, there is a way, however it seems many here lack the experience to work on properly locked down UNIX servers, where a user is really a plain user that dances to IT music tune.
creshal 5y ago
You're kind of missing the point of sudo if that's all you use it for. sudo can also be used to whitelist specific user+program+argument combinations, so e.g. unprivileged users can run system updates, but not install new programs. These users can use sudo, but should not be able to reach full root privileges from it. But if such a setup is indirectly exploitable because the default $PAGER allows arbitrary code execution, that's definitely a gotcha you need to be aware of.
- NavinF 5y ago
  I remember reading about this use case ~10 years ago. I always found it super weird and I've never had a chance to use it. Even back then, people didn't share computers unless they fully trusted each other. If a program running as an unprivileged user wants to trigger something like a software update, I'd just write a daemon that reads the trigger command over a unix socket or a signed message over a TCP socket and then runs the update. I guess you'd lose the automatic audit logging of sudo, but pretty much any programmer can verify correctness.
  - creshal 5y ago
    > Even back then, people didn't share computers unless they fully trusted each other. Or you're in a big enterprise or university that has a ton of shared machines. sudo wasn't really designed with single-user machines in mind, `su -l` is good enough for those.
    - im3w1l 5y ago
      I've only ever seen people use sudo to prevent accidents (by running most commands unprivileged), not malicious use.
matthberg 5y ago
I also found this a bit overly obvious at first, yet when considering it from an unintended side effects/uses perspective it's actually a valid thing to consider. For example, `less`[0] might be used with `sudo` to view a file owned by another user. This is all good until you remember that you can run arbitrary commands by just hitting '!' in the paging view, which are also runs with `sudo` privileges. Though that might seem like a bit of a contrived example, through unintended features otherwise safe tools can be unexpectedly dangerous (the entire point of this site). For a real-ish world example of this effect, one of the OverTheWire wargame challenges [1] (spoilers for bandit) has a user login "shell" be a message saying login was prohibited, printed with `less`. When you resize your console window to a point where scrolling is needed and then attempt login, you can then interact with `less` and use '!' to run commands as the current user and print the key. Now you may say this isn't relevant to the `sudo` category of risk since who runs `sudo less` without also being able to run `sudo anything`, but many other apps use less as their pager, and some of those make much more sense to allow for general use with sudo (like say allowing all users to update apps, or any of hundreds of other insignificant things). In short, I think the `sudo` and `setuid` notices might be better considered as "permission transparent", i.e. any permissions or access you hand to the listed tools are handed directly to the user as well. There are secure ways to not do this when writing programs, like by setting all of the real, effective, and saved uids [2] to something non-root (or the original calling user, if available) and totally wiping the capabilities sets before `exec()`ing anything, yet that's just what I remember from a computer security class a few years ago, you would probably be best off looking into it further if you're writing anything security sensitive. [0]: https://gtfobins.github.io/gtfobins/less/ https://gtfobins.github.io/gtfobins/less/ [1]: https://overthewire.org/wargames/bandit/ https://overthewire.org/wargames/bandit/ [2]: https://man7.org/linux/man-pages/man2/setresuid.2.html https://man7.org/linux/man-pages/man2/setresuid.2.html
- VBprogrammer 5y ago
  I used to work for a company where launching a shell from within vim was the way we got privileged access on some of the customers boxes (which ran code we developed). Pretty crazy looking back on it..

by kiryin 5y ago

scandinavian 5y ago

It's not referring to having sudo ALL permissions, but to users having sudo permissions for individual applications. So if you are trying to privilege escalate a linux box and sudo -l returns: (root) /usr/sbin/tcpdump You check gtfobins for tcpdump and see that you can get a root shell with sudo access.

pjmlp 5y ago
If the server admin was dumb enough to allow executables on $HOME, or anywhere where the user has write access.
- NavinF 5y ago
  Why would the attacker need to set the execute bit on the file they want to execute? Can't they just run "tcpdump -ln -i lo -w /dev/null -W 1 -G 1 -z /lib64/ld-linux-x86-64.so.2" and then swap the tcpdump savefile with the file they want to execute? That will run "ld-linux-x86-64.so.2 ./savefile" after a few seconds which is the same thing as running "chmod +x savefile; ./savefile" https://unix.stackexchange.com/questions/400621/what-is-lib64-ld-linux-x86-64-so-2-and-why-can-it-be-used-to-execute-file https://unix.stackexchange.com/questions/400621/what-is-lib6... Anyway this whole discussion of "What if the admin was silly enough to think the execute bit did something?" is academic. If the attacker can run any binary that's already on the system as root, you've already lost.
  - pjmlp 5y ago
    For that they have to have the rights to actually replace tcpdump, so it is already owned anyway.
    - NavinF 5y ago
      No, the stock tcpdump works just fine for this attack. You were replying to a guy talking about this scenario where the attacker can run tcpdump as root: >So if you are trying to privilege escalate a linux box and sudo -l returns: (root) /usr/sbin/tcpdump
      - pjmlp 5y ago
        Except you missed the part "swap the tcpdump savefile", which one then needs to execute somehow. Complicated, when not given the rights to do so.
        creshal 5y ago
        The savefile is not the tcpdump executable.
        NavinF 5y ago
        Swapping the file is as easy as running "mv ./evil_binary ./savefile". This is all happening in the home directory. evil_binary can written using "echo -n -e" You can take as much time as you want to do the swap. tcpdump will only run the log-rotate program you specified after the time limit you specified has passed. I find it baffling that you think this is a complicated exploit. It's literally the first thing I thought of, and I'm just a random programmer. A real attacker would have a lot more tricks up their sleeve and all the time in the world to google solutions to problems like this. Does your threat model assume that the attacker doesn't know how to use a terminal?
        pjmlp 5y ago
        Home is mounted as noexec. Sure when there is a will, there is a way, however it seems many here lack the experience to work on properly locked down UNIX servers, where a user is really a plain user that dances to IT music tune.

creshal 5y ago

You're kind of missing the point of sudo if that's all you use it for. sudo can also be used to whitelist specific user+program+argument combinations, so e.g. unprivileged users can run system updates, but not install new programs. These users can use sudo, but should not be able to reach full root privileges from it. But if such a setup is indirectly exploitable because the default $PAGER allows arbitrary code execution, that's definitely a gotcha you need to be aware of.

NavinF 5y ago
I remember reading about this use case ~10 years ago. I always found it super weird and I've never had a chance to use it. Even back then, people didn't share computers unless they fully trusted each other. If a program running as an unprivileged user wants to trigger something like a software update, I'd just write a daemon that reads the trigger command over a unix socket or a signed message over a TCP socket and then runs the update. I guess you'd lose the automatic audit logging of sudo, but pretty much any programmer can verify correctness.
- creshal 5y ago
  > Even back then, people didn't share computers unless they fully trusted each other. Or you're in a big enterprise or university that has a ton of shared machines. sudo wasn't really designed with single-user machines in mind, `su -l` is good enough for those.
  - im3w1l 5y ago
    I've only ever seen people use sudo to prevent accidents (by running most commands unprivileged), not malicious use.

matthberg 5y ago

I also found this a bit overly obvious at first, yet when considering it from an unintended side effects/uses perspective it's actually a valid thing to consider. For example, `less`[0] might be used with `sudo` to view a file owned by another user. This is all good until you remember that you can run arbitrary commands by just hitting '!' in the paging view, which are also runs with `sudo` privileges. Though that might seem like a bit of a contrived example, through unintended features otherwise safe tools can be unexpectedly dangerous (the entire point of this site). For a real-ish world example of this effect, one of the OverTheWire wargame challenges [1] (spoilers for bandit) has a user login "shell" be a message saying login was prohibited, printed with `less`. When you resize your console window to a point where scrolling is needed and then attempt login, you can then interact with `less` and use '!' to run commands as the current user and print the key. Now you may say this isn't relevant to the `sudo` category of risk since who runs `sudo less` without also being able to run `sudo anything`, but many other apps use less as their pager, and some of those make much more sense to allow for general use with sudo (like say allowing all users to update apps, or any of hundreds of other insignificant things). In short, I think the `sudo` and `setuid` notices might be better considered as "permission transparent", i.e. any permissions or access you hand to the listed tools are handed directly to the user as well. There are secure ways to not do this when writing programs, like by setting all of the real, effective, and saved uids [2] to something non-root (or the original calling user, if available) and totally wiping the capabilities sets before `exec()`ing anything, yet that's just what I remember from a computer security class a few years ago, you would probably be best off looking into it further if you're writing anything security sensitive. [0]: https://gtfobins.github.io/gtfobins/less/ https://gtfobins.github.io/gtfobins/less/ [1]: https://overthewire.org/wargames/bandit/ https://overthewire.org/wargames/bandit/ [2]: https://man7.org/linux/man-pages/man2/setresuid.2.html https://man7.org/linux/man-pages/man2/setresuid.2.html

VBprogrammer 5y ago
I used to work for a company where launching a shell from within vim was the way we got privileged access on some of the customers boxes (which ran code we developed). Pretty crazy looking back on it..