> glibc doesn't allow LD_PRELOAD on suid binaries.
I'll just leave this here then. [1]
I'll just leave this here then. [1]
What does any of this have to do with LD_PRELOAD?
> 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.
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.
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.
Just coming across this comment, I would disagree with your assessment.
Most distros use systemd, systemd has a dependency on d-bus and to do many of the features their userbase expects, it relies on d-bus activation which reparent's processes under the systemd user in most cases via the dbus-helper which suid's. This process also breaks common admin utilities like tops and ps (they don't show up except under very specific views, like tree view). Importantly, these distros often do not have MAC configured with a safe baseline if at all.
To put it mildly auditing d-bus and activations of this sort is ridiculously obtuse from an administrative perspective. Then there's all the dated software which no one touches or views such as gsd-* that cause a fail-whale when disabled.
The way exploits work most times is by using a chain of exploits. You chain 1 piece to the next, to the next, until you get to a bug that gets you what you want and the attacker then hits paydirt. This is basic cyber-sec 101, I don't see why you would discount exploits just because you don't know how they can get to that point to use it. We work with a porous attack surface everyday.
Most distro's have system defaults which don't even include a basic endpoint stateful firewall. I would hardly call these distros secure (which is most of them). End users are not expected to have specialties in Cybersec, Information Technology or System's Engineering just to set up a out of box system that's secure by default, this is the responsibility of the distro publisher.
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://devblogs.microsoft.com/oldnewthing/20230103-00/?p=10...
gimp is no more dangerous that any other scriptable app, like emacs, vs code, web browser, etc..