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.
It's also already fixed in the latest 10.10.5 beta.
How about periodically checking for the MD5 hash of the sudoers file ( for those who don't have the patch )
NotMisleading title.
Old news.
Patched bug.
Seems like Apple made some really big mistakes in Yosemite. Let's hope they fix it asap.
-- Cheers!
"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)
A Tweet-Sized Exploit Can Get Root On OS X 10.10
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
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."
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
I thought, what? But I misread.
Maybe set immutable flag on /etc/sudores ? /me ducks
/etc/sudoers is already read only by root/wheel..... which of course is no problem to change if you are root (which is what you have to give access to to make the changes in the first place) -- and that requires user intervention to install the malware.
There is a bug that allows you to add that line to sudoers without the password.
Hence my suggestion of setting the file immutable
http://arstechnica.co.uk/security/2015/08/0-day-bug-in-fully-patched-os-x-comes-under-active-exploit-to-hijack-macs/
"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) -- or a developer would have to link in external packages into their application that could potentially have the exploit.
Subsequent to the installer changing the sudoers file (which requires user installing the application containing the exploit) -- FURTHER applications or would no longer be asked for password during sudo escalation.
Fair enough... ... afaik
Still setting the immutable flag would mitigate this
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
Did OSX start using systemd?
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.
I think the consensus for many years with Mac's was that they were basically immune to the ills of the internet. For many arguable reasons, but I think this was more true when Mac's used Power PC chips and when Apple switched to Intel chips. It generally opened up OS X to more problems. I am not sure how much it benefited Apple? But I am sure the shear amount of options in Intel chips was worth it. I do however still believe OS X is safer then Windows. But I also think Windows is safer then it used to be. Not withstanding the greater amount of malware targeting it still. But at least much of it is being stopped by Windows security. Nothing is 100% secure and by now we should know this.
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 the group "group1" can read it.
Auditor: "And no-one else can read or write the file, not even root?"
Admin: "What do you mean, of course root can read and write the file, root can do anything. This is Unix, d-oh!".
Auditor: "Ok. Who can run as root, then? I need to have an exhaustive list, you see. The insurance company needs the list to assert the risk and calculate the premium"
Admin: (sighs, looks up in sudoers and su) "The user admin1 and users in admingroup1 can run as root".
Auditor: "And no-one else can run as root? What about that setuid bit I've heard of?"
Admin: "yes, ok, a setuid root utility can run as root, I knew that. But I have those covered. I run a report every week which lists all of those utilities with the setuid bit that are owned by root. We accept only those utilities that we know. Trust me"
Auditor: "Ok then. So back to this file, how can you document to me that - say - this 'cmsagent' utility cannot access the file, now that we know it is setuid root?"
Admin: "What do you mean, I installed cmsagent myself, I'm pretty sure that it only allows remote users to access documents in the CMS system"
Auditor: "But how do *I* know that? The operating system does not protect the resource against root abuse?"
Admin: "No - this is Unix. I know what I am doing. Trust me. I have access to the source code, if you want to see what it can do".
Auditor: "Ok. I don't know how to read code, so I need to have one of our code auditors look at all the source code then. Assuming that, how do I know that the binary present on this system is the compilation of the source code you will give me?"
All of this because of a bad design decision. In other operating systems (with no all-powerful root and no setuid), the DACL of a resource *does* reflect who can access the file.
SELinux, apparmor etc are ways to add (yet another) security context with proper security boundary.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
That's all fine and dandy for this particular exploit but until Apple releases 10.10.5, Mac users need to be aware that their system is vulnerable.
As a side note, 10.7, 10.8 and 10.9 are permanently vulnerable to a separate privilege escalation ("rootpipe") that Apple has stated they will not patch.
There's been an ability to execute root privileges in all *nix for years and it's still unpatched. This isn't news.
Macs don't have security exploits. Just ask your local "genius" or know-it-all skinny jeaned, self proclaimed "tech expert because I have a blogger account and can't fuddle through basic markup scripting" guy in town.
r in ur mac nao
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".
For years all of you state one OS is better than another. Proof is now in the pudding, as the MAC os reaches the point of profit for hacking you will see neither one is better. If Linux reached the same level it too wuold show to have huge flaws in coding. Humans are not perfect in anything we do so I ask you, show me absolute proof that you are correct. I actually think that non of you can either the MAC community nor the Windows community. ZFerrini
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.
Macs don't get viruses! I know this for certain because my mommy told me!