Twelve-Year-Old Linux Vulnerability Discovered and Patched

It’s a privilege escalation vulnerability:

Linux users on Tuesday got a major dose of bad news—a 12-year-old vulnerability in a system tool called Polkit gives attackers unfettered root privileges on machines running most major distributions of the open source operating system.

Previously called PolicyKit, Polkit manages system-wide privileges in Unix-like OSes. It provides a mechanism for nonprivileged processes to safely interact with privileged processes. It also allows users to execute commands with high privileges by using a component called pkexec, followed by the command.

It was discovered in October, and disclosed last week—after most Linux distributions issued patches. Of course, there’s lots of Linux out there that never gets patched, so expect this to be exploited in the wild for a long time.

Of course, this vulnerability doesn’t give attackers access to the system. They have to get that some other way. But if they get access, this vulnerability gives them root privileges.

Tags: , , ,

Posted on January 31, 2022 at 6:18 AM • 36 Comments

Comments

Denton Scratch • January 31, 2022 7:27 AM

Isn’t polkit only really needed if you have multiple desktop users?

It’s hard to remove, because of tangles of dependencies, but but I think only GNOME requires it. Oh – systemd probably wants it.

Most Linux systems are either servers (i.e. no desktop users), or personal laptops (i.e. only one desktop user). Places where it might be useful include hot-desking situations; but people don’t generally share their laptop, so they don’t need polkit.

I don’t have any of this *kit stuff on my systems; everything works, including XFCE.

[Edit] I have a 10-year-old Panasonic “smart” TV. I have no idea what that is running. I also have a Sky box. But neither of them provides any way to get a commandline, as far as I can see, and this exploit depends on a commmandline.

Hedo • January 31, 2022 10:41 AM

@Denton Scratch,
Yeah, tell me about it, I’ve done it a million times where I’d get too deep into removing dependencies until I’d break the installation and had to either start over from scratch or restore from a backup if I had one. It can get very tricky once you get into removing of some of the dependencies.
An example of “tangles of dependencies” as you put it – is CUPS nowadays. It used to be fairly straightforward to remove CUPS with dependencies if you didn’t need to print but as time goes by it’s getting harder and harder to remove all CUPS dependencies due to BS such as “tangles of dependencies”.

Furthermore, there will be a ton more bad news for Linux OSs (any flavor) because as I mentioned it before – more home users are switching to Linux because it still is way more secure than Windows. It’s open source and free (some exceptions such as RHEL) but the open source community is pretty big, a worldwide pool of some very bright and talented individuals that take care of fixes pretty darn quick. Response time to fix vuln’s is very quick compared to the M$’s monthly patches. Linux was and is considered way more secure than Windows because it is so by design and for many other obvious reasons which I won’t get into, but it has also had a pretty small user-base (market-share) thusly NOT targeted by hackers nearly as much as Windows because most Computer users in the world are running Windows and logically, if you can hack Windows – you can gain access to many many more devices than if you can hack Linux.

That is changing slowly but surely and there will be more very OLD vulnerabilities exposed in Linux systems simply because Linux systems have been UNDER THE RADAR for a very long time and not that many hackers were interested in investing their time and effort into something that very few people use but like I said – that is changing, and it is becoming more profitable to be able to break into Linux systems. This for the most part applies to desktop systems as many Enterprise systems (servers) are running RHEL and come with a paid support so it’s a bit harder to break into those.

This of course applies to the “point and click” GUI tools that can and will be designed and sold to the interested parties because the demand has favored M$ hacking tools for a long time due to the very large user-base but as I said, as Linux user-base grows – so will the demand for en masse Linux hacking tools (exploit kits). Simply put, not that many hackers were focused on Linux in the past, thus adding another layer of “security”.

RandolphLe • January 31, 2022 10:52 AM

Isn’t polkit only really needed if you have multiple desktop users?

It’s hard to remove, because of tangles of dependencies, but but I think only GNOME requires it. Oh – systemd probably wants it.

pkexec, it seems, is needed by almost nobody, so it’s a bit unfair to call this a “Linux vulnerability”. Run “chmod u-s /usr/bin/pkexec” as root (or “dpkg-statoverride –update –add root root 755 /usr/bin/pkexec” on a Debian/Ubuntu system), and you probably won’t have any problems. It serves a similar purpose to sudo: once in a while, it opens a root hole when we find it’s been insecure all along. The ostensible purpose of running a command as another user is similar too, but you’d probably be better off with the “command=” option in an OpenSSH authorized_keys file; that program has a better track record for security, and avoids the setuid feature (which gives the calling process way too much control over the privileged program’s state, and has therefore been a constant source of trouble and required various ad-hoc kernel restrictions like making chroot() privileged).

