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.
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.
/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.
"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.
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
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.
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*
It'd be easier to just do this:
#sudo chflags uchg /etc/sudoers
(chflags is the OSX equivalent of chattr. "uchg" is the equivalent of "+i" "nouchg" is "-i")
Quo usque tandem abutere, Nimbus, patientia nostra?
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".
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.
To address the actually comprehensible part of your post, it's not true that all OSes are equal in security, or anything else for that matter. We'll have to see how this unfolds.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
One of the forums that I frequent had a user who supposedly had a remote execution on a Mac for sale. The price was not unreasonable and I have seen others come and go. I can only assume there are some in the wild. I have seen similar/same for every OS on the planet pretty much - including some of the more obscure stuff. Meh... Practice safe hex. No matter what you do there are risks. To be ignorant of them is folly but, well, some folks tend to think they are immune. I suspect they are already pwned and just attribute their credit card hack from being from a skimmer somewhere at a gas station even though they have no evidence for it and it likely is their computer. Oh well... 'Snot much I can do about it. Nobody listens to a KGIII and that is probably a good thing.
"So long and thanks for all the fish."
What is true is that no OS is secure. Well, not one you can turn on at any rate. Nothing connected is secure. No OS is secure. No code is bug-free. Well, almost no code is bug free. I have a couple of Hello World's that I trust. Some are more secure, OS X is - traditionally - one of the more secure operating systems out there. No, no I am not an Apple fan. I do not even use them. I use Linux, Windows, and sometimes play with Unix. My phones I do not care about - even smart phones. I do nothing on them that is hidden really. I just discount them as insecure by default. I tend to do very little on my computer either.
I have not used a real credit card online in many years and always just get my credit union or bank to either make an account specifically for online transactions or just have them hook me up with a re-loadable card. This way, when (not if - though it has never happened oddly enough and I'd assume I would be targeted) it happens the risks are minimal. As banks pass the fault on to the vendor, and I side with the vendor - usually, I would likely just eat the cost and it would be trivial.
As for Macs? I own an iPod and an MacBook Pro. I gave my last MBP to my daughter and bought a new one just about a year ago. I only have it so that I can poke at it to help friends and family. I do not use the OS enough to be comfortable in it but, I suspect, it is a fine operating system. I have had no problem with it and the hardware is top notch even though it feels flimsy. I do find it to be a bit too light (if that makes sense) for my taste. I am a big laptop fan and prefer a large laptop with a full number pad and a second drive bay.
"So long and thanks for all the fish."