4 ms·

> Heck, glibc by default still allows LD_PRELOAD pretty much everywhere, and most distros have available SUID binaries you can hijack, so it's useless sandboxin

> Heck, glibc by default still allows LD_PRELOAD pretty much everywhere, and most distros have available SUID binaries you can hijack, so it's useless sandboxing anyways. Common misconception, but no, glibc doesn't allow LD_PRELOAD on suid binaries. Root is the one thing that's well-protected on linux, you cannot get root without the aid of a user giving it to you. Similarly, separation between users is also rather secure, but no desktop user is going to run each application under their own user.

cookiengineer 3y ago
> glibc doesn't allow LD_PRELOAD on suid binaries. I'll just leave this here then. [1] [1] https://gtfobins.github.io/ https://gtfobins.github.io/
- theamk 3y ago
  the first sentence of this says: > bypass local security restrictions in misconfigured systems. "misconfigured" is a key here. Sure, people do occasionally make mistakes or bad decisions and introduce security vulnerabilities.. but that happens less often than you think. gtfobins is pretty useless in regular server/desktop installs, at least for user permissions elevations. If user-to-root escalation is discovered with common config settings, it gets assigned a CVE and fixed, not listed at random websites.
  - vntok 3y ago
    > Sure, people do occasionally make mistakes or bad decisions and introduce security vulnerabilities.. but that happens less often than you think. It's not exactly expected that a local GIMP desktop install would provide reverse shell capability, yet here we are (https://gtfobins.github.io/gtfobins/gimp/ https://gtfobins.github.io/gtfobins/gimp/)
    - mid-kid 3y ago
      We get it, code execution leads to code execution. https://devblogs.microsoft.com/oldnewthing/20230103-00/?p=107635 https://devblogs.microsoft.com/oldnewthing/20230103-00/?p=10...
    - theamk 3y ago
      GIMP desktop install provides python scripting. The reverse shell capability comes from reverse shell specified on command line. gimp is no more dangerous that any other scriptable app, like emacs, vs code, web browser, etc..
  - cookiengineer 3y ago
    I'm pretty sure this happens more often than you think. I'm literally scraping all Linux security trackers (both OVAL data if available and the trackers themselves) and correlating them. [1] In my personal opinion, Debian/Ubuntu are the worst when it comes to security and maintenance. There are thousands of issues and CVEs marked as Fixed or Ignored on their security tracker which were not actually fixed but had a tag similar to the meaning of "code diverged too much from upstream". A lot of PoCs that you can find on ExploitDB still work today, after 5+ years later, on an updated system. Especially the ones that are disputed CVEs where companies like SAP ain't give no damn about security issues (they have a dispute rate of exactly 100%, how can that be?). Blaming misconfiguration up onto the End-User is not what I would do here, because it's the distribution that labels themselves as being secure/stable/whatever. If users use the default packages with no changes to configurations, I expect the distribution to provide sane and secure defaults. If you argue that a "misconfiguration" is what makes a system vulnerable, then good luck finding a system that is not vulnerable - because there will be none. Coming back to glibc and its messup when it comes to environment variables and parsing and linking issues: That was one of the reasons Alpine started its muscl library. I mean, glibc is so ridiculous that you could get root privilege escalation via using the "ping" command up until around 3 years ago when distributions finally started to remove the SUID flag on the binary and instead use the network capability flags. [1] https://github.com/tholian-network/vulnerabilities https://github.com/tholian-network/vulnerabilities
    - theamk 3y ago
      This is pretty much the opposite of my experience. While there are occasional CVEs which can cause problems, most of them are not exploitable in any way. And the automated security trackers are even worse, giving totally useless results. The latest example which comes to mind CVE-2023-22809, sudoedit bug. Out infosec department made a whole bunch of noise about it, forcing the upgrade all over the place. But this requires (1) interactive user (because sudoedit makes no sense otherwise) with no root sudo access (2) restricted sudoedit access. I am pretty sure our whole org had no machines with such config. First of all, in the era of VMs and cloud machines, the interactive users are admins, they are very likely to have full sudo. And if there is a task unprivileged user must do, it would be a web app or CI runner or a chat automation, not sudo-less ssh session. Second, if such user did exist (unlikely) and had a need to edit a non-owned file (even more unlikely), who would grant them direct "sudoedit" access? It would be a script which takes input file, validates, logs changes, and only then installs the new version. I'd agree with you on one point: proprietary Linux software is often of horrible quality and I would not trust it. I never worked with SAP, but we have a proprietary remote desktop access app, and it's horrible design, with dozens of suid binaries, and insane authentication methods. I would not be surprised if it has a vulnerability or five. As for the rest of your arguments, I believe you are simply wrong. "If users use the default packages with no changes to configurations", the latest Ubuntu with all the patches will be secure. It is not hard to find a system which is not vulnerable - just regular Ubuntu LTS system, say default install + browser + emacs + some compilers, will be secure today (except for unpatched vulnerabilities, of which there are none at this moment; and unknown zero-days which no one can do anything about). glibc had its share or vulnerabilities in the past, but none in the last 10 years. The system defaults are generally secure (but not always sane :) ) If you disagree, please mention specific exploits/CVEs. As a part of my work, I spend lots of effort on keeping stuff secure, but the whole CVE/security scanner things are pretty much a huge disappointment.