There’s talk of changing the kernel to restrict argc==0. It’s not clear Linus will acccept it, because it will break programs—notably, the test case for this very bug—and everything that’s been proposed can be done just as well, or better (less possibility of breakage), in libc. As I hint at above, what I’d rather have is a way to disable setuid processes everywhere. Maybe someone could convince the systemd developers to have pid 1 call prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) before spawning anything, when a certain boot option is set. We should have either setuid/setgid and “file capabilities” (man 8 setcap), or dbus/polkit/etc., or just OpenSSH; not multiple ways to escalate privilege.

RandolphLe • January 31, 2022 11:18 AM

Hedo, removing packages is a difficult way to handle this (because of all the dependencies). There are several easier ones:

1) Make sure their daemons are disabled, e.g. via “systemctl disable”.
2) Use dpkg-statoverride or similar to revoke any setuid/setgid privileges, or even the ‘x’ bit if you want to ensure even root won’t run them (via dbus or cron or whatever). Then they’re just wasting disk space.
3) More aggressively, make a dummy package with the correct name and version and “Provides:” lines to satisfy the dependencies, then install it and freeze its version (e.g., “apt-mark hold”). In some cases, like with polkit or cups-daemon, an empty package might do, which would make this really easy. If a library and daemon are in the same package, it’ll be kind of a pain in the ass, because you’ll need a library with all necessary symbols (rebuilding the package but omitting the binaries might work). Debian seems to prefer separate packages, though.

FA • January 31, 2022 2:34 PM

@Denton Scratch

I don’t have any of this *kit stuff on my systems; everything works

Same here, and indeed you don’t need it.

Polkit/Policykit just adds another layer on top of the basic Unix security checks, and the only way it can do that is by being a security risk itself.
It just obfuscates things that should be simple to manage and audit.

Clive Robinson • January 31, 2022 2:35 PM

@ Bruce, ALL,

Of course, this vulnerability doesn’t give attackers access to the system. They have to get that some other way.

But access gets given all the time because… Just well because, it’s what somepeople “nod along to”.

The first question that should be asked about any xomputer system, from a gumstick like the Pi 2W right theough to some moder super computer with a few thousand CPU chips is,

What is the VALID business case for connecting this system to externally available communications?”

In the very very few valid business cases, more often than not, you can achive the same or better objective by doing things other ways, thus avoiding having computer systems even indirectly connected to externally available communications.

It’s long over due that we consider these alternatives first, for our own sanity. The MBA robotic mantra of “Must connect, connectivity is an enabler, enablers are good”… Needs to be not just “defenistrated”[1] but those that who midlessly chant it should have their wherewithal chopped with extream prejudice[2].

@ Denton Scratch, Hedo, ALL,

It’s hard to remove, because of tangles of dependencies…

The dependencies are there for what are silly reasons these days. That is we are not “resource limited” in a way that necesitates this sharing.

In fact the sharing is actually a bad idea outside of libraries for languages, designed by standards committees…

The reason is people needlessly try to make their libraries “all things to all men” and that is not just dangerous as log4J recently showed[3] but also because it makes the code being “reused” way way larger, way more complex, thus way more fragile, than writing what “needs to be done”, rather than for “everything that can be done”.

It’s actually slightly worse than you say with,

Most Linux systems are either servers (i.e. no desktop users), or personal laptops (i.e. only one desktop user).

If SysAdmins are sensible, and want reasonable “availability” servers are used,

1, Only for one Service.
2, For services with no interdependencies.

That way, infrastructure tends towards “staying up” rather than go it various forms of “YoYo mode” due to management silliness that forces developers to make code with way to much “reuse” expectation in it.

Just to make it worse some managment want everything possible to be “shoved on the box” as they see it as a “cost saving” which it most probably is not…

[1] “Defenistratend” literally means “thrown out of windows” not sure what the same is for *nix, but…

[2] I do know the word for a group of emasculated males sounds just like “unix”…

[3] Just four weeks ago the FTC joined the SEC in “throwing the toys out of the pram” with regards the legislative and regulatory side of the Log4J issue,

https://www.csoonline.com/article/3646595/sec-ftc-warn-companies-to-remediate-log4j-vulnerabilities.html

Clive Robinson • January 31, 2022 2:38 PM

@ Moderator,

Just had a 429 “too many” error.

Which on trying to repost cause a “being held for moderation.

I will try spliting it but this problem appears to be getting worse for some reason 🙁

Clive Robinson • January 31, 2022 2:41 PM

@ Bruce, ALL,

Of course, this vulnerability doesn’t give attackers access to the system. They have to get that some other way.

But access gets given all the time because… Just well because, it’s what somepeople “nod along to”.

