Slashdot Mirror


OS X Bug Exploited To Infect Macs Without Need For Password

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.

29 of 127 comments (clear)

  1. Also fixed in 10.10.5 by Anonymous Coward · · Score: 4, Informative

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

    1. Re:Also fixed in 10.10.5 by Anonymous Coward · · Score: 3, Funny

      But Windows 10 is free and people already happily flock to free adware infested services like Facebook, Gmail, etc. So Microsoft just took the normal adware-filled web browsing user experience and transported it to the desktop to make using computers more consistent!

      Anyway, with the way Apple's stock is going it's just a matter of time before the same thing in OSX. Except Apple won't give any options to disable it.

    2. Re: Also fixed in 10.10.5 by Anonymous Coward · · Score: 2, Informative

      I just installed Win10 via upgrade and rather easily turned off almost all the reporting features within minutes from the control panel. I don't use their store and I login only with a local login and use Firefox. Win10 so far has been as good as Win7 and I haven't run into any of Win8 issues. You sound like another Microsoft bandwagon hater. Years ago I learned to use the best tool for job, maybe you should too.

    3. Re: Also fixed in 10.10.5 by perpenso · · Score: 5, Informative

      I just installed Win10 via upgrade and rather easily turned off almost all the reporting features within minutes from the control panel.

      You could have turned off the reporting from the installer by selecting the custom configuration option.

    4. Re: Also fixed in 10.10.5 by Penguinisto · · Score: 2

      And you cannot prevent Apple from changing your shit when they update OS X.

      Turn in your geek card, because yes you can modify OSX post-patch - you just have to be comfortable with a *nix command prompt and have sudo privs.

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    5. Re: Also fixed in 10.10.5 by Penguinisto · · Score: 3, Informative

      What makes you think that MS will use Windows Update to change settings?

      Because they've done it before.

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    6. Re:Also fixed in 10.10.5 by macs4all · · Score: 3, Insightful

      But Windows 10 is free

      I know you were trying to be humorous; but OS X has been Free for the past 3 Revisions now.

    7. Re:Also fixed in 10.10.5 by macs4all · · Score: 2

      That's a pity. This exploit could be used to automatically deinstall Apple's app store, install an open one and replace XCode with some free, cross-platform development environments. It would be a win-win for Apple and everyone else.

      Apple uses the App Store platform to roll-out Software Updates; so you might want to think twice about that.

      And as far as XCode goes, Apple hasn't automatically installed XCode for about a decade. Do try to keep up!

  2. Better Title by Anonymous Coward · · Score: 2, Insightful

    "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)

    1. Re:Better Title by gl4ss · · Score: 4, Insightful

      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.

      --
      world was created 5 seconds before this post as it is.
    2. Re:Better Title by MSG · · Score: 2

      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 a minor security threat. You also have a PDF reader that allows code execution, but code executes as the user, with limited rights, so this rates as a moderate security threat. You also have a dynamic linker that allows any process that can call system() to write to protected files. This is a critical security vulnerability.

      An attacker can now infect a server that you visit, or maybe convince you to visit a server that they control, and combine those to get root access on your system.

  3. You mean this one? by complete+loony · · Score: 3, Informative
    --
    09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
  4. Better link by phantomfive · · Score: 5, Informative

    Here is a better link with more technical details.

    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.

    --
    "First they came for the slanderers and i said nothing."
    1. Re:Better link by Dutch+Gun · · Score: 4, Informative

      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.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    2. Re:Better link by phantomfive · · Score: 3, Informative

      Last time I tried to report a bug to Apple through their bug tool, I got this error message. 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.

      --
      "First they came for the slanderers and i said nothing."
    3. Re:Better link by Dutch+Gun · · Score: 5, Insightful

      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.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    4. Re:Better link by benjymouse · · Score: 3, Insightful

      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 these to break out of sandboxes or gain root.

      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.

      Unix and Linux with the braindead SUID/setuid design are especially susceptible to privilege escalation. The design is akin to the security model of ActiveX: You let someone gain privileges far beyond what is necessary and then hopes he is well behaved and - crucially - cannot be fooled to use those privileges in nefarious ways. Well, bugs is one way to fool a SUID process to do something wrong.

      SUID/setuid breaches the security boundary of the *nix security model. Once a process becomes root there is no policy that constrain what the process can do*.

      * (absent kludges like apparmor, SELinux that are bolted on with separate security policies).

      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.

      Again, the trap is in the basic Unix design. A SUID process executes in the environment where it was launched, but with privileges of the file owner (typically root). That means that *anything* from the user environment is potentially an attack vector. In this case it was as simple as environment variables. So the tables turn, and now the developer must *explicitly* guard against malicious injections rather than coding to a well-defined contract where parameters are explicit. Not to mention that the developer may not even be aware that someone will change the executable to SUID or just invoke the executable as a tool from another SUID executable (example: sudo).

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    5. Re:Better link by CraigCruden · · Score: 4, Insightful

      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...
      Read the code that is being executed by the installer

    6. Re:Better link by TheRaven64 · · Score: 3, Insightful

      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.

      --
      I am TheRaven on Soylent News
    7. Re:Better link by benjymouse · · Score: 4, Insightful

      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?

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    8. Re:Better link by pop+ebp · · Score: 2

      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...

  5. Privlege escalation exploit change looks like this by CraigCruden · · Score: 4, Informative

    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

  6. Infect Mars? by tinkerton · · Score: 2

    I thought, what? But I misread.

  7. Re:Privlege escalation exploit change looks like t by TheRaven64 · · Score: 2

    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...

    --
    I am TheRaven on Soylent News
  8. 10.11 should be immune anyway by itsdapead · · Score: 3, Insightful

    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..

    --
    In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
    1. Re:10.11 should be immune anyway by benjymouse · · Score: 2

      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 are no longer permitted."

      Hardly a new "security model". And from that description - no it would not have mitigated this attack.

      Sounds an awful lot like Windows File Protection (later renamed to Windows Resource Protection). Welcome to 2004!

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
  9. "What Malware?" by tlambert · · Score: 3, Informative

    all that adware and spyware will still be present and enabled by default,

    What malware? Please point me to concrete evidence of this as I have yet to see it.

    I believe that's a reference to what they disable that used to work, and the bandwidth stealing.

    The things that get ripped out from under you are:

    (1) Windows Media Center
    (2) DVD Playback
    (3) Desktop gadgets
    (4) Preinstalled games (Solitaire, Minesweeper, Hearts; you have to purchase replacements)
    (5) USB Floppy drive support
    (6) The OneDrive application from Windows Essentials (it's replaced instead with the sync application)
    (7) Windows Updates are forced on you instead of being optional, unless you pay more for Pro or Enterprise

    We've seen this already with the consistent installation of the Windows 10 Update tray icon and application, even on Windows 7 and 8. This is particularly insidious, since the application runs in the background, and acts as a torrent style replication server as part of their Windows 10 content delivery network used for the updates. Basically, they are stealing bandwidth from you, even if you do not opt in for the update.

    Microsoft calls this "feature" Windows Update Delivery Optimization, and your computer is basically eating into your bandwidth cap, if you have on, since about July 29th when the update was released. This is enabled by default for the Home and Pro versions (but not Enterprise or Education, apart from the local network).

    To disable it, you have to go to the "Settings" / "Update & Security" / "Windows Update" / "Advanced Options" / "CHOOSE HOW UPDATES ARE DELIVERED", and then turn the "Updated from More than One Place" from "on" to "Off".

    And yeah, I think if something is eating into my bandwidth cap, it counts as "malware". The other problem is that it tends to monopolize upload bandwidth, which is usually asymmetric with download -- mean that it eats all of your ability to ACK your full download bandwidth.

    The other thing that I'd count as "malware" is Wi-Fi Sense, which shares your Wi-Fi password with various email and social network contacts. But it doesn't allow you to pick and choose with which ones it's shared, so for every enabled network, it's "everyone on this social network in my contacts, not just family or close friends".... also: kinda not cool.

    Again: trun-offable, but on by default: "Windows Settings" / "Network & Internet" / "Change Wi-Fi settings" /"Manage Wi-Fi settings" then turn off all the items under Wi-Fi Sense. Then have Wi-Fi Sense (and JUST THAT) "forget the list of known networks".

    1. Re:"What Malware?" by Ravaldy · · Score: 2

      The things that get ripped out from under you are:

      (1) Windows Media Center
      (2) DVD Playback
      (3) Desktop gadgets
      (4) Preinstalled games (Solitaire, Minesweeper, Hearts; you have to purchase replacements)
      (5) USB Floppy drive support
      (6) The OneDrive application from Windows Essentials (it's replaced instead with the sync application)
      (7) Windows Updates are forced on you instead of being optional, unless you pay more for Pro or Enterprise

      1) The installer notifies you that you will lose that feature if you currently have it enabled. So no issue there. Note the feature wasn't popular so that's why MS made away with it.
      2) DVD Playback. Performing updates will install Windows DVD Player at no charge (limited time) which will provide DVD playback
      3) It was a shitty feature that reeked security holes. MS decided it wasn't a popular enough feature to keep it. So as far as I'm concerned it was a good decision
      4) Big deal. There's tones of better offerings online for free
      5) The nostalgia. 99.9% of users do not use floppy drives on computers that can run Windows 10. If you need that support you can still use a Windows 7 machine in a virtual box or equivalent. Good on MS to finally drop some legacy support. You'll still be able to use them using 3rd party software.
      6) It's built-in. How is this a problem?
      7) I'm not a fan of this one either but I can see why they did it. There's pros and cons to either way of doing. For most users it's no skin off their nose since they were already setup for auto updates

      I fail to see malware in any of the 7 points.

      The bandwidth sharing for Home and Pro is a big deal for me too but it's not malware as it's intent is not malicious. See definition https://en.wikipedia.org/wiki/....

      You have the option to disable it and the estimated monthly bandwidth usage is minimal (estimated at a maximum 2GB of sharing / month). If everybody disables it, that could increase the load for the ones who have it on (I'm assuming as I don't fully understanding their peer to peer implementation).

      So is this truly an issue? Depends if the estimated max of 2GB / month of sharing is accurate. After all, the product is offered for free and we all know there's significant cost in hosting updates. I guess the next question is: "Would you pay for your updates?". That would bring us back to a subscription model which most aren't a fan of. At the end of the day something has to give and consumers often prefer paying for it indirectly (such as advertisement). MS is working with the tools it has so it's hard to blame them even if I'm not a fan of the torrent style updates.

  10. It is not big deal, Chicken Little... by tlambert · · Score: 2

    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 had to have known about this prior to the general disclosure.

    In my time at Apple, this is typically not something Apple would issue a security update over. Specifically local shell privilege escalations are typically not considered an issue, since if you have access to the hardware, you can own it anyway.

    While layered attacks are getting more common, the specific attack in the wild has to do with a click monkey installer permitting the use of a non-local developer key signature on a compromised installer, as opposed to something code signed by the Apple App Store. Further, it requires a settings change (which you've probably already made, if you are a developer, or get third party apps directly), coupled with an explicit install authorization using an "admin" account.

    In other words: it's not a big deal, and is in fact rather "ho-hum" compared to, for example, the last 7 Adobe Flash vulnerabilities. It's *NOT* a "drive by attack", where if you just go to a web site with a Yahoo Ad on it, and no "Click To Flash" and no "Click To Run Plugins" settings, you're p0wned.