- Volundr 3y ago
  I don't get this site. Yes, emacs can be used to read/write files, and yes indeed if you set the SUID bit or run it via sudo it'll have root privileges... And? Is this a common configuration on some system I'm not aware of? What does any of this have to do with LD_PRELOAD?

cookiengineer 3y ago

> glibc doesn't allow LD_PRELOAD on suid binaries. I'll just leave this here then. [1] [1] https://gtfobins.github.io/ https://gtfobins.github.io/

theamk 3y ago
the first sentence of this says: > bypass local security restrictions in misconfigured systems. "misconfigured" is a key here. Sure, people do occasionally make mistakes or bad decisions and introduce security vulnerabilities.. but that happens less often than you think. gtfobins is pretty useless in regular server/desktop installs, at least for user permissions elevations. If user-to-root escalation is discovered with common config settings, it gets assigned a CVE and fixed, not listed at random websites.
- vntok 3y ago
  > Sure, people do occasionally make mistakes or bad decisions and introduce security vulnerabilities.. but that happens less often than you think. It's not exactly expected that a local GIMP desktop install would provide reverse shell capability, yet here we are (https://gtfobins.github.io/gtfobins/gimp/ https://gtfobins.github.io/gtfobins/gimp/)
  - mid-kid 3y ago
    We get it, code execution leads to code execution. https://devblogs.microsoft.com/oldnewthing/20230103-00/?p=107635 https://devblogs.microsoft.com/oldnewthing/20230103-00/?p=10...
  - theamk 3y ago
    GIMP desktop install provides python scripting. The reverse shell capability comes from reverse shell specified on command line. gimp is no more dangerous that any other scriptable app, like emacs, vs code, web browser, etc..
- cookiengineer 3y ago
  I'm pretty sure this happens more often than you think. I'm literally scraping all Linux security trackers (both OVAL data if available and the trackers themselves) and correlating them. [1] In my personal opinion, Debian/Ubuntu are the worst when it comes to security and maintenance. There are thousands of issues and CVEs marked as Fixed or Ignored on their security tracker which were not actually fixed but had a tag similar to the meaning of "code diverged too much from upstream". A lot of PoCs that you can find on ExploitDB still work today, after 5+ years later, on an updated system. Especially the ones that are disputed CVEs where companies like SAP ain't give no damn about security issues (they have a dispute rate of exactly 100%, how can that be?). Blaming misconfiguration up onto the End-User is not what I would do here, because it's the distribution that labels themselves as being secure/stable/whatever. If users use the default packages with no changes to configurations, I expect the distribution to provide sane and secure defaults. If you argue that a "misconfiguration" is what makes a system vulnerable, then good luck finding a system that is not vulnerable - because there will be none. Coming back to glibc and its messup when it comes to environment variables and parsing and linking issues: That was one of the reasons Alpine started its muscl library. I mean, glibc is so ridiculous that you could get root privilege escalation via using the "ping" command up until around 3 years ago when distributions finally started to remove the SUID flag on the binary and instead use the network capability flags. [1] https://github.com/tholian-network/vulnerabilities https://github.com/tholian-network/vulnerabilities
  - theamk 3y ago
    This is pretty much the opposite of my experience. While there are occasional CVEs which can cause problems, most of them are not exploitable in any way. And the automated security trackers are even worse, giving totally useless results. The latest example which comes to mind CVE-2023-22809, sudoedit bug. Out infosec department made a whole bunch of noise about it, forcing the upgrade all over the place. But this requires (1) interactive user (because sudoedit makes no sense otherwise) with no root sudo access (2) restricted sudoedit access. I am pretty sure our whole org had no machines with such config. First of all, in the era of VMs and cloud machines, the interactive users are admins, they are very likely to have full sudo. And if there is a task unprivileged user must do, it would be a web app or CI runner or a chat automation, not sudo-less ssh session. Second, if such user did exist (unlikely) and had a need to edit a non-owned file (even more unlikely), who would grant them direct "sudoedit" access? It would be a script which takes input file, validates, logs changes, and only then installs the new version. I'd agree with you on one point: proprietary Linux software is often of horrible quality and I would not trust it. I never worked with SAP, but we have a proprietary remote desktop access app, and it's horrible design, with dozens of suid binaries, and insane authentication methods. I would not be surprised if it has a vulnerability or five. As for the rest of your arguments, I believe you are simply wrong. "If users use the default packages with no changes to configurations", the latest Ubuntu with all the patches will be secure. It is not hard to find a system which is not vulnerable - just regular Ubuntu LTS system, say default install + browser + emacs + some compilers, will be secure today (except for unpatched vulnerabilities, of which there are none at this moment; and unknown zero-days which no one can do anything about). glibc had its share or vulnerabilities in the past, but none in the last 10 years. The system defaults are generally secure (but not always sane :) ) If you disagree, please mention specific exploits/CVEs. As a part of my work, I spend lots of effort on keeping stuff secure, but the whole CVE/security scanner things are pretty much a huge disappointment.
Volundr 3y ago
I don't get this site. Yes, emacs can be used to read/write files, and yes indeed if you set the SUID bit or run it via sudo it'll have root privileges... And? Is this a common configuration on some system I'm not aware of? What does any of this have to do with LD_PRELOAD?