The first question that should be asked about any xomputer system, from a gumstick like the Pi 2W right theough to some moder super computer with a few thousand CPU chips is,

What is the VALID business case for connecting this system to externally available communications?”

In the very very few valid business cases, more often than not, you can achive the same or better objective by doing things other ways, thus avoiding having computer systems even indirectly connected to externally available communications.

It’s long over due that we consider these alternatives first, for our own sanity. The MBA robotic mantra of “Must connect, connectivity is an enabler, enablers are good”… Needs to be not just “defenistrated”[1] but those that who midlessly chant it should have their wherewithal chopped with extream prejudice[2].

[1] “Defenistratend” literally means “thrown out of windows” not sure what the same is for *nix, but…

[2] I do know the word for a group of emasculated males sounds just like “unix”…

Clive Robinson • January 31, 2022 2:43 PM

@ Denton Scratch, Hedo, ALL,

It’s hard to remove, because of tangles of dependencies…

The dependencies are there for what are silly reasons these days. That is we are not “resource limited” in a way that necesitates this sharing.

In fact the sharing is actually a bad idea outside of libraries for languages, designed by standards committees…

The reason is people needlessly try to make their libraries “all things to all men” and that is not just dangerous as log4J recently showed[1] but also because it makes the code being “reused” way way larger, way more complex, thus way more fragile, than writing what “needs to be done”, rather than for “everything that can be done”.

It’s actually slightly worse than you say with,

Most Linux systems are either servers (i.e. no desktop users), or personal laptops (i.e. only one desktop user).

If SysAdmins are sensible, and want reasonable “availability” servers are used,

1, Only for one Service.
2, For services with no interdependencies.

That way, infrastructure tends towards “staying up” rather than go it various forms of “YoYo mode” due to management silliness that forces developers to make code with way to much “reuse” expectation in it.

Just to make it worse some managment want everything possible to be “shoved on the box” as they see it as a “cost saving” which it most probably is not…

[1] Just four weeks ago the FTC joined the SEC in “throwing the toys out of the pram” with regards the legislative and regulatory side of the Log4J issue,

hxxps://www.csoonline.com/article/3646595/sec-ftc-warn-companies-to-remediate-log4j-vulnerabilities.html

John Brown • January 31, 2022 3:58 PM

@Denton Scratch you are correct in that Polkit is required by Systemd. This is just a small part of the cancer that Poettring has inflicted on Linux systems.

As a result of this deliberate sabotage, unless you’ve gone out of your way to pick a system that sensibly avoids Poettring’s virus, then you’re vulnerable to this exploit, and many others. Devuan is the best choice for those currently stuck on compromised distributions like Ubuntu or Debian.

@RandolphLe it’s not ‘required’ by Linux. But it is required by the virus that Lennart Poettring has spread through many formerly great distributions. If you are currently using a distribution infected by systemd, walk, not run, away.

Clive Robinson • January 31, 2022 6:50 PM

@ John Brown, Denton Scratch,

If you are currently using a distribution infected by systemd, walk, not run, away.

Even though the barn door was left banging in the storm that followed it’s escape into the wils, the pwnie still comes galloping back in the nightmare…

https://pwnies.com/systemd-bugs/

I’ll be honest, and say I could never see the point to systemd scope, it just made things needlessly complicated where they did not need to be. And as a result moved “power over systems” away from the owners to the distribution publishers. If you are a “desktop user” you are probably unaware of systemd which is unfortunate… but if you are the SysAdmin of numerous servers, you probably hate systemd for a whole host of reasons, not least being it breaks all the Unix models and is needlessly complicated and has “binary logs”.

Why do I say

“… you are probably unaware of systemd which is unfortunate…”

Well you would have thought that people would have by now wised up to the salami slicing progress towards “lock-in” that the likes of Microsoft and Apple and Google have done one way or another on other OS’s. So you would have thought that would have alerted people to the danger for Linux…

There are two sayings,

“If it ain’t broke, don’t fix it.”

And,

“Don’t Change For the Sake of Change”

They have when coupled to the history of such things, end up giving you the view that,

“Change for changes sake rarely gives progress and almost always comes around to haunt you.”

Therfore “Change has to be for a valid reason”, not because it’s creator thinks it’s a “neat idea”. Yes SysVinit needed updating, but it did not need to be a million lines of code, that trys to be,

“All things, to all things.”

There is for instance a very good reason why Unix almost always used “human readable” files, protocols etc, because they alowed “people” to work with them with minimal unspecialised tools. Further “lockin” would be next to impossible. Binary files and interfaces however are a problem. Systemd needs specialised tools and interfaces and it breaks standards.

