Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
OS X Bug Security Apple

OS X Bug Exploited To Infect Macs Without Need For Password 127

Posted by Soulskill from the sooner-or-later dept.
An anonymous reader writes: A new flaw has been discovered in the latest version of OS X which allows hackers to install malware and adware onto a Mac without the need for any system passwords, researchers say. The serious zero-day vulnerability was first identified last week and results from a modified error-logging feature in OS X Yosemite which hackers are able to exploit to create files with root privileges. The flaw is currently found in the 'fully patched' OS X 10.10.4, but is not in the newest 10.11 El Capitan beta – suggesting that Apple developers were aware of the issue and are testing a fix.
This discussion has been archived. No new comments can be posted.

OS X Bug Exploited To Infect Macs Without Need For Password More

OS X Bug Exploited To Infect Macs Without Need For Password

Comments Filter:

  • Also fixed in 10.10.5 (Score:4, Informative)

    by Anonymous Coward on Wednesday August 05, 2015 @02:27AM (#50254149)

    It's also already fixed in the latest 10.10.5 beta.

    • "It's also already fixed in the latest 10.10.5 beta."

      Good. Now can we work in the iOS bug that allows malicious ads to yank you into the App Store involuntarily?

      • "It's also already fixed in the latest 10.10.5 beta."

        Good. Now can we work in the iOS bug that allows malicious ads to yank you into the App Store involuntarily?

        Has it been fixed on Android already? Oh no, wait, that takes you to Google Play involuntarily - so not a bug, but a feature, right?

        • An acknowledgement of iOS/Android equivalence. I'm glad I switched to a Windows phone, I guess...

          • An acknowledgement of iOS/Android equivalence. I'm glad I switched to a Windows phone, I guess...

            Well, then you switched less than 7 months ago, because there were reports of it happening there too. Which went mostly unnoticed because pretty much nobody was affected - well only all Windows Phone users.

          • Re: (Score:1)

            by KGIII ( 973947 )

            What is cute is all this effort to deflect from the problem with OS X. And you all are falling for it. Silly users...

  • Click-bait FUD (Score:1)

    by Anonymous Coward

    NotMisleading title.
    Old news.
    Patched bug.

  • Not good (Score:2)

    by tsa ( 15680 )

    Seems like Apple made some really big mistakes in Yosemite. Let's hope they fix it asap.

  • Better Title (Score:2, Insightful)

    by Anonymous Coward

    "Significant vulnerability demonstrated in OS X. Apple releases patch a few days later. News at 11."

    Not as exciting, is it ?

    (it appears to be dealt with in both the 10.10.5 and 10.11 betas)

    • Re:Better Title (Score:5, Insightful)

      by gl4ss ( 559668 ) on Wednesday August 05, 2015 @04:09AM (#50254331) Homepage Journal

      apple knows of bug. fixes it in beta(first anyways, dunno if it's fixed in non beta). journalist tells it's fixed in the latest version.

      story gets posted again after a week on slashdot.

      but osx being exploitable if you have console/local access? that's not really news.

      • Re: (Score:3)

        by MSG ( 12810 )

        but osx being exploitable if you have console/local access? that's not really news.

        I don't know why so many people don't get this.

        The bug doesn't require a human at the console. Any code-execution bug can be escalated to root access because of this bug. It is not, by itself, a remote root, but security vulnerabilities can be combined, and a combination of bugs typically rates at the highest threat level of any individual element of the combined attack.

        That is, imagine that you have a bug in your browser that causes it to automatically open PDF files in an external viewer. This rates as

  • Better link (Score:5, Informative)

    by phantomfive ( 622387 ) on Wednesday August 05, 2015 @03:15AM (#50254235) Journal
    Here is a better link with more technical details. [sektioneins.de]

    It's a privilege escalation exploit, so an attacker would already need shell access on your computer to get something done. Every OS has privilege escalation vulnerabilities, because it's much harder to close all the holes when you allow someone to execute arbitrary code on a system.

    That said, this is a particularly braindead bug from Apple, and it is worrisome because it shows they aren't thinking about security, or don't have proper processes in place to ensure the system stays secure. Their programmers should have known better than to create that kind of environment variable so lightly.

    • Re:Better link (Score:5, Informative)

      by Dutch Gun ( 899105 ) on Wednesday August 05, 2015 @03:29AM (#50254263)

      Ugh, don't give this asshole more traffic. I think there's a reason few people are linking to his blog directly. He released the details of this bug without even attempting to contact Apple. When asked why he didn't do so, he replied "Why should I?" Later he states that "Responsible disclosure is simply a way of redirecting blame for a vulnerability from the vendor to the reporter." Right on his blog he's advertising his own presentations. Essentially, he's making news about this at the expense of user safety in order to promote himself and his services.

      A real piece of work.

      • Re:Better link (Score:4, Informative)

        by phantomfive ( 622387 ) on Wednesday August 05, 2015 @03:37AM (#50254279) Journal
        Last time I tried to report a bug to Apple through their bug tool, I got this error message [imgur.com]. When I sent a message to the address in the error message, they responded, "please submit that bug through our error reporting tool." The initial bug I was trying to report still hasn't been fixed.

        This vulnerability is already being exploited in the wild. In that case, responsible disclosure means announcing it publicly, so people can defend themselves. And if Apple gave him as much trouble as they gave me, I don't blame him for not reporting the bug to them.

        • Re:Better link (Score:5, Insightful)

          by Dutch Gun ( 899105 ) on Wednesday August 05, 2015 @04:24AM (#50254353)

          Is it really too much work for a security researcher to send an e-mail to product-security@apple.com? About five seconds of searching got me Apple's support page and that e-mail address.

          This guy admittedly didn't even try. And bugs that affect functionality are an entirely different matter than serious security issues. When dealing with a zero day, the decision on whether to announce it publicly depends on a number of factors.

          The very act of announcing it publicly guarantees that new exploits will explode in the wild (as this article confirms). And the reality is that very few OS X users will have seen this idiot's initial posting a month ago. Did you? I sure didn't. In the meantime, my system was and is now vulnerable to a hell of a lot more malware than it otherwise would have been.

          Sorry, but I have to disagree with you. Bad on Apple for making a stupid mistake in the first place and being slow to fix it, but I'm not giving this guy a pass either.

          • Sure, he should have let Apple know. That was a mistake.

            That said, Apple's bug process sucks, and letting people know about security bugs is a good thing, too.

      • Ugh, don't give this asshole more traffic. I think there's a reason few people are linking to his blog directly. He released the details of this bug without even attempting to contact Apple.

        It is not big deal, Chicken Little...

        If you looked at his LinkedIn profile -- assuming you have access because you are a close enough contact -- Stefan Esser is a first degree contact with Aaron Sigel, who is the Manager in OS Security at Apple. He's also a first degree contact with Alex Ionescu, who used to work on iPhone until 2011 (the same year I left Apple), and of course, I know Stefan through various forums, and from my tenure on the Core OS Kernel team at Apple (I was there 8 years).

        So yes, Apple h

    • That said, this is a particularly braindead bug from Apple, and it is worrisome because it shows they aren't thinking about security, or don't have proper processes in place to ensure the system stays secure. Their programmers should have known better than to create that kind of environment variable so lightly.

      They are thinking about security. This entire class of exploit is impossible on iOS and will be impossible in the next release of OS X (where it's much harder if you want to be compatible with typical UNIX software).

      • This entire class of exploit is impossible on iOS and will be impossible in the next release of OS X

        How will this 'class' of exploit be impossible on the next version of OSX (and how is it impossible now)? All you need to do is find a bug in an approved program (like Safari, and there are bugs in Safari), then use this exploit to get root permissions.

        They are thinking about security.

        This bug is clear evidence they don't have proper processes in place to give them security.

    • Re: (Score:3, Insightful)

      by benjymouse ( 756774 )

      It's a privilege escalation exploit, so an attacker would already need shell access on your computer to get something done.

      No shell access needed. A code execution bug in Firefox, Safari or Chrome (or whatever browser or internet-facing software you use) and the attacker is a local user. Especially Firefox does not have a sandbox, so a bug gives the attacker free reign. With this bug he can become root on your kit. That is bad. Blended attacks are the *norm* now - not the exception. Sometimes they are called "attack coctails" when they try multiple vulnerabilities to get foothold and then use privilege escalation bugs like thes

      • Re: (Score:2, Insightful)

        by Craig Cruden ( 3592465 )
        NO, Code execution in a browser CANNOT escalate privileges.... none of those applications have sufficient rights to change the /etc/sudoer file. The user would have to download and install an application from an unknown developer - which is blocked by default. You would then have to go into security settings and say - open up that installer for the application anyways. That installer application would then have sufficient privileges to make changes to the file and give that user root access with no aski

        • NO, Code execution in a browser CANNOT escalate privileges.... none of those applications have sufficient rights to change the /etc/sudoer file

          Way to miss the point. If they had the rights to write to /etc/sudoers then they wouldn't need a privilege escalation vulnerability. The entire point of this exploit is that it allows someone with an unprivileged account to gain root access. That said, both Chrome and Safari run the WebKit renderers in sandboxes that don't have the ability to run any setuid binaries (which this needs), so the grandparent is only partially correct: only Firefox would be vulnerable, out of the ones that he listed.

          • Re:Better link (Score:5, Insightful)

            by Craig Cruden ( 3592465 ) on Wednesday August 05, 2015 @05:54AM (#50254545)
            NO, you miss the point....

            "On Monday, researchers from anti-malware firm Malwarebytes said a new malicious installer is exploiting the vulnerability to surreptitiously infect Macs with several types of adware including VSearch, a variant of the Genieo package, and the MacKeeper junkware. Malwarebytes researcher Adam Thomas stumbled on the exploit after finding the installer modified the sudoers configuration file."

            The installer itself has been granted privileges by the operator to install the application to all users. It cannot install itself directly from the browser. It has to be downloaded (and potentially auto-opened) for installation. It either has to be installed maliciously into an application (which is unlikely to be a signed developer).

            Subsequent to that installation of the malicious malware, that user that installed the application has been given effective root access WITHOUT requiring passwords on subsequent actions. But until that file is modified, that user does not have sufficient rights, nor do any 3rd party applications have sufficient rights to make changes to that file without user intervention.

            The vulnerability is that the installer can make changes to the /etc/sudoers file during installation by use of the DYND_PRINT_TO_FILE.

            It is highly unlikely an application that is from a certified/signed developer is going to contain malware in the installer -- possible but not likely. This means social engineering to get the user to download unsigned applications - then go into security settings and allow that installer an exception to start the installation.

            http://arstechnica.co.uk/secur... [arstechnica.co.uk]
            Read the code that is being executed by the installer

            • Re:Better link (Score:4, Insightful)

              by TheRaven64 ( 641858 ) on Wednesday August 05, 2015 @06:46AM (#50254657) Journal
              Please go and read what the vulnerability does. It allows unprivileged code that is able to invoke a setuid binary, to append data to a root-readable file. If you have a browser exploit that allows arbitrary code execution in the context of the browser, then you have this ability unless the browser is running in a sandbox. Safari and Chrome run most of the code in such a sandbox, Firefox does not. A vulnerability in Firefox can be combined with this vulnerability to do anything that root can do.

            • Re:Better link (Score:5, Insightful)

              by benjymouse ( 756774 ) on Wednesday August 05, 2015 @07:35AM (#50254787)

              NO, you miss the point....

              You need to learn to distinguish between vulnerabilities and exploits. An *exploit* (the "installer" in this case) takes advantage of a *vulnerability* (the privilege escalation bug) to perform the attack. The underlying vulnerability exists regardless of the exploit.

              You focus on the exploit and (incorrectly) claim that it is unlikely to work. That's beside the point, however, as there are many *other* ways to exploit the vulnerability, where a code execution vulnerability in a browser, email client, facebook app or whatever can be combined with this vulnerability to create true drive-by exploits.

              I took issue with the dismissal of this bug as "just a privilege escalation" bug. Privilege escalation bugs are *serious* and critical vulnerabilities.

              You do not need an installer to exploit this vulnerability. A simple execution bug in Firefox (last version patched 4 of them, as did practically every version before that) or a sandbox escape bug in Chrome/Safari (more rare) will get you pwned should an attacker choose to create an exploit.

              As an apologist you are looking for a way to explain away the seriousness of the bug. That's the wrong (and dangerous) way to think about it. There are many attackers with tons of creativity who are ready to leverage a privilege escalation bug in any way they can.

              You cannot possibly cover all those scenarios. That is why we need OS vendors and software developers to maintain and respect security boundaries: Walls where as few as possible well-defined gateways, where each gateway is controlled by transparent policies that makes it easy to audit what can pass through the gateway and (preferably) why.

              In this case a piece of the wall crumbled, which means that you must now consider the risk that all the bad guys on the outside can venture in to the protected inside and do whatever they like. You have identified one bad guy on the outside (the installer) and claim that he can be controlled. What about all those that you have not identified?

            • No, no, no...

              The bug has only been observed in the wild in an installer, but that doesn't mean it can only be exploited by an installer.
              If you read the proof-of-concept in the OP link, no installer was involved at all.
              More generally, I don't understand why you seem to think a non-privileged (i.e. not running as root) installer process could exploit this bug in a way that a browser process cannot.
              Remember, we are discussing the hypothetical scenario of your browser already executing attacker-controlled co

        • You might want to read up on what "privilege escalation" means...

          none of those applications have sufficient rights to change the /etc/sudoer file

          None of these applications should be able to change sudoers, but due to this bug all of them are actually able to. That is why it is called privilege escalation.

          Most unix admins don't allow anyone root access

          That is exactly why this is a vulnerability. If the users already have root access, there will be no privilege escalation and this wouldn't be a vulnerability at all...

      • No shell access needed.

        Well, you do need the ability to set an environment variable, fork and exec a setuid binary. But you don't need to run /bin/sh.

  • Privlege escalation exploit change looks like this (Score:5, Informative)

    by Craig Cruden ( 3592465 ) on Wednesday August 05, 2015 @04:31AM (#50254365)
    if run "sudo cat /etc/sudoers" it will print out the file in question. The section normally looks like:

    # User privilege specification
    root ALL=(ALL) ALL
    %admin ALL=(ALL) ALL


    If it has been changed to include a new user or make changes at the end of any of the lines to add "NOPASSWD:ALL" then you have been affected:

    eg.
    username ALL=(ALL) NOPASSWD:ALL
    • Modifying the sudoers file was only one example use for this. It allows you to write to any file that is normally only writeable to root. Modifying sudoers is a fairly simple and visible change, but modifying one of the system startup scripts that launchd runs as root would work just as well. I think it only lets you append to a file, but it would also be possible to temporarily modify sudoers, then set your worm's setuid bit and change the owner to root, then revert the sudoers change. The only user-vi

      • Modifying the sudoers file was only one example use for this. It allows you to write to any file that is normally only writeable to root. Modifying sudoers is a fairly simple and visible change, but modifying one of the system startup scripts that launchd runs as root would work just as well. I think it only lets you append to a file, but it would also be possible to temporarily modify sudoers, then set your worm's setuid bit and change the owner to root, then revert the sudoers change. The only user-visible thing would be the setuid bit on a suspicious binary hidden somewhere in the system (how many people check for this?). Of course, once you are root then you can do things like modify firmware and boot settings and hide inside the kernel...

        Spot on. If I was a bad guy (I'm only a little bad) this is *exactly* how I would create an attack.

        The only user-visible thing would be the setuid bit on a suspicious binary hidden somewhere in the system (how many people check for this?)

        That part in particular highlights the problem with setuid.

        It is, in effect, a deliberate hole in the security boundary: The mere existence of the setuid facility means that you can *never* audit the security policies (access rights) and be confident that they truly reflect the rights and restrictions of users.

        Auditor: "Who can access this file"

        Admin: "Easy" (ls in the directory), "User1 can write and users in

  • Infect Mars? (Score:3)

    by tinkerton ( 199273 ) on Wednesday August 05, 2015 @05:03AM (#50254415)

    I thought, what? But I misread.

  • 10.11 should be immune anyway (Score:4, Insightful)

    by itsdapead ( 734413 ) on Wednesday August 05, 2015 @05:58AM (#50254561)

    but is not in the newest 10.11 El Capitan beta – suggesting that Apple developers were aware of the issue and are testing a fix.

    10.11 has a new SELinux-like 'rootless' security model that should mitigate against any privilege escalation attack like this. Odds are it was naturally immune..

    • 10.11 has a new SELinux-like 'rootless' security model that should mitigate against any privilege escalation attack like this. Odds are it was naturally immune..

      That's interesting. This is waht I have been able to find from Apple on the feature (now called "System Integrity Protection"):

      "System Integrity Protection

      A new security policy that applies to every running process, including privileged code and code that runs out of the sandbox. The policy extends additional protections to components on disk and at run-time, only allowing system binaries to be modified by the system installer and software updates. Code injection and runtime attachments to system binaries a

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close