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.
> As for the rest of your arguments, I believe you are simply wrong.
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.
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.