You have to work wirh the tools provided and if they don’t support the changes you want to make, then you have a rather significant problem.

But what of the public face of systemd, well… Some think he’s not exactly facing reality on various fronts,

https://www.zdnet.com/article/lennart-poetterings-linus-torvalds-rant/

Vagans • January 31, 2022 10:02 PM

@Clive Robinson: I tend to agree that making the number of ways of putting data onto a system as small as possible makes the user and supporter’s life easier. The thing I don’t understand about your perspective is this:

Computers are tools for storing, changing, and transmitting data. Their power comes from taking in data, manipulating it, and sending it out. So how do you propose to restrict access as far as you want to without giving up this power? Typical personal-computing tasks are looking up the weather report, looking up an object stored in another building, and creating a document and sending it to someone in another country. These tasks all require communicating with an external source.

Lets say you are designing the IT system for a department store. They have an inventory system which needs to be updated pretty close to 24/7 as shipments arrive, product is sold and returned, and items move from receiving to warehouse to floor to new location on the floor. Of course the store also sells online, so part of the inventory has to be available over the Internet (oh, and other stores in your chain may want to know if you have an item in stock which they do not have in stock). And the system which prints receipts needs access to a list of orders and a list of items and current prices.

How would you propose to meet these needs using your philosophy? Or how would you make a case that the business can compete with other businesses without them?

Denton Scratch • February 1, 2022 1:11 AM

compromised distributions like Ubuntu or Debian.

For clarity, all my Linux systems are Debian, without systemd or any *kit nonsense.

Debian supports and packages sysvinit and other inits. It’s just a PITA to get rid of the default stuff.

I haven’t tried Devuan. Two reasons: (a) it’s a fringe distro, and I’m not confident in it; and (b) it’s still possible to de-kit it.

I deplored the decision a few years ago to make systemd the default init. I absolutely think that this was the wrong decision for Debian specifically. But Debian is ruled by Debian developers, i.e. package maintainers and the people who develop Debian-specific stuff like apt. Debian isn’t a sort of democracy of the users; users don’t get a say. I’m OK with that.

If Debian ever makes it impossible to remove the *kit nonsense and systemd, then I’ll have to find another OS; a bit like if your long-term girlfriend is always washing her hair, and can’t make time to see you. As far as Ubuntu is concerned, I’ve never been inclined to rely on Ubuntu. Ubuntu is trying to make a mass-market desktop OS, like RedHat, and they lean heavily on the Poettering components. If I’m ever forced to abandon Debian, I might go for LinuxFromScratch.

Curious • February 1, 2022 4:35 AM

Please pardon my ignorance, but I am wondering: Lets say just for the sake of argument sort of, that Linux distro was 100% secure in some sense, then if I installed a web browser and trusted that piece of software to be bug free and not contain malicious things; I am wondering, would the addition of that one piece of software potentially compromise the entire security of the linux OS, or how does that work?

I guess I am wondering, does any OS typically prevent any single application/software, from compromising your entire computer? Otherwise, it sort of seems to me that, adding any one additional software on your computer, is just hopelessly complicating things and becomes just a question of time before your computer is deemed insecure in ways.

SpaceLifeForm • February 1, 2022 5:44 AM

@ Curious

Good thinking. To answer your question, it should not be a problem to install a userland application and have it not subvert your system. If the application is not running as root, then it should be considered safe.

That is what some call ‘theory’.

Then there is ‘reality’.

Silicon Turtles

This is why, sometimes, bare metal is safer.

Peter A. • February 1, 2022 6:46 AM

@Curious @SpaceLifeForm

Right. Unix derivatives still have the legacy of ‘setuid bit’, a hack from distant past that allowed regular users do things restricted for administrators for technical reasons, but useful for regular users, like changing a password – just because that involved writing to a file that was write-protected from users. Old Unix dialects had even more ‘setuid’ programs, for example even listing active processes (‘ps’ command) had to run as root, because of a rather simplistic way it worked, reading out data directly from an in-memory kernel tables (via a pseudo device file /dev/kmem).

A random app run from userland can’t compromise the system all by itself, but can exploit bugs in ‘setuid’ programs or privileged internal services or even in system calls (very rare) to do something as root, so it has more chances that an Internet worm which can access only the services exposed to the world.

Theoretically, such operations like changing a password should be done via authenticated APIs to some privileged system service or the kernel, not by ‘magic’ programs that routinely escalate privileges. Of course there is always a potential for kernel or system service level bugs allowing to bypass authentication.

Even if kernel and system services are rock solid, an userland app can subvert you, the user, by stealing your credentials etc. Back then we played little pranks on fellow students by leaving the terminal with a little program running, which mimicked the normal login prompts, saved the credentials entered, emulated an incorrect password response, then killed the session thus going back to normal system login. Our colleagues soon learned to power-cycle the terminal (thus signaling logout to the system) before logging in…

