back to article Linux distros haunted by Polkit-geist for 12+ years: Bug grants root access to any user

Linux vendors on Tuesday issued patches for a memory corruption vulnerability in a component called polkit that allows an unprivileged logged-in user to gain full root access on a system in its default configuration. Security vendor Qualys found the flaw and published details in a coordinated disclosure.  Polkit, previously …

  1. Anonymous Coward
    Linux

    Eyes

    While Linux and Open Source do have a considerable advantage over closed operating systems and software because of all the eyes on the code, this points out that the eyes are mostly looking at the present and future.

    The Polkit bug went unnoticed for 12+ years because the initial eyes missed it and subsequent eyes assumed what was already there was fine.

    We have efforts to maintain old code (xkcd's random person in Nebraska)

    But a concerted effort is needed to fund and implement a review of old code as well.

    1. Snake Silver badge

      Re: Eyes

      That's a dramatic statement of policy (and marketing) shift in F/OSS, and a good one. Recent years have proven that "We have more eyes on the code!" only means 'We have more eyes directed towards our [future] goals, but not necessarily reviewing our past work'.

    2. david 12 Silver badge

      Re: Eyes

      Where Linux and Open Source do NOT have an advantage over Windows is in the (cultural) dependence on Environment Variables.

      I got sick of pointing out that for Windows builds, other methods offered more secure alternatives: I was assured that the use of environment variables was safe because the user was not privileged.

      1. Anonymous Coward
        Anonymous Coward

        Re: Eyes

        "Where Linux and Open Source..."

        Your first sentence... so much wrong.

        "I got sick of pointing out..." <-- this

        1. david 12 Silver badge

          Re: Eyes

          If, as seems to be the case, you are alleging that Linux in particular, and Open Source in general, do not place 'environment variables' in a more critical place than is the case for Windows and Windows application programming --- then you are only demonstrating your ignorance of Windows and Windows application programming

          1. Anonymous Coward
            Pint

            Re: Eyes

            "..demonstrating your ignorance of Windows..."

            WOW! I usually don't tear up like this, but thank you... thank you very much! Have a great day!

    3. jake Silver badge

      Re: Eyes

      Don't make mountains out of molehills. It's just another bug. It has been patched, and faster than commercial software usually is, by a wide margin. No more problem.

      There will be more bugs in ANY codebase as large as a Linux distribution. When found, they will be patched just as quickly as this one was.

      ::shrugs::

      1. Skiron

        Re: Eyes

        Yes, and to be honest, who will be affected by this? I doubt any business allows any old user to connect to a Linux terminal, and even if they did that person still has to have the knowledge to manipulate it to get root.

        1. sabroni Silver badge
          Thumb Up

          Re: I doubt any business allows any old user to connect to a Linux terminal

          Yes! This is how you do security!

          1. jake Silver badge

            Re: I doubt any business allows any old user to connect to a Linux terminal

            That was quite kind and gentle of you, sabroni. Mellowing with age?

            1. TimMaher Silver badge
              Windows

              Re: I doubt any business allows any old user to connect to a Linux terminal

              Yes but it’s the young users who are the most dangerous.

        2. John Riddoch

          Re: Eyes

          Why do we care about this bug that allows a user to run unprivileged code? It couldn't possibly be used to do anything nasty...

          The point is that once you have an unprivileged shell on a target machine, having a method to escalate to root is the next step. The best crackers don't rely on one vulnerability, they chain together multiple vulnerabilities to get where they want to be.

          1. Anonymous Coward
            Anonymous Coward

            @John Riddoch - Re: Eyes

            Yeah, but let those hackers work as hard as possible and spend a lot of time to get those root privileges. Why offer them an easy way ?

            Remember, defence also includes retarding the attackers as much as possible.

        3. Anonymous Coward
          Anonymous Coward

          Re: Eyes

          "Yes, and to be honest, who will be affected by this? I doubt any business allows any old user to connect to a Linux terminal, and even if they did that person still has to have the knowledge to manipulate it to get root."

          But there are a reasonably large number of places which do have multi-user systems for valid reasons, and those users aren't always entirely trustable (eg, universities). And even an 'inquisitive' user on a box where they are the only user could still get up to some naughtiness if they could become root.

          1. Anonymous Coward
            Anonymous Coward

            Re: Eyes

            apt purge snapd -y

            1. Anonymous Coward
              Anonymous Coward

              Re: Eyes

              WTF? When did rm get replaced with bloatware?

              1. jake Silver badge

                Re: Eyes

                "When did rm get replaced with bloatware?"

                Not replaced with, augmented by. Was the logical answer when bloatware authors decided to scatter files in so many sub-directories that using scripts to remember where they are became necessary.

                For rather small values of logical, of course.

                Sad, innit?

                1. phuzz Silver badge

                  Re: Eyes

                  when bloatware authors decided to scatter files in so many sub-directories

                  So since at least 1979 when Unix 7th edition was released then?

                  1. jake Silver badge

                    Re: Eyes

                    Yeah, but back then bloated monstrosities like EMACS (sorry, rms!) were the exception, not the rule. Even Sendmail was four years out in '79 ... and Apache's httpd was 16 years away!

                    Argumentum ad absurdum usually makes one look silly, and upsets the pig.

        4. Terry Barnes

          Re: Eyes

          Once an exploitable vulnerability exists all that is required for it to be exploited is time.

        5. doublelayer Silver badge

          Re: Eyes

          "I doubt any business allows any old user to connect to a Linux terminal, and even if they did that person still has to have the knowledge to manipulate it to get root."

          Businesses do allow users to connect to terminals. True, few of them are still using the one big computer that does everything and everyone's accounts are launched on it, paradigm, but root on one server can be used to collect data useful in breaking into others.

          The other side of this is that it might not be someone using this to attack a system that they've already been granted non-root access to. If an external attacker manages to get into a system through some other exploit, but they only have access to a particular user's area, they could use a bug like this to get somewhere else.

        6. vogon00

          Re: Eyes

          person still has to have the knowledge to manipulate it.

          Knowledge is a rarity these days.....pasting from the WWW (stackoverflow et al) seems to be the current substitute. I wonder how many people who use/abuse stackoverlow actually understand what a stack overflow really is?

    4. John Robson Silver badge

      Re: Eyes

      Because there is no way that this would have gone unnoticed at Microsoft or Apple - we never hear about bugs in *their* code.

      1. Handy Plough

        Re: Eyes

        Just, wow! This is exactly the arrogance of the 'many eyes' apologists! Just think of the shit storm that there would be were this Windows/macOS!

        Think of the many 1000's of unpatched servers out there affected by this. FFS people, drop you religious zeal and see the bigger issue; FOSS, while giving you the ability to review the code, is no better than closed source, because the many clearly do not review the code!

        1. Graham Cobb Silver badge

          Re: Eyes

          No, that is simply a false statement. FOSS, with the ability to review the code, is much better than closed source for two very important, and objectively true, reasons:

          1) Many people can, and do, review code. Of course, not all code gets reviewed very often - particularly older code - and reviews certainly don't spot all bugs. But much code gets reviewed and many bugs are spotted.

          2) Once a bug is found, many people do review the code, review and improve the fix, review other similar code in other programs, add this issue to their internal list of gotchas to avoid, add regression test cases to automated testing, etc. And, of course, if the bug is important to them they can fix it themselves if they need to - for example if they are running an old, unsupported version for some reason.

          1. Anonymous Coward
            Anonymous Coward

            "Many people can, and do, review code."

            That's plain wishful thinking. Actually, those reviewing the code now is vulnerability hunters, often for profit. Those reviewing code on a voluntary basis look to be very few. So a bug can the there for twelve years. And that happens with what is the most financed FOSS project - think what happens with the others with little or no resources.

            Closed source code is reviewed as well because there are cases when people are actually paid to do that. Closed source doesn't mean it is stored strongly encrypted when only the compiler can see it. It just means it is not publicly published.

            Bugs are fixed the same way in open and closed source code - often, the developers are the same.

            "they can fix it themselves if they need to"

            Another myth - most users don't have nor the skill nor the tooling to fix code themselves, especially old versions. Sure, they could paid someone if they could find him or her.

            1. Graham Cobb Silver badge

              Re: "Many people can, and do, review code."

              You misunderstand. I am not saying that every piece of FOSS code has been reviewed by many people. Although I am fairly confident that for modern code it gets reviewed by many more people than equivalent proprietary code does (as major FOSS projects nowadays impose code review obligations on code changes that result in many more reviewers than the 2 or 3 in a typical vendor's development team). What I am saying is that when comparing large codebases, the FOSS implementations generally get more review than the proprietary implementations.

              No single function necessarily gets a lot of review in either environment. And there are plenty of bugs in 12-year-old code in both environments. However, bugs are much more likely to be found, fixed, and stay fixed in the 12yo FOSS code than in the proprietary code.

              How many people have ever even seen the equivalent "change mode to root" switching code in Windows? Compared to the number that have now seen it in polkit? Hopefully there isn't a similar bug in that Windows function. We can now be confident that there isn't a similar bug in any of the similar functions in the major FOSS world because this bug will have prompted many people to look at that code in polkit, and the similar code in sudo, su, and other FOSS implementations.

              The "many eyes" effect is very real. It isn't perfect at all, but it drives an ever improving code quality level that just can't be matched by proprietary teams.

              1. Anonymous Coward
                Anonymous Coward

                "bugs are much more likely to be found, fixed"

                Have you any evidence of that? Just saying it doesn't make it real. Moreover when you can make money by finding exploitable vulnerabilities only, how many bugs which aren't vulnerabilities aren't reported?

                "generally get more review than the proprietary implementations."

                Again, have you evidence of that? Moreover, is the number of review that matters, or the quality of them?

                "Compared to the number that have now seen it in polkit?"

                Those numbers might not be that much far apart. The problem is exactly that. But their own developers, there are not many other people looking at the source code of most projects, especially those with enough skills to be able to quickly spot bugs.

                "The "many eyes" effect is very real."

                Actually, the bugs that are emerging in these days look to show it is not real at all. Software with too few developers and little support. People using code and giving nothing back - not even bug reports, and no fixes. The problem is the lack of resources and incentives, and the "someone else's problem" attitude.

                1. Graham Cobb Silver badge

                  Re: "bugs are much more likely to be found, fixed"

                  You obviously aren't familiar with the process of modern FOSS code review. It isn't about big security issues like this - those are the ones that get headlines but the "many eyes" process doesn't just (or even mostly) help with that.

                  I am not a kernel developer but I follow the btrfs development mailing list. Every patch to btrfs goes through that list. Every patch is reviewed by several of the key developers. So far, that is similar to the proprietary process (except that the reviewers work for different companies - itself a small benefit). But every patch is also reviewed by a lot of other people - some, like me, are just interested techies - some are very experienced system managers who have dealt with bugs in btrfs for many years, build their own kernels, and help track down problems - some manage the largest btrfs deployments in the world (think about places like Facebook) and have a lot of experience of how things fail in their world. All these people contribute to the review and the testing - before the code is even sent to Linus for the rest of the world to see.

                  The effect is that most of the bugs found by these people are not major security issues - they are functional issues, deadlock issues, hangs, performance slowdowns, etc. Many, many of those are found by interested parties in the community, long before the code gets out.

                  Personally I have only contributed one patch to btrfs. That was to fix a small functional issue - that probably would only affect less than 1% of users (still a lot!). But I have participated in other discussions and testing that have resulted in improvements to the code.

                  Yes, there are many FOSS projects that don't get the review, testing and support that the kernel does (and even parts of the kernel that don't get much interest - I submitted a long-asked-for improvement to a small and unloved part of the kernel and it took months to get it reviewed and accepted) and we need to improve that. But that is nothing to do with the "many eyes" issue.

                  FOSS has plenty of faults but there is no point trying to deny that the "many eyes" process is an important advantage for FOSS - which has to be weighed against the various disadvantages. This particular incident is a great example of the considerable benefit it gives.

              2. Terry Barnes

                Re: "Many people can, and do, review code."

                “ I am not saying that every piece of FOSS code has been reviewed by many people. ”

                For a building to be secure, every door must be locked.

                You are as secure as your weakest link, not your strongest.

          2. Terry Barnes

            Re: Eyes

            Point 2) is only true if the person who finds it has good intentions. Don’t presume that people looking for mistakes are doing so out of the goodness of their hearts.

        2. John Robson Silver badge

          Re: Eyes

          "Just, wow! This is exactly the arrogance of the 'many eyes' apologists! Just think of the shit storm that there would be were this Windows/macOS!"

          Erm - it's regularly Windows, and slightly less frequently MacOS.

          There is no shitstorm, nor even a significant murmuring.

          At least here we can patch any systems, including any that are out of official support - and we don't need to take on board 47 other "essential" fixes which ech introduce a dozen changes to other bits of the system just to grab this one.

          FOSS isn't perfect, noone says it is - but this isn't something which highlights the benefits of closed source as some seem to claim. It highlights the requirement to have defense in depth.

        3. Bob9911

          Re: Eyes

          This says it all. Open source does NOT equate to better, more secure code. As long as people are coding things, there will be bugs

          1. dafe

            Re: Eyes

            I think there was a baby in that bathwater.

        4. Anonymous Coward
          Anonymous Coward

          @Handy Plough - Re: Eyes

          Sorry, pal, but for the money I'm paying to Apple and Microsoft that sh%t storm would be entirely justified.

          Besides, in case you were not aware, there's a well known security mantra saying "Trust but verify". Contrary to code from Microsoft and Apple, nobody is preventing you to check and validate OSS code before use, you said it yourself. Now to add insult to injury, on top of being guilty for those bugs, the OSS developers are guilty of not reviewing the code for you.

          I don't mind for proprietary software to be better than Open Source. It's all about making the right choice based on your needs.

    5. Dan 55 Silver badge

      Re: Eyes

      The Polkit bug went unnoticed for 12+ years because the initial eyes missed it and subsequent eyes assumed what was already there was fine.

      I'd have thought Red Hat which has the money to constantly run automated fuzz testing on every one of their executables would have been doing this for years. Sadly not, they're as bodgy as the rest of us.

      1. Anonymous Coward
        Anonymous Coward

        Re: Eyes

        >Red Hat which has the money to constantly run automated fuzz testing

        Yeah - but if Lars is the one parsing the output he'll discard anything that doesn't confirm his ideas.

    6. Jaybus

      Re: Eyes

      And if we can't afford a review of all old user-mode code, then at least a review of code designed for SUID root might be in order.

  2. Skiron
    Unhappy

    Polkit

    This is another RedHat thing that got foisted on to everybody else, isn't it?

    1. Gene Cash Silver badge

      Re: Polkit

      It's another systemd abomination apparently, but according to Wikipedia, Fedora was the first to have it.

      According to the Debian wiki "it is sometimes referred to as "the sudo of systemd".

      1. jake Silver badge

        Re: Polkit

        Except it was in development before the systemd-cancer existed.

        1. Graham Dawson Silver badge

          Re: Polkit

          Except it was completely re-written and renamed in 2012, after systemd had established itself. It broke API compatibility in order to better align with the systemd way of doing things, and likely simplified the exploitation of this bug in the process.

          1. jake Silver badge

            Re: Polkit

            Bastardization of the concept doesn't negate the origin.

      2. Dave559 Silver badge

        Re: Polkit

        And Wikipedia wisely says (note the second sentence!):

        It is also possible to use polkit to execute commands with elevated privileges using the command pkexec followed by the command intended to be executed (with root permission). However, it may be preferable to use sudo, as this command provides more flexibility and security, in addition to being easier to configure.

    2. Anonymous Coward
      Anonymous Coward

      Re: Polkit

      interestingly enough, AWS Linux (based on centos) doesnt have pkexec.

      1. jake Silver badge

        Re: Polkit

        How about polkitd?

    3. AdamWill

      Re: Polkit

      It's kinda weird constantly seeing this argument *in the same week* as people are also moaning about how nobody is paying F/OSS developers.

      Yes, lots of important F/OSS things are written by people who work at Red Hat. You know why that is? Because Red Hat hires people who write important F/OSS things and pays them to do it. You know. That thing people keep saying should be happening more. systemd is a "Red Hat thing that got foisted on everybody else" because Red Hat saw that Lennart was writing important stuff (at the time, pulseaudio and avahi) and hired him to do it full time. polkit is a "Red Hat thing that got foisted on to everybody else" because Red Hat hired a bunch of the GNOME developers in order to let them work on GNOME full time.

      Would F/OSS be in a better place if Red Hat *didn't* hire people and pay them to work on important F/OSS projects full time? Would you prefer that?

      1. Paul Crawford Silver badge

        Re: Polkit

        Maybe - but really it is the arrogance of certain individuals who want everything re-written in their own image.

        So stuff that was OK/secure many years ago gets re-implemented and a whole new set of bugs created, and since much of this is PID-1 stuff, has root vulnerabilities.

        1. AdamWill

          Re: Polkit

          The point of polkit is to *reduce* the amount of stuff that can have root vulnerabilities. At a very big-picture level, the point of polkit was to replace consolehelper/userhelper. The major limitations of consolehelper/userhelper were how coarse it was - it ultimately just decided whether a user was allowed to run things as root or not, and ran the entire thing as root if the user was allowed to do so. So back in Ye Olde Days when some people seem to think everything was so highly secure, a graphical admin tool that needed root privileges for something - say, a user account creation tool, or a keyboard layout configuration tool - had to be run entirely as root in order to work. Everything it did, it did with root privileges. And if a user needed to be able to run that tool, they *also* ipso facto had to be given the ability to run anything else as root. No finer-grained policy was possible.

          One major advantage of polkit is that it allows for much more fine-grained policies than "can this user run things as root or not?" The other major advantage is that it makes it much simpler for applications to run *mostly* unprivileged and then gain only specific necessary privileges for operations that need them. The user management tools in KDE and GNOME can run mostly as the user that runs them, then gain only (for example) the privileges they need to create user accounts, when the user who's running them actually clicks on the "Create User" button. If they don't do that, the app doesn't try to gain any privileges at all.

          pkexec isn't really the main point of polkit (which is why, as another commenter noted, it's possible to ship polkit without it). It's not like it exists because someone decided they wanted to rewrite sudo. No distro that I'm aware of actually suggests using pkexec interactively to run things as root (they all recommend sudo for that). It was initially included, AFAIR, to accommodate the move from consolehelper for apps whose authors weren't willing or able to rewrite them to the better model of doing things; the idea was it was better to accommodate those apps *somehow* so that it was possible to get rid of consolehelper, rather than keep it around forever. (If you're wondering why things couldn't be rejigged to just run those apps via sudo, it's a good question and I don't remember for sure; I think it was to do with wanting to keep the experience of launching the apps from a menu and a graphical authentication prompt appearing, but I might be forgetting something).

          It's definitely pretty bad that pkexec turned out to have this bug all along. It might even be a reason for distros to reconsider whether they still need to ship pkexec (I don't know, off the top of my head, if there's an obvious reason to keep it around at least by default any more).

      2. Joe W Silver badge

        Re: Polkit

        I sort of agree - but completely changing the philosophy of how stuff should work (do one darned thing and do it well), there are programs that want to be the be-all-end-all-thing. Having these pushed aggressively upset many people - there are problems with the monolithic approach, and the interconnected parts of the thing, and (for me) finding the cause for problems and then resolving them is much more complex (and aggravating - why does component $X influence component $Y?!) than it used to be - maybe it's my age showing.

        The problem is that it is conceivable there do exist components / programs that should be pushed from certain vendors, and that would make everybody happy in the long run, making sysadmins' tasks easier, removing dependencies or old cruft - alas, fixing the old stuff is not sexy.

        (and don't get me started on pulseaudio...)

      3. Doctor Syntax Silver badge

        Re: Polkit

        Right idea, bad choice.

    4. Steve Graham

      Re: Polkit

      It's a mechanism for bypassing normal Unix-style permissions. I've always regarded it as an accident waiting to happen, and make sure that none of my Linux boxes have it.

    5. Warm Braw

      Re: Polkit

      The basic problem here is that there is a historic all or nothing privilege system and the mitigations for that (like polkit) involve running significant chunks of code in an elevated privilege context in which any error is potentially very serious.

      A long-standing bug with similar consequences was found in sudo.

      I don't think RedHat is responsible for a fundamental design error made in the 1970s - or possibly earlier.

      1. Doctor Syntax Silver badge

        Re: Polkit

        As far as I can remember so long ago the basic design, or at least V7 which was my earliest version, was a bit more nuanced.

        Yes you could use root to do things such as administer printers but you could also use a different UID to do that such as lpadmin for the printers. "Do one thing and do it well" in operation.

        It meant that in the case of an installation with multiple operators the privileges could be shared out appropriately by giving an operator the specific passwords they needed.

        That seemed to be Too Complicated so everyone tended to get the root password whether they needed it or not.

        That was Too Insecure so then we got sudo and pkexec.

        1. jake Silver badge

          Re: Polkit

          "It meant that in the case of an installation with multiple operators the privileges could be shared out appropriately by giving an operator the specific passwords they needed."

          Still can, if you know what you are doing. Slackware makes it (relatively) easy.

      2. Peter Gathercole Silver badge

        Re: Polkit @Warm Braw

        Given the history of UNIX, and the fact that the initial movers and shakers had got completely fed up with some of the design extremes that were going into Multics, I would say that in the initial work providing the split between privileged and non-privileged was a design choice, not a design error.

        As I understand it, the privilege model of Multics, although good in principal, put far too much demand on the systems of the time. And the UNIX privilege model fitted in well with the USER and SUPERVISOR hardware privilege model of the PDP-11 system, which fed into a lot of UNIX and C design.

        Should it have been changed? Well, it was extended (the concept of groups was added to UNIX quite early, but which the full scope has been forgotten over the years). UNIX does not have to be all-or-nothing, but it has always required to have one user which could do everything. It's the implementations that has made anything that was not being run by an ordinary user run by root, but it does not need to be like that.

      3. dafe

        Re: Polkit

        Polkit is not a mitigation of user and group based capabilities.

        It completely by-passes that system for the purpose of privilege escalation, and while the filters can be as fine-grained as any setuid command, Ulrike sudoers polkit's always run as root. It's a root-kit.

        1. AdamWill

          Re: Polkit

          "Ulrike[sic] sudoers polkit's always run as root. It's a root-kit."

          This isn't accurate. polkit itself doesn't run as root. The design of polkit is, as the documentation says, that it "provides an authorization API intended to be used by privileged programs (“MECHANISMS”) offering service to unprivileged programs (“CLIENTS”)". The "privileged programs" can be privileged in any way - that could mean that they're running as root, but it could also mean that they have much more restricted elevated privileges (by running as some other user with specific privileges, or using a more advanced mechanism like capabilities). polkit itself is effectively just a "referee": its job is to help the privileged program decide whether it should offer a service to a less-privileged one.

  3. bazza Silver badge

    CLI strikes again...

    This is not the first time that a program has caused havoc by failing to parse its command line parameters properly.

    Given that there are myriad ways in which interfaces can be automatically generated from a specification, with little room for abuse in the implementation (especially for ASN.1, JSON, and XSD/XML done properly), it is ridiculous that we still cling on to the CLI as a way of having one program call another. There is a lot of advantages in using something like Dbus compared to passing parameters on a CLI.

    1. Roland 2

      Re: CLI strikes again...

      Agreed that config/argument parsing should be done by a well tested library, but nothing much to do with CLI arguments vs. json config files.

      There are plenty of poor ways to hand parse a config file too, with associated security issues.

      Using an adequate library (think argparse in python, or clap in Rust) is not only safer, it also brings good error messages in case of misuse, arguably better that a security hole.

      1. bazza Silver badge

        Re: CLI strikes again...

        Good arg parsing libraries are useful but don't solve the whole problem. There's no good way for the caller and program to k ow for sure that they're using the same understanding of what args mean what. Generally it's up to a human to t read a man page, see what's changed.

        This matters quite a lot.

        For example there was some years ago a HDD encryption package for Linux which was the usual collection of scripts calling other scripts and programs. Problem was that the program that did the actual encryption changed its CLI but not in a way that broke the scripts. The result was that null passwords were used to encrypt data, regardless of what the user typed in.

    2. Androgynous Cupboard Silver badge

      Re: CLI strikes again...

      Oh please. Code generated automatically from a spec language is a filthy thing. It's so abstracted away from the norms of whichever language it's written for that it fails the "principle of least surprise", which is one of the most important things a developer needs to write good, secure code.

      I say this from the perspective of both 30 years of coding and a recent battle with the Xero API, which is generated from a spec language, and has been completely reworked several times since inception (requiring corresponding reworks of my integration, when I have better things to do). It's my current poster child for how not to do API development.

      Plus you mentioned ASN.1 and didn't wash your mouth out. I've seen abuse of ASN.1 that would make the Church blush.

      1. Graham Cobb Silver badge

        Re: CLI strikes again...

        Ah. ASN.1 BER. The memories.

        In the late 1980's I implemented a big and important (for us, at the time) protocol specified in ASN.1. I played with the ASN.1 compilers of the time and gave up on getting any useful code out of them. But I did create my own library (for my application) of tools to parse, check and generate valid ASN.1 BER (although the semantics of the messages were all handled in ordinary code). And I wrote lots of regression tests just to check the validation (and added to them if I found a bad message that got through).

        The one massively useful thing which ASN.1 encoding gave me was that I could (and did) check every message which arrived for encoding correctness, with arbitrary-sized messages, removing issues like incomplete messages, buffer overflows, etc from that code. After that initial check, I knew I had the whole message in memory, that there were no incomplete sequences, no incorrectly formatted integers, etc. I also applied some of my own implementation-specific rules (such as requiring that every integer would fit in 64 bits, and imposing maximum lengths on certain types of sequences and object IDs). All before any of the semantic processing started.

        ASN.1 isn't user friendly, but it is implementor friendly. I assume (hope?) that the tools have got a lot better in the last 30+ years.

        1. Anonymous Coward
          Anonymous Coward

          Re: CLI strikes again...

          Well, if you're from the Java world the answer is a resounding "no" to your last question. BouncyCastle API is the usual approach, and it's hairy. ASN.1 is an amorphous blob of possiblities, so if you've set yourself the goal of covering all those possibilities, you're going to wind up with an awful lot of amorphous code.

          We used it for a time then did the same as you, jacking it in for our own ASN.1 parser. The fun part wasn't the parsing so much, it's the many "interesting" interpretations of the higher specs such as PKCS#7 or X.509 that have sprouted like mushrooms. For anyone that thinks X.509 is a "standard" in the modern sense of the word, I beg to differ.

        2. bazza Silver badge

          Re: CLI strikes again...

          Yes, the commercial tools have got a lot better in the last 30 years.

          You could do worse than take a look at the modern commercial tools, and the modern ASN. 1 standards. The commercial tools now have reasonable language support (C, C++, C++ using std lib, Java. C#, even Python). The ASN.1 spec now includes XML and JSON as wire formats (which gives interesting interop options). All major OSes and platforms are supported.

          OSS options are more limited. But the ESA has something called the TASTE framework, which is quite interesting. There's a fairly good OSS C implementation / compiler on GitHub too.

          You can these days have an agile, single version of the interfaceing truth specification in the core of one's project, and safely make late breaking significant interface changes for minimal risk and effort. You're relying on the tools to either deal with changes through recompilation, or pointing out where your interface spec change has broken something. Once you that pattern of working established, it's pretty slick and dev friendly, largely because you can minimise code review effort for such a change.

          Google Protocol Buffers gets a lot more attention, but doesn't have any notion of constraints on value or length. Which is a real pity because otherwise GPB is moderately useful.

          1. Androgynous Cupboard Silver badge

            Re: CLI strikes again...

            If you need to serialize arbitrary binary data I would highly recommend CBOR over GPB or Msgpack. Vendor independent, very good library support and simple enough to roll-your own if you prefer (I did). Plus it handles indefinite-length items, which makes it great for streaming.

            With application layers like COSE on top (basically JSON Web Tokens in CBOR) it's also starting to encroach on territory held by ASN.1.

      2. TheFifth

        Re: CLI strikes again...

        As someone who has also engaged in battle with the Xero API, I completely agree. When I was battling with it, the documentation was incomplete, most of it was auto-generated, and the examples included simply didn't work. I've noticed it's improving in that regard, but still has a long way to go. I've also had to rework the implementation many times too to keep pace with their constant shifting.

        1. Anonymous Coward
          Anonymous Coward

          Re: CLI strikes again...

          Yes, that documentation is an absolute joke. I ended up running their Jar through a decompiler so I could see the magic formula for the various constructs their code generated came up with.

      3. This post has been deleted by its author

      4. bazza Silver badge

        Re: CLI strikes again...

        There's a lot code generation tools around these days, they get used quite a lot. Things like Google Protocol Buffers are perhaps a bit more hipsterish than ASN.1...

        The C++ code generated by GPB is pretty horrific, but I think that that simply reflects the fact that C++ simply doesn't have the capacity or neatly express some of the concepts embodied in the GPB schema language. Generally I've found that higher level languages generally get neater generated code, because there's more the language can provide that the code generator doesn't have to implement for itself.

        Eg having a variable length array in C takes a ton of code. Even in C++, it's a bunch of code. C++ with the STL does a lot better, because now there's vectors and such. C#, Java and Python just have that sort of thing natively, and the code generator can just declare one.

        Things can still be problematic, eg a JSON schema can express something that is like a C union, but C# does not have unions, so the JSON schema code generators for C# that I've seen just refuse to implement it. Probably all is well in Python.

        No I didn't wash my mouth out! It's matured like a good wine, or Parmigiano cheese.

    3. Anonymous Coward
      Anonymous Coward

      Re: CLI strikes again...

      The biggest advantage in passing arguments via DBus rather than directly through the operating system is that you have a bigger attack surface. Exploiting parser bugs is no longer limited to newly forked processes, it can also affect already running daemons now, including the DBus daemon itself.

      1. bazza Silver badge

        Re: CLI strikes again...

        That's certainly true, if a parsing flaw is present. But if the parsing component is flawless, and rigidly so, then it's robust and won't let mistakes propagate. Dbus uses a schema driven code generator, I'm assuming with the need for interface parsing rigour in mind (though it lacks value constraints).

        It basically comes down to what's better, getting a single parser generator correct or there being a myriad different ways individual devs and libraries go about parsing. It's probably more efficient to focus on the single parser generator (per language).

    4. Lunatic Looking For Asylum

      Re: CLI strikes again...

      It's not the CLI.

      It's the usual suspects desire to have everything graphical in front of the CLI that's causing this.

      I really hate Red Hat for this very reason. When I build a system I don't want X installing on it, I don't want a graphical boot or install process, I don't want avahi (lets sniff round the network and look for shares and printers...) installing on it, I don't want graphical tools on it for basic system admin tasks. polkit et. al. is in place to allow circumvention of the command line and good system management practice.

      When I build a server I want nothing on it apart from the bare minimum required to perform its functions, everything extraneous to that just adds another attack vector.

  4. Paul Johnston
    FAIL

    Oh dear

    I know 9 is essentially in beta-ish and this is just a learning box, nothing in production but doesn't inspire confidence

    (base) [paulj@e-uxxmcasspj5 ~]$ cat /etc/redhat-release

    CentOS Stream release 9

    (base) [paulj@e-uxxmcasspj5 ~]$ ./cve-2021-4034--2022-01-25-0936.sh

    This script (v1.0) is primarily designed to detect CVE-2021-4034 on supported

    Red Hat Enterprise Linux systems and kernel packages.

    Result may be inaccurate for other RPM based systems.

    This script is meant to be used only on RHEL 6-8.

  5. Anonymous Coward
    Anonymous Coward

    Shudders at "learning" PolicyKit

    My introduction to LInux was Ubuntu, which I installed on a media server.

    It took me a long time (because the documentation was ... well lets leave it there) to work out why there were some programs that would not run in my NoMachine session - even though it was direct to the console.

    Eventually I found PolicyKit and the XML files where it defines what to do for privilege escalation.

    I actually wrote up my findings and posted them on the (now defunct) UbuntuForums

    Every so often I'd get a grateful email from someone else who had been similarly baffled.

    It was also an early introduction to the Linux community.

  6. FuzzyTheBear
    Pint

    Oook :)

    Before i read about it here i already had a libpolkit update applied. didnt know why it was there .. just glad to see the patch was already done before i read about it. :D As far as fixing problems is .. that's one for the team cheers

  7. Colin Guthrie
    Facepalm

    Policy can still let you down

    I remember a while back that I found a several years old bug in the policy file for a tool called sectool which was a RedHat thing. It's policy file ultimately gave all users the right to do things as root. So install a package to audit security and it messes up your security! Fun times.

    Polkit is handy overall tho'. Gives flexibility to run a restricted set of tasks very cleanly with defined API on the system/user buses (speaking to appropriate daemons running as other users etc). It's pretty clean (from a usage perspective) generally even if the JS interpreter might seem like overkill. Running commands via the CLI is just one use case for polkit - sudo certainly can't do 90% of what polkit can. The same policy mess up I found (which was pre the big polkit rewrite IIRC) could have just as easily been a file packaged in /etc/sudoers.d/ folder.

  8. fredesmite2
    WTF?

    Why do you broadcast this for ?

    " Let's reveal how you can fuck up a system "

    1. Doctor Syntax Silver badge

      Re: Why do you broadcast this for ?

      How about "Let's reveal there's an important upgrade to apply"?

    2. dafe

      Re: Why do you broadcast this for ?

      Those who want to fuck up your system already know from the CVS or had the exploit ready for over twelve years.

      Those whose system might get fucked up by this probably don't subscribe to the CVS.

  9. bombastic bob Silver badge
    Unhappy

    FreeBSD appears to be affected

    I checked the pkexec.c source (from a recent install) and it has the flaw in it. Also verified that under FreeBSD it's possible to use execve() with zero arguments causing 'argc == 0' (which is a valid condition as someone else pointed out). Assuming argc must always be >= 1 is just bad code.

    Fortunately, with the source available, I can patch it myself.

    1. -tim

      Re: FreeBSD appears to be affected

      pkexec isn't installed on most FreeBSD systems. It doesn't appear to be in the base system install and likely in polkit package.

  10. Nate Amsden

    lucky

    I manage about 750 linux systems. checked this morning after verifying the ubuntu security advisories and saw none of my systems have this package installed.

    So maybe installed by default but not a required package. good news there anyway.

  11. symgryph

    Glad I use Alpine!

    I recently tried to update a 'test' of rocky linux (the successor to Centos), only to find that by default the Updates repo didn’t work due to a change on deadrat's side of 4k rsa sigs. Additionally, I now see silly things like 'polkit' suid nonsense, and I am SO GLAD I use alpine:

    1. Small

    2. uses MUSL instead of GLIBC (smaller attack surface)

    3. systemd OPTIONAL (sometimes one needs systemd evil, but I don't want deviltry enforced on me)

    4. upgrade EASY and painless

    5. LBUBACKUP saves all my settings and etc things automagically

    Busybox does take a bit of getting used to, but you can selectively install GNU things if you really need them. My systems 'just work' without breaking (unlike deadrat, where my system obliterated itself due to a faulty kernel update).

    Also openrc is nice, but its not quite as easy to use as systemd with unit files, but 99% of the time I can find a system package that already has one. So I often don't need to deal with beyond service blah enable.

    1. jake Silver badge

      Re: Glad I use Alpine!

      "sometimes one needs systemd evil"

      Can you provide examples that are not contrived just to prove the point?

      To date, I have never, not once, seen a place where the systemd-cancer is needed.

      1. jtaylor

        Re: Glad I use Alpine!

        "'sometimes one needs systemd evil' Can you provide examples?"

        It's useful to be able to manage service dependencies and groups of services. This is why I liked the Service Management Facility in Solaris

        Note that I don't claim systemd is the correct solution to anything, only that I have found cases where it helps to manage services at a higher level than SysV init.

        1. jake Silver badge

          Re: Glad I use Alpine!

          Sounds to me like you want a service manager, which doesn't really belong in an init when you think about it.

          1. jtaylor

            Re: Glad I use Alpine!

            I don't care if init calls a service manager. I want the web server to start after boot, and if it depends on a database back-end, I want the database up before the web server starts, and if the database depends on an NFS mount, I want that volume mounted first. I don't want every startup task to be serialized, but get the dependencies right.

            1. jake Silver badge

              Re: Glad I use Alpine!

              I've been doing exactly that on Slackware for about 25 years. No big deal :-)

    2. Lunatic Looking For Asylum
      Pint

      Re: Glad I use Alpine!

      I like Alpine too Have one of these.

      I'm not too chuffed with musl not supporting utmp/wtmp, their reasons seem spurious at best Scroll down here https://wiki.musl-libc.org/faq.html for more info)

      Administering big multi user systems, seeing who is online and having a history of logins/reboots etc. is pretty fundamental.

      1. jake Silver badge

        Re: Glad I use Alpine!

        I prefer pine to alpine, but will happily use either.

        Spurious? Sounds to me more like paranoia ... or, more likely, somebody got caught red-handed.

  12. Anonymous Coward
    Anonymous Coward

    Meanwhile in the NHL

    PK SUBAN unvailable for comments.

    1. jake Silver badge

      Re: Meanwhile in the NHL

      What's hockey got to do with all this?

      1. FernTheConcentricGuy

        Re: Meanwhile in the NHL

        "This vulnerability has been hiding in plain sight for 12+ years and affects all versions of pkexec..." That's his first name minus exec. Sencondly to gain root access in linux you would have to use the su ie super user command with a password; that's his second name if you add ban.

        1. jake Silver badge

          Re: Meanwhile in the NHL

          Syntax error, unable to parse. 2 minute minor.

  13. Lorribot

    Can't wait for the 100 odd Linux based appliances that will likely need updating with patches from the many different vendors for their specific flavours of Linux, some will be quick, others not so, some will likely not bother or even know as the bloke that did has left due to cost cuts, IR35. Each one will have to manually patched, with attendant Change requests and lots of out of hours work no doubt.

    Thus is the life of those supporting Linux in the real world rather the nice idealized one were you have a few servers running the distro of your choice and you can just grab and update as required.

    Unlike Windows were you just point it at a WSUS server and all your servers are up to date in what ever time scale you choose.

    1. Dante Alighieri
      Pint

      Appliances v Servers

      Sorry, I may have misunderstood but you talk about appliances and Io(.shi)T then about windows servers.

      oranges v screwdrivers methinks.

      You have seen the 12 Borks etc etc etc

      embeded WinCE on rides in Disneyland will also be sorted for all CVE (wish I'd had a camera for the Bork!^3 when I was riding it)

      YMMV. ----> icon

    2. bombastic bob Silver badge
      Meh

      polkit is really only necessary if you have a GUI and something like Gnome or Mate uses it for whatever reason. Although I think systemd may need it, it may also be optional without a GUI installed.

      So most (if not all) of those Linux appliances may not be affected. But RPi OS would be, if you're using it as a touch screen. So there you have it.

      (risk assessment as needed if the device is networked or not)

  14. Anonymous Coward
    Alien

    Bury it in the desert. Wear gloves

    Polkit problem is that it was designed by people with brains made of cabbage. Open source can not help you if your brain is made of cabbage. Open source can not help you if you use software written by cabbage brains.

    Imagine you wanted to look at a system and statically answer question: 'who has privileged access?'. If that system uses polkit then to answer this question you must evaluate programs written in JavaScript. JavaScript is trivially Turing-complete language so in general that means that you can not answer this question, even in principle. Oh, yes, now cabbage-brains will say that no, is not halting problem here as computations are time limited. Yes: time-limited, so now to know if a computation completes or times out and fails you will need merely to store the entire physical state of the machine running it and replay it, accounting for any possible events which may alter timings like, well, anything. Which is a problem you can solve in principle ... if you can store the entire state of the past light cone of the computation, which is laughably impossible.

    Solution to polkit is simple: bury it in the desert. Wear gloves.

    1. Anonymous Coward
      Anonymous Coward

      Re: Bury it in the desert. Wear gloves

      "Polkit problem is that it was designed by people with brains made of cabbage."

      Precisely how does this differ from the people who designed Linux ? Inasmuchas that train wreck has a design.

      For many years now Linux has resembled a rag-bag of random stuff thrown together by monkeys with typewriters. One word proof: systemd.

      1. bombastic bob Silver badge
        Linux

        Re: Bury it in the desert. Wear gloves

        Fortunately, systemd is NOT Linux. I would say that some of the desktops (talking about YOU, Gnome) resemble the rag bag etc. in at least SOME ways, but fortunately Linux itself and the standard POSIX utilitiesl do NOT (they seem very well designed and reliable, to me).

        1. jake Silver badge

          Re: Bury it in the desert. Wear gloves

          Not only is the systemd-cancer NOT Linux, Linux doesn't even need the systemd-cancer to operate.

          GNOME is simply awful. Why people continue to propagate the charade is beyond me.

          Yes, the basic utilities included with all (most?) Linux distributions (and BSD) are very well designed, secure, and reliable.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like