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 …

Page:

  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 Silver badge
      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 Silver badge

              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

Page:

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