Winter • February 1, 2022 10:13 AM

@SpaceLifeForm
” To answer your question, it should not be a problem to install a userland application and have it not subvert your system.”

Immutable file systems might help (a little). For instance, Silverblue:
ht-tps://www.redhat.com/sysadmin/immutability-silverblue

New applicaitons are installed by way of flatpacks. Obviously, it is not perfect, nothing is, but it reduces the number of things you have to worry about.

JonKnowsNothing • February 1, 2022 10:47 AM

@SpaceLifeForm, @Curious, @Winter, @All

re: Compromised Security Pre-Post OS Installation

An issue that is common to just about everywhere:

  Setting up a PC system for User Access vs Admin Access

If you are working in a big corp with a big corp provided hunk of stuff that lands on your desk and you have to call IT for anything you want to do with the machine, such a system might have been setup with a split between Admin Profile and User Profiles.

The software installed may have required Admin Access to install it but does not require Admin Access to run it. Often this type of software has a “central installation” scheme and each User Profile gets a sanitized version unique to that profile. Meaning UserA gets a copy and UserB gets a copy.

The copy is not necessarily the entire installed version but callable segments that tap into the central version. The User Profile get the needed functionality to access the main code base.

This separation allows the PC Hunk of Stuff to have many User Profiles without every profile having Admin Privileges.

This scheme fails in at least 2 scenarios:

1) Engineering. Nearly every engineer will have one or more machines 100% under their control where they install, wipe and reinstall the OS on a regular basis. The reasons for the wipe and reinstall vary but a fair amount of Dev Time is related to Crash Recovery.

2) Home Systems. Nearly every system sold in stores comes “pre-loaded”. There is a dropped copy of the OS on some partition of the hard drive. You plug it in, turn it on and “GO”. Except you are not supposed to just GO, you are in Theory, Illinois, supposed to do some housekeeping on the system before GO.

This housekeeping isn’t commonly done or completed, because folks just want to GO.

Housekeeping can be downloading updates, configuring the system to connect to your internet access devices, installing or licensing pre-hooked software and maybe for those a bit more savvy, installing other software packages not included in the initial drop on base.

The one thing that rarely gets setup in Home System is “Admin Profile vs User Profile”. People just run under the Admin Profile because they don’t understand what a User Profile does and if they have tried a User Profile and got “You Need To Supply The Admin Password” prompt to run something they revert to using the Admin Profile to avoid the message.

Some systems attempt to fix this but users are quite inventive and they just want to run their stuff and are not interested in the finer details of system security or data safe computing.

What all of that means is, you can secure the hardware, you can secure the OS installation, you can secure an add-on application but if you run under Admin Profile you’re not as secure as you may think. (1)

===

1) Secure is used here in the commonly understood meaning, not the deeper problems facing the entire hardware, software and internet where there is no security possible.

Scott Lewis • February 1, 2022 5:39 PM

@RandolphLe

You write: “ pkexec, it seems, is needed by almost nobody, so it’s a bit unfair to call this a “Linux vulnerability”. ”

I completely am baffled by that statement. If it’s widely deployed by default then it’s a vulnerability. The fact that many might not need it is irrelevant. It’s both vulnerable, and widely installed.

Being capable of being patched or easily disabled also wouldn’t change the fact that there are tons of at risk systems out in the wild.

RandolphLe • February 1, 2022 6:20 PM

“pkexec, it seems, is needed by almost nobody, so it’s a bit unfair to call this a Linux vulnerability.”

I completely am baffled by that statement.

You’re right that the statement as written was unclear. Sorry about that. My intended point was that the vulnerability is not in Linux, but in some software that runs on Linux. I think I wrote “so” because it would be easier to call this a “Linux vulnerability” if the software were arguably necessary to use Linux—like ‘mount’ or udev. (I should’ve explained that or split it into two independent sentences.)

In this case, though, it’s a vulnerability in some software that almost nothing (from what I can tell) depends on. If any Linux distributions installed it setuid-root by default—a bad idea if indeed no other packaged software actually runs it—it’s those Linux distributions, not “Linux”, that were vulnerable.

Speaking of bafflement, I have no idea why distros install all their setuid-root programs as executable by any user. Only “real” users, and not “www-data” or “systemd-timesync” for example, are likely to ever need to execute ‘passwd’ or ‘chsh’ or ‘mount’. All that stuff should be mode 4754 (if setuid at all), executable only by users in a specific group. Debian’s adduser.conf even allows a convenient ADD_EXTRA_GROUPS option to make all “non-system” users end up in such a group.

