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.

Comments

Also fixed in 10.10.5

[Anonymous Coward]

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

Re: Also fixed in 10.10.5

[perpenso]

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.

Better link

[phantomfive]

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.

Re:Better link

[Dutch Gun]

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

[Dutch Gun]

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.

Re:Better link

[CraigCruden]

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

Re:Better link

[benjymouse]

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?

Re:Better Title

[gl4ss]

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.

Privlege escalation exploit change looks like this

[CraigCruden]

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