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.
"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)
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.
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*
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 asking of the password in the future. It takes a fair amount of social engineering of stupid users to get to that point.
Most unix admins don't allow anyone root access or the ability to install applications. It only exists in OS X to be user friendly. The exploit is closed in 10.10.5 (currently in beta)
.
In El Capitan the security will be rootless by default.
NO, you miss the point....
/etc/sudoers file during installation by use of the DYND_PRINT_TO_FILE.
"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
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
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.
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
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*
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.