SpaceLifeForm • February 1, 2022 7:24 PM

@ Scott Lewis, RandolphLe

Technically, it is not a Linux bug. I am being technical, it is not a Linux Kernel bug.

It is really a Userland problem because there must exist setuid userland programs.

There are only 3 (or 2) Userland programs that require setuid bit. The others are cruft that expands the attack surface.

The critical ones are login, su, and passwd.

The passwd program technically does not need to have the setuid bit, if you use the modern bsd method.

But, login and su definitely need the setuid bit.

Those are the only Userland programs that you really need with the setuid bit set.

Any others are attack surface.

ResearcherZero • February 1, 2022 8:43 PM

@SpaceLifeForm

BSD has a very good approach to implementing security updates and features.

RandolphLe • February 1, 2022 10:33 PM

But, login and su definitely need the setuid bit.

Evidently not. login isn’t setuid on my Debian system, and that’s not a local override. /usr/sbin/getcap doesn’t list any file capabilities for it either.

su only needs the bit if non-root users want to become root. As far as I know, no common software depends on that (nor have I seen anything, except for the occasional dodgy shell-script, that misses sudo when it’s not around). One could use ssh instead, or a virtual terminal, or various other methods (common desktop software doesn’t “become” root but uses dbus to make requests of software running as root; polkit’s sometimes used, but I don’t think pkexec is).

Do “average” users even use the passwd utility to change their passwords? I imagine most desktop users would somehow do that through a GUI which probably uses dbus these days. At work, I use kpasswd to change my Windows Domain password. On a machine where I had root access, I’d just run passwd as root if I wanted to change my non-root password.

John Brown • February 1, 2022 11:12 PM

Setuid isn’t a problem. The continuing existence of Lennart Poettring and his software is.

SpaceLifeForm • February 2, 2022 5:46 AM

@ RandolphLe, John Brown

On a Debian box (I am doing this on buster), become root in a xterm.
If you become root via su, make sure you do it as su –

then

cd /usr/bin

ls -ls login su passwd

ldd login su passwd

Then, run the login command while already root. Notice anything?

It’s weird that while login does not have setuid bit set, both su and passwd do.

The complexity is stupid.

I do not want to do this at the moment, but I need to experiment some more on this without X11 running. The problem should still occur at console level, but maybe it does not.

Even more strange. In an xterm (not root), if I try to run login, I get:

login: Cannot possibly work without effective root

So (as root), I secure the login binary with the setuid bit on, and
then again in an xterm (not root), if I try to run login, I get:

No utmp entry. You must exec “login” from the lowest level “sh”

That makes a bit more sense. But, something is wacky.

Clive Robinson • February 2, 2022 10:18 AM

@ SpaceLifeForm,

The critical ones are login, su, and passwd.

Even they don’t need to be…

It’s a “root of trust” issue. Back in the 1960’s computers did not have the resources to do hardware security, nor was RSA etc a reality so they had to do it some other way…

So they made the kernel and the init process privileged and everyone else not. They worked on the idea that the system would boot securely, which without networking back then and computers costing a “Kings Ransom” thus given plenty of physical security was a not unreasonable assumption.

But times change and so does the environment and the things in it.

We can now build a “Hardware Security Module”(HSM) sufficient for the most exacting security requirments in little more than a chip (see mil spec GPS receivers). More importantly PubKey crypto enables us to build some more interesting devolved “root of trust” structures that work in networked environments.

Yes things needed to change in the *nix world, but “systemd” and it’s desire to “own the universe” is not the right solution.

Whilst it is in theory possible to make something “be all things for all needs” making it even moderatly secure is nit, as systemd is proving.

And when it does go wrong trying to sort things out with systemd, is beyond all but a few people… So not the best way to go about things.

Oh and as I’ve noted, it’s a way to get “lock-in” by slowely creeping up on you. The complaints being made against Apple, Google and others over their “walled gardens” is just going to happen again due to systemd if we do not remain alert to the danger.

RandolphLe • February 2, 2022 1:05 PM

We can now build a “Hardware Security Module”(HSM) sufficient for the most exacting security requirments in little more than a chip (see mil spec GPS receivers). More importantly PubKey crypto enables us to build some more interesting devolved “root of trust” structures that work in networked environments.

Plan9 (with Factotum) did it 30 years ago without public-key crypto, shortly after Kerberos had done similarly. A hardware security module shouldn’t be strictly necessary, because it’s relatively rare that anyone attacks a computer’s security (other than seized phones) through its hardware. It’s our obvious inability to produce secure software leading us to think maybe hardware could do better; except all this “hardware” is just software running on another processor, and people seem to be moving back away from hardware in favor of “fTPM” (a software-only TPM running in some special CPU mode to protect itself from the OS; were the OS actually secure, we wouldn’t even need that). In other words, it’s not a shortage of tools or theories holding us back.

