Live data from Hacker News

OS X sudoers exploit found in the wild

blog.malwarebytes.org

61–70 of 193 posts

Re: OS X sudoers exploit found in the wild

#61
post #33

Earlier quoted context omitted.

On public wifi, I use https://www.getcloak.com I also uninstalled Flash.

Why do you trust Amazon AWS and this company more than your own connection?

"Public wifi", not "your own connection". You have two options for who you decide to trust:

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.

Re: OS X sudoers exploit found in the wild

#62

I'm not sure who makes me more cranky: Apple for apparently sitting on the fix, or Stefan Esser for flinging the vulnerability into the breeze for anyone to catch. 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 caree…

Apple doesn't really seem to care much about its users once their money has changed hands. Look at how long every iPhone in the world was able to be remotely rebooted via a single text message. That took nearly two months to fix.

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.

Re: OS X sudoers exploit found in the wild

#64
post #33

Earlier quoted context omitted.

Why do you trust Amazon AWS and this company more than your own connection?

"Public wifi", not "your own connection". You have two options for who you decide to trust: 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 m…

I think you put far too much trust in one of thousands of clone VPN services. There's no reputation to taint, there's stock standard scripts running on commodity VPS boxes they rented from somewhere else. I would be shocked if at least some of the most commonly used ones weren't run by people looking to sniff credentials. You're paying to pipe all of your sensitive information through some random persons box, which is just ludicrous.

Re: OS X sudoers exploit found in the wild

#66
post #37

Earlier quoted context omitted.

From the Author in the Comments "In Esser's original post revealing the vulnerability, he said, "At the moment it is unclear if Apple knows about this security problem or not."" So basically he just released it without disclosure. He claims reasons (see parent post), but its still kinda ick..

Just giving the benefit of the doubt here, a lot of the time it's unclear if your disclosure even made it to the right people in a company or not. No response is the norm for security disclosures, as is claims of "we didn't get this", even if you have a receipt for their ticketing system that says they did. I've sometimes spent far longer attempting to contact a company than doing research into something that seems t…

Stefan is not just some random guy on the Internet. I can assure you the relevant folks at Apple know him and most likely he knows them.

Re: OS X sudoers exploit found in the wild

#67

Earlier quoted context omitted.

How can you be mad at Esser? He didn't put the bug there. He has nothing to do with this.

You forget your key when leaving for work, and don't lock your door. It was accidental, you have a lot on your plate. Your neighbour sees you didn't lock it, and tweets out, "Hey Mike at 321 Greyhat Bvld, you didn't lock your front door". He didn't send that to you as a text, he tweeted it. You come home, and you've been cleaned out. I'm sure we can all agree, you should have locked your door. Why be mad at your neig…

I'm sure we can all agree we can make up shit that can happen till the cows come home. I'm not going to act as if someone robbed me until they do. Hold Esser responsible if someone hacks a large number of people because of what he did. Otherwise, stop living a thousands lives.

Re: OS X sudoers exploit found in the wild

#68
post #40

I'm seriously shocked. This is ridiculous. This looks like possibly the easiest root exploit ever discovered on a desktop OS (a one-liner in bash). Why in the world would they allow an env variable to write to a file in a setuid'd binary? 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 bette…

This one, albeit local only, was a lot of fun too:

https://www.securemac.com/macosxsetuidroot.php

Re: OS X sudoers exploit found in the wild

#70
post #44

Earlier quoted context omitted.

Security software is a band-aid on vulnerable software and users installing things they shouldn't. 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 ex…

I believe in defense in depth. There is always going to be an escape. Within the last month there has been several different privilege escalations possible in OSX. While I appreciate OSX having a strong security model, secondary solutions are desirable too me.

> I believe in defense in depth. ... While I appreciate OSX having a strong security model, secondary solutions are desirable too me.

You might want to check out mtree(8) then. It's serves well as the FreeBSD/OS-X Tripwire[1] equivalent.

1 - http://www.tripwire.com

Post reply on HN