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

[Anonymous Coward]

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.

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.

Re: Also fixed in 10.10.5

[Penguinisto]

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

Because they've done it before.

Re:Also fixed in 10.10.5

[macs4all]

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.

You mean this one?

[complete loony]

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

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

[phantomfive]

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.

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

[benjymouse]

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

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

[TheRaven64]

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

[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

10.11 should be immune anyway

[itsdapead]

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

"What Malware?"

[tlambert]

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