The CHERI project looks to me like the most promising and practical way to restrict and manage privilege within a single computer. Linux is still using ‘unsigned long’ and u64 for virtual addresses, even in new userspace ABIs, which will make it needlessly difficult to integrate (see UCAM-CL-TR-947), but the CHERI group have ported FreeBSD and some other popular and security-relevant software. Formal verification à la seL4 is cool too, but few people view it as practical right now.

With regards to blaming particular groups or projects for this or other security lapses, I tend to embrace the philosophy of aircraft/rail security investigators: look to determine the causes (technical, culture, etc.), so as to avoid similar incidents in the future, rather than trying to ascribe blame or liability. I see complexity as a leading one whether we’re talking about setuid binaries or polkit/dbus/systemd/etc. With setuid, the ease of finding and neutering these binaries is a point in its favor, but the amount of state copied from unprivileged to privileged context works strongly against it; few if any programmers seem fully aware of all such state, which is why I say it should go away entirely. (It’s rather telling that libc implementations could’ve detected and rejected “bad” state when euid!=uid decades ago—argc==0, duplicate keys in the environment, unexpected signal handling, FDs connected to questionable things, dlopen() before dropping privilege—and still don’t. Even OpenBSD’s, despite CVE-2006-6164 etc. Even the stuff Matt Bishop warned about in 1985.)

Interprocess communication mechanisms like dbus are far simpler for programmers to use securely, particularly if deserialization is already handled, though it seems few sysadmins know how to audit and limit the set of available privileged calls. And then there’s polkit, which I’m not sure anyone other than the author really understands. (Sometimes, udisks would decide not to let my “session” use it; I never solved that nor found anything but ineffective cargo-cult suggestions for fixes. Nobody provided any fruitful suggestions on how to debug such a thing, nor enough theoretical basis for anyone to figure it out. Occasionally it did fix itself…)

name.withheld.for.obvious.reasons • February 2, 2022 6:45 PM

@ RandolphLe
I appreciate your willingness to beat your head against a rock. Many of us have industry, and surprisingly, travel scars from a repeated attempt to make trustworthy computing possible. In the first part of the new millennium for example, Microsoft hemmed and hawed over ISO 15408 standards inferring that it impeded the company’s competitive business operations. It was shortly thereafter a executive level security officer was recruited to improve Microsoft’s product reliability and security posture. And posture, a word that suggests a physical orientation more than it does an application of policies that improve product reliability.

But since Microsoft’s slow adoption of basic industry standard practices, other players in other markets took on Microsoft’s “make the customer the alpha tester” model of product release. It has been rapidly downhill ever since. When ISO 27001 was adopted this marked a significant departure from previous policy platforms. But with all these changes, the lack of formalism from the programmatic systems continue to harm any efforts to provide better solutions.

One issue is in the hardware manufacturing and fabrication process is the “re-engineering” of platforms or systems of production. Pre-production plans and testing fail to flush out the inherent risk related to the dynamism of a soft/hard solution set. Where hardware platforms, unless rigorously designed and developed, match the more destructive features of the software industry. One only has to look at the automotive or industrial manufacturing sector to see how TTM, ROI, and shareholder value compete with product reliability…guess which wins out, every time.

I understand that Clive and myself are on the same page, stepwise development and production from known discrete systems models and reiterate sufficiently to bring the hardware forward. It has been an endless stream of whack-a-mole that always leads back to the hardware. Hardware inspection is crucial, determining what the physics observed with performance and results without guessing what happened should be a thing.

Add to that the hubris of governments to intervene in the manufacturing, making demands of industry whether in telecomm or computing to cooperate in “added features” and you find yourself here.

Jesse Thompson • February 7, 2022 5:48 PM

@Clive Robinson:

What is the VALID business case for connecting this system to externally available communications?

This feels too much like chasing wrinkles across the carpet, Clive. What is the valid business case for using any electronic technology at all? What is the valid business case for being in business?

From a forest view, if “connecting all the things all the time” had no valid business cases it wouldn’t be done so ubiquitously. There is demonstrably profit to be had in not having to hire extra human beings to sit in front of physical servers at all of one’s varied business locations — or to do all the work physical servers might otherwise do by hand.

Information still needs to flow, so changing how it flows doesn’t buy you anything magical.

So Server A can’t talk to Server B now, and you have to have Matt from accounting call up Jeff from sales and read numbers off of the screen (or out of the ledger book) to him instead. What protection does that buy you?

