OS X sudoers exploit found in the wild
blog.malwarebytes.org
blog.malwarebytes.org
Esser has his reasons - "Short reminder: Europeans are not allowed to disclose vulns privately to a foreign company like Apple without registering dual-use export"[1] - but it's hard to believe he couldn't have told them anonymously. Disclosures make careers, though, so there's a strong incentive to go public.
I don't think of this as strictly career advancement. I think he is making an important legal and political point. If there were never serious issues while we operate under said laws, then they would never be changed or subject to question either.
So basically he just released it without disclosure. He claims reasons (see parent post), but its still kinda ick..
I'm sure we can all agree, you should have locked your door. Why be mad at your neighbour, he didn't leave the door unlocked, he didn't take your stuff...
I don't mean to blame any individual human here, but I'm baffled at the process by which debugging environment variables were added to dyld without being carefully vetted for bad interactions with setuid binaries. This is a well-known easy place to screw up, and I'm surprised that someone was working on dyld without knowing that (although yes, humans forget things sometimes), and much more surprised that this made it past code review and into a shipping product.
This isn't a random screw up in regular software. dyld is security-sensitive; it's one of the small number of libraries that bears a responsibility to be paranoid about setuid.
1) The person who left the house open was certain to get the message quicker because of the tweet than just a text. 2) It was possible to quickly and remotely lock the door. Apple can and should fix this bug very quickly, as that is certainly possible for them.
Esser put people at risk. Whether or not anything happens is irrelevant. He put them at risk and we need to recognize that is the cost of full disclosure.
If you're fine with that, cool, but don't pretend he didn't do anything.
Stop presuming I haven't.
> Esser put people at risk.
That's non-provable until we see it instantiated.
> If you're fine with that, cool, but don't pretend he didn't do anything.
Don't speak for me. I never said he did the right thing. I said stop spinning what-ifs about it, but clearly what I should have said is STFU and do something about it. People getting in each other's grill isn't doing something about it. It's blaming others for whatever issues we, as a group, find polarizing.
>That's non-provable until we see it instantiated.
That's not how risk works. I don't even know where to start. If you play a round of Russian Roulette and happen to hit an empty chamber, do you say it's impossible to prove you were at risk? Do you see now how dumb that argument is?
If he publicized a vulnerability, the risk to all of the affected systems is increased. Period.
It's the same way that EMPs are a risk to airlines. If someone releases a method to generate them very easily, they increase the risk to all airlines. You don't have to wait until an airline is brought down before you say the risk was increased.
[1] https://www.justsecurity.org/5703/export-control-arrangement...
Frankly, I find myself reading dyld's source code every so often when tracking down something or another with OS X program loading. I'm not saying I would have caught it, but I'm pretty sure I'm not the only one who reads it non-maliciously.
Furthermore, it was fixed in 10.11 betas, so Apple themselves already knew about it [edit: apparently not]:
>EdisonCarter 3 days ago
>It's only really "fixed" in El Capitan as a side effect of Apple introducing the new - and widely reported - "rootless" security feature which introduces fine grained file permissions.
Then let me help you with this one. The former is responsibility of the worlds most profit corporation with tens of thousands of employees, and the latter is under the responsibility of a random guy on the internet.
Apple are irresponsible for not addressing the issue in good time (they have known about it for long enough).
This fellow is irresponsible for not following decent "responsible disclosure" procedure. He released information of a serious exploitable problem without first making any attempt to inform the people who could do something about it or otherwise checking to see if they were already aware.
Relative size, income, employment/employee status, and so forth, are all irrelevant here.
This isn't true at all. Shaming people for unethical or unprofessional actions which they make publicly is quite effective in altering behavior and doesn't require a police state.
They're much more interested in getting you to sign up for their new music service than they are in making sure the devices you use it on are secure.
One party makes billions off their users, and will most likely continue their practice of not supporting 3 year old systems even if they are still in wide use for the next time. This should pretty much clear up who is worse.
> Esser has his reasons - "Short reminder: Europeans are not allowed to disclose vulns privately to a foreign company like Apple without registering dual-use export"[1] - but it's hard to believe he couldn't have told them anonymously.
You're suggesting that he should feel ethically obliged to break the law for helping out a company that takes part in the usual tax and labor law evasion tactics (not to mention customer protection evasion in the US)?
It has nothing to do with what's good for the company. That's not what responsible disclosure is about.
Irrelevant. The moral question being raised here is about potentially hurting Apple users via irresponsible behaviour, not about helping Apple itself. Just because Apple does it (by sitting on the problem) does not make it right for other people to put the public at risk as well.
Both parties can be in the wrong at the same time, the behaviour of neither of them is not valid defence for the other.
You do have to be very careful in these cases because of the way the law is set out and how easily companies turn to litigious defence instead of actually fixing problems. In this case I would recommend anonymously informing the controlling party. Of course if he had already done that then things are different and public disclosure is probably the only other thing he could have done.
The logical next step is that Apple have been intermittently flippant about security (of late they have improved but their approach is still wholesale unacceptable). Why do users knowingly use an OS with this track record?
> anonymously informing the controlling party
With government surveillance could he have had any guarantee that his disclosure wouldn't have been snooped?
Either way this discussion can be argued ad infinitum. The real villain here is the European Commission for such a brain-dead policy.
Knowingly might be a stretch there. Many don't know any better either through lack of education on such matters or deliberate ignorance.
> The real villain here is the European Commission for such a brain-dead policy.
I'd argue that this means there are three villains, rather than the bad law being the one and only problem!
Good point. Specifically regarding Apple and EU: something really needs to change.
Perhaps because ever since 2001 there are 5-6 new stories like this with huge scaremongering headlines and "sky is falling" implications, and then NOTHING absolutely happens, at worse a tiny miniscule of OS X boxes are ever affected, and there are absolutely no implications for 99.9% of users. In the meantime, Apple, even if slow to respond to stuff like this, does improve OS X security infrastructure steadily.
Meanwhile, in the same real world, people have to constantly fight viruses off of Windows boxes (slightly better after 8, but still a real concern).
Btw, no it's not just about "small market share" either. Mac OS had even smaller market share in the late 90s (even 1/10 as small as OSX), but it still had lots of malware and viruses people caught.
Sure, just brush off a sudo vulnerability.
> fight viruses off of Windows boxes
Virus != vulnerability.
Furthermore, while a rootkit is still a virus it's a long-shot from the relatively benign things running around on Windows machines (not that I mentioned Windows at first, but there ya' go - were on to that now). Just to avoid a Windows shitstorm, the same thing could be said of BSD. I am absolutely certain that there is at least one virus for the platform; however, the damage it could possibly do is seriously mitigated by the security of the platform.
"Viruses" (used as a distinct term to "rootkits") can at worst log a few keys up until your next virus scan. After that, poof! They're gone.
A "rootkit" (which requires a sudo/UAC vulnerability) can also at worst log a few keys or something. When you do your virus scan you're going to find nothing. It's going to sit on your machine until kingdom come because the virus is more privileged than you.
Security is like a backup. You only care about it when you have the random bad experience of actually needing it. I'm sure there are a bunch of Windows users who lament turning off UAC now that their files are all encrypted by ransomware. It has nothing to do with "market share" and has everything to do with risk: "UAC is such a stupid feature."
I could leave my keys in my car ignition every night of my life. No matter how much "market share" that car brand has all it takes is the random misfortune of someone on the street noticing that I do that.
Just keep in mind that it was you that bought up all these tangential topics.
But local vulns are only a concern if someone already has access to your system. In which case your usually fucked anyway. Which is why Apple introduced developer certs and gatekeeper.
Yeah that is a really neat feature from a security standpoint.
If it doesn't impact me, and has never had, I will. Just like I don't feel any need to run antivirus and anti-spyware on my Ubuntu box, whereas I do on any Windows box 1 own (3 of them).
>Virus != vulnerability.*
Well, the vulnerability has to be exploited to matter. Either by some virus, some hackers, some malware, creating a botnet, whatever. If it never does, or its always in the form of some trojan needing a stupid user to install it willingly, I don't care about it.
The mere existance of it is not really important. All systems had, have and will have some vulnerabilities.
I'm not some wide eyed believer in the invulnerability of OS X. I've cut my teeth on Sun OS (pre Solaris) and HP-UX, and I've run Linux since 1997.
I just don't care much for hypotheticals.
As for my data, I back them up. I can go back to a clean system, if anything happens, within 10 minutes with rolling archived bootable backups. And I re-install from scratch + dumb data in around 5 hours (I just did it a few weeks ago to try El Capitan).
>Security is like a backup. You only care about it when you have the random bad experience of actually needing it. I'm sure there are a bunch of Windows users who lament turning off UAC now that their files are all encrypted by ransomware. It has nothing to do with "market share" and has everything to do with risk: "UAC is such a stupid feature."
Well, it's kinda stupid. Even with UAC enabled the same users would just have gone ahead and authorized it to install the malware in the first place, not knowing what it is and just wanting to get it out of the way.
Besides, if they had earlier backups of said files, removing the ramsonware and restoring the original files would be a few minutes affair.
>I could leave my keys in my car ignition every night of my life.
And if you live in certain countries where car theft rarely or never happens, you'll be justified too.
There are countries were people sleep and even leaves their house with the doors unlocked and windows open.
Not because theft is impossible -- just because it's rare enough that barely even registers, and they don't feel any need to be paranoid.
It's a healthy lifestyle, even if 1 in 100.000 has something stolen from time to time.
Heck, it's healthy even if it's you that has had that misfortune.
> One party makes billions off their users, and will most likely continue their practice of not supporting 3 year old systems even if they are still in wide use for the next time. This should pretty much clear up who is worse.
I don't agree. I have a six year old Macbook. In those six years I've updated to a new OS about three or four times. One time it has cost me 20 euros, the others were free. Not only that, but updating is a breeze, it's painless and never was a problem. I never had to do a complete reinstall. My mother could have done this. It's clicking a few buttons and that's it.
On top of that, there is no serious degradation in speed. They claim it's even faster, but that probably isn't true for the older hardware. So even if they don't support their three year old OS, you can update your six year old system to the most current one without problem. They could have served these updates as minor ones, but that wouldn't be fun, nothing to show, no new names, no big shows.
Now tell me - what is it that they don't support?
And Apple is doing their part by not emphasizing the role of the person who did disclose responsibly:
This is obviously very bad news. Apple has evidently known about this issue for a while now – not due to Esser, but thanks to a responsible researcher going by the Twitter handle @beist, who had alerted Apple some time before Esser discovered the bug.
As an outside observer, all I see here is: Don't alert Apple.
I'm suddenly very glad I don't use my macbook as my main machine, but I guess I'll remove the set{u,g}id bits on newgrp for now. Don't know if that will break things, but it's better than getting a rootkit.
Well there's always the classic "login -froot" bug [1]. Although, to be fair, you did say "desktop OS" and I'm not sure AIX exactly qualifies.
[1] http://seclab.cs.ucdavis.edu/projects/testing/vulner/18.html
Ignoring the nonexistent "root" privileges on Windows-95 (which allowed anything to change anything it felt like), also one of the easiest to fix:
mv /usr/bin/sudo /usr/bin/some-other-name-that-you-like-and-there-ya-goTrue, but a short-term replacement along the lines of:
#!/bin/sh
unset DYLD_PRINT_TO_FILE
# Cleanse the sudo arguments here...
# Check MD5 of /etc/sudoers against known good
# value here...
exec /usr/bin/the-renamed-sudo "$@"
EDIT: Added the comments regarding sanity checks.
That `unset` is useless since they don't call sudo to initiate the exploit. The setuid/setgid bits on the newgrp binary are to blame here (combined with the env variable). They could just overwrite your new /usr/bin/sudo file if they wanted to. Hell, they could brick your entire system just out of spite. No sudo necessary.
My point was to show that this very nasty exploit can be mitigated in the short-term by introducing a wrapper script to "protect" setuid programs.
> That `unset` is useless since they don't call sudo to initiate the exploit. The setuid/setgid bits on the newgrp binary are to blame here (combined with the env variable).
You are quite right. In an effort to be concise, the example wrapper unset the environment variable (for completeness) and mentioned checking /etc/sudoers against a known-good hash. I did not properly explain the mitigation strategy and should have stated that wrapping and unsetting the environment variable should be done for all setuid programs. Doing so should block this attack vector until a vendor supplied patch is available.
Is it an ugly hack? Probably. Doable, though, and I believe capable of defending against this particular vulnerability.
http://www.cvedetails.com/cve/CVE-2003-0518/
btw, discoverer claims to have written a kext fixing the hole
http://www.sektioneins.de/blog/15-07-07-dyld_print_to_file_l...
https://thehackernews.com/2013/08/apple-mac-os-x-vulnerabili...
Not as ridiculous as the response here, which is to bend over backwards to excuse the richest company on the planet, when compared with the scathing responses vulnerabilities in Adobe, Oracle, or Microsoft products receive.
Thus, the bending over backwards to excuse the richest company on the planet is very understandable. Especially within HN with it's fair share of early innovator and rich pockets.
It's understandable and utterly depressing.
What do you recommend as security software for OSX currently? How do you help secure your devices from public wifi and the internet in general? Especially for novice users?
I also uninstalled Flash.
1) A VPN company, who you've had the opportunity to research, who's primary business and reputation is based on handling your traffic.
2) Each and every WAP you connect to, in many cases with no real means to verify it's actually e.g. the official WAP of the hotel you're staying at, for something that likely costs the owners money rather than being seen as a profit center in and of itself. Their primary business and reputation is staked on something completely different than their handling of your traffic (be it their coffee, their accommodations, whatever.)
If you trust #2, statistics eventually comes into play - you will trust someone who shouldn't have been trusted. This also ignores that "public wifi" frequently performs MITM attacks for the... not entirely unreasonable purpose of providing login gateways, terms of use, etc. when you initially open up your web browser. But if you're already MITM traffic, it's not as big a stretch to substitute your own (poorly vetted) advertisements and affiliate links for a little extra revenue. Even if you don't do that, there's no guarantees your MITM tech isn't accidentally weakening security ala Superfish.
Not everyone can set up their own VPN endpoint. For those who can, and are willing to maintain it, great!
More: https://blog.getcloak.com/2013/03/04/why-trust-matters-when-...
(And what does AWS have to do with anything?)
My solution for that is to deny anything I don't recognize, and create rules for things I see more than twice, but if you're conditioned to click "OK" on everything you see, Little Snitch isn't going to to much for you...
If you really want to monitor what's going in&out of your computer you'll need to use wireshark from other computer in your network... =)
[1] https://www.blackhat.com/docs/us-15/materials/us-15-Wardle-W... [PDF Warning]
Part of the OSX security strategy is to minimize users installing things they shouldn't by making it difficult (enforced code signing, confirmations when opening an unsigned or new application). The other side is minimizing attack surface for exploits by staying up-to-date, not shipping crap like Java unless the user explicitly needs it, and (increasingly) sandboxing applications to user-approved subsets of the filesystem.
Bolt-on detection and resolution of malware infections is just not a part of the OSX security ecosystem like it is with Windows.
Little Snitch can help give you a picture of what's going on with regard to your network card, but at the end of the day malware can usually hide its traffic in an otherwise-trusted application to avoid that sort of detection.
You might want to check out mtree(8) then. It's serves well as the FreeBSD/OS-X Tripwire[1] equivalent.
http://googleprojectzero.blogspot.com/2015/06/analysis-and-e...
The code required for them to do their thing is so intrusive into the operating system that it has serious effects on stability.
And they are not that effective anyhow. Since they won't be able to detect exploits in existing programs over authorised channels.
The two follow up contenders were ESET and Kaspersky.
http://www.macupdate.com/app/mac/35914/tcpblock
You can set it up to disallow all network traffic until you whitelist the binary. Not sure if it's actually hashing them or just checking the path though.
Edit: And if it is signed: yes, I believe Apple could and presumably would push out a malware update that would invalidate the cert.
Gatekeeper and code signing work hand-in-hand. You can run any unsigned code you want, as long as you didn't download it from the web. For example, gatekeeper won't prevent you from running usigned code you compiled yourself, or from running code you installed using a package manager.
OS X is smart enough to know that a shell script is equivalent to an application. You can't fool Gatekeeper quite that easily.
When you double click a shell script downloaded from the internet, the warning will not ask you if you want to open the file. The warning will tell you that you can't open it because it is from an unidentified developer.
Let me try to clarify this: "Quarantine" is a flag set on files downloaded from the internet. When you open a file with the quarantine flag, Gatekeeper checks the code signature. If it is valid, it asks you if you want to open this file that you downloaded from the web. If the code signature is not valid, or if the file has no code signature, you wont be able to open it.
There are several ways to execute shell scripts downloaded from the internet: 1) Check "Allow all Applications" in System Preferences 2) Right click, select open. Then the warning will have a second option to open it despite being unsigned 3) Execute it from the command line
All of these presumably require the user to know what they are doing...
If Apple did this you could take down any app from the App Store by writing some malware and making it "advertise" the App Store listing.
Edit: as noted in Esser's blog [1]: $ EDITOR=/usr/bin/true DYLD_PRINT_TO_FILE=/this_system_is_vulnerable crontab -e
I found this test failed in both a patched (10.10.4) and un-patched system (10.10.1) so not sure what these results mean.
[1] https://www.sektioneins.de/en/blog/15-07-07-dyld_print_to_fi...
$ ls -al /
(etc)
-rw-r--r-- 1 root wheel 0 Aug 6 06:46 this_system_is_vulnerable
and b) the patch works: I ran the patch, deleted the test file, rebooted and the file is no longer able to be written.
chflags uchg /etc/sudoersOr perhaps a fresh environment with a few of the most important variables sanitised and copied over? And perhaps with the old variables available with a prefix (_UNPRIVILEGED_DYLD_PRINT_TO_FILE etc)?
What would this break?
Early innovators, technologists and many Hacker Newsers have spent thousands in both time and money on Apple. To attack Apple attacks their investment leading to defensive behaviour. To think to yourself "oh, now I'm going to ditch Apple and choose Linux" causes psychological harm as you have to 1) admit that your time and money was wasted on Apple 2) You made the wrong choice and 3) You don't want to learn another technology.
Thus it's easier to fight an attacker than to admit defeat.
We can only speculate that it was done in order to disguise what the malware is really doing (installing adware such as Genieo).
Download Shuttle is a free app and makes up an insignificant part of our overall Mac app portfolio. FIPLAB is one of the longest standing app developers on the Mac App Store and our apps have been featured multiple times by Apple themselves.
Perhaps you shouldn't jump to conclusions?
From face value it does look very odd. I apologize in for assuming you guys were involved.
Flash stand alone is removed, and disabled in Chrome. Lastpass for passwords. Tunnelblick+privatetunnel for open networks. And even though I use some software that isn't signed, after I've installed such software I revert the Security & Privacy "allow apps" setting back to app store+identified devs. And relevant, just by coincidence, in this case, I'm using 10.9.5 (which is still currently maintained with security updates).
The reality is that Mac users are simply used to trusting Apple to handle these sorts of things. And it's not a good alternative for that trust to be lost and placed in a 3rd party, e.g. on Windows where trust loss means a litany of 3rd parties to choose from in that space with no real practical way to differentiate, and the Windows Store described as a "cesspool of scams." Apple will get this fixed soon. It's definitely sub-optimal response wise, but I still trust this ecosystem compared to Windows at this point.
Edit: Oh and Privacy Badger.
Frankly, I'm way more comfortable taking my Windows 8.1 machine to public wifi hotspots these days than my OS X 10.9 machine.