Social engineering remains one of the primary penetration methods in targeted attacks, because personnel are one of the weaker points in security. I call up Jeff and pretend to be Matt instead of calling a setuid executable and pretending to have authorization that I lack. Jeff isn’t reporting any of these conversations to rsyslog, either.

@John Brown

Setuid isn’t a problem. The continuing existence of Lennart Poettring and his software is.

Porque no los dos? It sounds to me like they are cut from the same cloth, after all.

And its funny when I read about Poettring’s complaints about open source culture in general and Linux in particular. He’s not strictly wrong. He just fails to grok that he gives at least as much of that toxicity as he gets.

@echo, what is the deal with OSS culture anyhow? It can’t be solely about boys toys, and I’m not on board with the “gen X nerds are literally hitler” meme I’m seeing floating around social media.

Speaking as one myself, I make the statment that negotiating and understanding social boundaries is harder than it’s ever given credit for (and moreso when neurodivergent) and certain people should stop taking it so callously for granted. :/

SpaceLifeForm • February 8, 2022 7:33 PM

@ Clive, ALL

February 7, 2022 10:53 PM

hxtps://www.schneier.com/blog/archives/2022/01/twelve-year-old-linux-vulnerability-discovered-and-patched.html/#comment-399863

Appears to have been moderated, I’ve only seen a limited part in my local copy of “100 comments”.

I am not surprised at all. It may have touched on ongoing investigation angle, sources and methods,

I see commenters here partially quouting previous comments that I never saw. This occurs more often than you would guess.

Also, the MITM just may be hiding stuff.

Except the spam to old articles.

Fingerprinting.

SpaceLifeForm • February 8, 2022 9:15 PM

@ Clive, ALL

I had at-ed you and jesse. Both full name.

Porque no los dos?

Why not both? Did that trip filter?

Or is it Metadata tracking?

Only your hairdresser knows for sure.

Clive Robinson • February 9, 2022 5:02 AM

@ Jesse Thompson, SpaceLifeForm,

This feels too much like chasing wrinkles across the carpet,

I’ve never played that game, so I can not comment on how it feels.

With regards,

Information still needs to flow, so changing how it flows doesn’t buy you anything magical.

There is a considerable difference between “controled” and “uncontroled” when it comes to communications, and even more so between “mandated” and “unmandated” communications.

Just having a computer “open to the Internet” is the worst combination, and most “office PC’s” are little better protected than “home PC’s”.

There is no “magic” involved with setting things up correctly.

But ask yourself what the quantifiable benifit is of having an Office PC of say an accountant with full external web access?

Darn little at best, in fact it’s way easier to make the opposite case that it is detrimental to the job they do, and to the organisation in vary many ways, including having them cut and past confidential information out the door.

People like to “trust” others who are a little more cautious “trust and audit” some who are considered professionaly paranoid “trust and verify”. Me I say “Why trust?” “Why audit?”, “Why even verify?”, it’s way easier and a darn sight less costly to “mitigate”.

If you disagree well that’s your choice, but from my point of view, you only give a computer access to any kind of external communications when you’ve done the full business case as the first step. Because if the business case shows no or nebulous, or even little benifit, why got to the expense and risk of connecting it. But even if the business case is valid and does show there is a benifit you get specific information not MBA mantras. This specific information you can do an analysis on for not just how to mitigate the PC it’s self, but also how to mitigate other computers it is directly or indirectly connected to, therby limit risk of two types of attack,

1, An outsider in the network moving sideways etc.
2, An insider betraying the organisation for some reason.

As I’ve said before, “my computers” are not connected to anything other than a physically isolated and physically connected set of networks and none have wireless / bluetooth or similar in them. Yes I take security precautions with them the same as if they were connected to external communications, just in case something does “magically” appear via some unknown second or third party.

One such set of precautions I take and have done for decades is physical / hard border protection. You can not get “front pannel access” unless you know the combination and the ward profile of the key to the locks on the container and they are alarmed as is the container. Also the network connection is “mechanically switched” as is the power, at the computer inside the physical issolation barrier, with instrumentation again with alarms.

To many this might appear extream, or paranoid, but I have reasons, not least of which is if you do not protorype and experiment, then you are not doing things professionally.

Whilst “Book knowledge” helps your thinking as does “water cooler comments”, there is a lot of things you will miss unless you experiment with suitable test kit.

It’s why I’ve been advising Pen-Testers for over a decade to get to understand and be very familiar with “Software Defined Radio”(SDR) and all the capabiliries it has.

For instance, you can get software for your laptop that will scan the WiFi and Bluetooth via the inbuilt interfaces but what about say Zigbee? Or WiFi that has been “frequency shifted” outside of your laptops coverage?

Add an SDR via a USB dongle and put other software on and now you do have coverage…

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.