
OS X sudoers exploit found in the wild - hew
https://blog.malwarebytes.org/mac/2015/08/dyld_print_to_file-exploit-found-in-the-wild/
======
flashman
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 careers, though, so there's a strong incentive to go public.

[1]
[https://twitter.com/i0n1c/status/624172774915973120](https://twitter.com/i0n1c/status/624172774915973120)

~~~
_pmf_
> 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.

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)?

~~~
dspillett
_> helping out a company that takes part in the usual tax and labor law
evasion tactics_

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_.

~~~
zamalek
> The moral question being raised here is about potentially hurting Apple
> users via irresponsible behaviour

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.

~~~
coldtea
> _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?_

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.

~~~
zamalek
> "sky is falling" implications, and then NOTHING absolutely happens

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.

~~~
fyolnish
Viruses are not going to go poof unless your antivirus knows about them And in
the typical case a vulnerability is a prerequisite for a virus.

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.

~~~
zamalek
> Which is why Apple introduced developer certs and gatekeeper.

Yeah that is a really neat feature from a security standpoint.

------
chjj
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 better than getting a rootkit.

~~~
AdieuToLogic
> I'm seriously shocked. This is ridiculous. This looks like possibly the
> easiest root exploit ever discovered on a desktop OS ...

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-go

~~~
NeutronBoy
That 'fix' is going to break a lot of other stuff.

~~~
AdieuToLogic
> That 'fix' is going to break a lot of other stuff.

True, 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 "$@"
    

Would do the trick when put in the place of /usr/bin/sudo

EDIT: Added the comments regarding sanity checks.

~~~
chjj
I'm not sure where you're going with this.

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.

~~~
AdieuToLogic
> I'm not sure where you're going with this.

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.

------
mey
I keep asking this question and Mac people keep looking at me like I'm an
alien, so I guess I'll turn to the HN community for this questions.

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?

~~~
frio
Little Snitch
([https://www.obdev.at/products/littlesnitch/index.html](https://www.obdev.at/products/littlesnitch/index.html))
is excellent.

~~~
rosser
As a Little Snitch user, I'm inclined to agree, but I find that I sometimes
end up in a state of "WTF wants to use the network _now_?!" saturation.

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...

~~~
danudey
I really wish Little Snitch could generate aggregate rules for apps. I keep
having situations where an app starts making requests over and over until I
realize that the developer is using https requests to cdn###.somehost.com
where ### is apparently a dozen or more different hosts, and the only option I
have is to just allow all https traffic rather than more granular by-host
rules.

------
esusatyo
Isn't this the time when Mac App Store supposed to shine? When they found
something that's dodgy and linked to a company that has apps on App Store,
can't they just turn on the kill switch? That way the malware won't have
anywhere to direct the users to.

~~~
glhaynes
It's not clear whether this "adware installer" is signed by a developer cert.
I'm gonna guess it isn't, which means under the default settings, if a user
double-clicks it to execute it, they'll be presented with a message saying
that the app can't be run because it's "from an unknown developer" and the
current settings disallow it. The user can get around that by right-clicking
it and choosing "Open" (or switching Gatekeeper to be more relaxed), but the
error message doesn't allude to this.

Edit: And if it _is_ signed: yes, I believe Apple could and presumably would
push out a malware update that would invalidate the cert.

~~~
noondip
One could easily make an "app" which just runs a shell script with this
exploit - no code signing needed.

~~~
glhaynes
And users attempting to run it would encounter the things I mentioned above,
so I'm not sure what you're getting at.

~~~
noondip
I'm getting at the fact a shell script with this exploit can be made to look
like an "app" and be "double-clickable", and doesn't require any code signing.

~~~
jakobegger
Gatekeeper also watches over shell scripts, so when you double click the shell
script it will tell you that you can't open it because it is from an
unidentified developer.

~~~
noondip
You're thinking of quarantine. You'll get a warning saying the script was
downloaded from the Internet, asking if you're sure you want to open it.
Again, nothing to do with code signing.

~~~
glhaynes
I haven't gotten to try it to confirm but I'm having trouble imagining why an
unsigned .app bundle containing a binary executable would get the code-signing
error but one containing a script wouldn't. Is that in fact the case?

~~~
noondip
Sorry for not making this more clear. Create a shell script with the exploit,
then remove the .sh extension. You can edit the icon to make it appear as any
application and when double-clicked it will open and run in Terminal.app.

~~~
glhaynes
Ah, thanks for clarifying. I suppose it wouldn't have execute permissions if
downloaded from a browser, but it could if copied with Finder from a network
share (or directly accessed, of course), so that sounds like a potential
vector.

~~~
noondip
It is a lot easier than you may think. Here is a simple demonstration:
[https://vid.me/gGQY](https://vid.me/gGQY)

~~~
jakobegger
This is bullshit. If you actually put that disk image on a web server, and
then download it, you'll get the unidentified developer warning and you _can
't_ run the script (there will be no button to open it).

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.

------
pqdbr
More and more news about Apple's software quality degrading. They are really,
really losing it.

------
odonnellryan
For anyone looking for the patch:
[https://github.com/sektioneins/SUIDGuard](https://github.com/sektioneins/SUIDGuard)

~~~
marquis
Is there a test to determine if the patch is successful?

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...](https://www.sektioneins.de/en/blog/15-07-07-dyld_print_to_file_lpe.html)

~~~
Corrado
Did you check the root directory for a file named "this_system_is_vulnerable"?
I just tested this on a mid-2015 MBP running 10.10.4 and found that file in
the root directory. :(

~~~
marquis
Thanks for clarifying: I was able to find the vulnerability on the unpatched
system with:

    
    
      $ ls -al /
      (etc)
      -rw-r--r--   1 root  wheel       0 Aug  6 06:46   this_system_is_vulnerable
    

So I can a) confirm the vulnerability exists and it can write with root
privileges.

and b) the patch works: I ran the patch, deleted the test file, rebooted and
the file is no longer able to be written.

------
muaddirac
Will a major OS vendor ever start taking object-capability ideas seriously? It
seems this is part of a class of vulnerabilities that simply couldn't occur
under that model.

------
athenot
Would it be possible to mitigate this by setting the immutable flag on
/etc/sudoers:

    
    
        chflags uchg /etc/sudoers

~~~
geofft
No, because the vulnerability is that you can write to arbitrary files with
root privileges. It turns out that sudoers is the easiest file to write to to
gain persistent root, but there are millions of other things: /etc/passwd,
/etc/cron.d, /root/.ssh/authorized_keys, any binary that's run by root, etc.

------
twic
Would it make sense for the kernel to use a fresh, empty environment when
executing a setuid binary?

Or 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?

~~~
delinka
The kext at
[https://github.com/sektioneins/SUIDGuard](https://github.com/sektioneins/SUIDGuard)
does something like that. For privileged processes, it neuters DYLD_*
variables completely.

------
kordless
I seriously wonder if issues that have highly polarized responses aren't some
sort of rip in reality.

~~~
chippy
..well, it's not cognitive dissonance - it's not holding two contradictory
thoughts, it's more a refusal to believe and more so a defence of investment.

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.

~~~
kordless
Dissonance is harder to resolve than it is to 'deal with'. I'd say you are on
the mark with your last two statements and wrong about it not being cognitive
dissonance. I can only claim that because I spend an inordinate amount of time
thinking about it in terms of cloud services and trust. :)

------
ganessh
Does this issue arise from Unnix or Mac OS?

------
qudat
Doesn't seem to work in 10.11

~~~
marquis
That's the correct behaviour. It's supposed to be patched in El Capitan by
default.

------
zwetan
I don't see in the article where they all blame the fault on Flash ?

------
chadscira
I was wondering why Download Shuttle has so many more users than my app (Fat
Pipe). Seems like they are playing with the world of adware marketing, I hope
they aren't doing weird things with the OS as well :/.

~~~
n9com
Our app, Download Shuttle, has nothing whatsoever to do with this malware. We
have no idea why the malware creator decided to open up Download Shuttle in
the Mac App Store.

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?

~~~
chadscira
Sorry about that, glad to hear that you guys are not involved.

From face value it does look very odd. I apologize in for assuming you guys
were involved.

------
ikeboy
This is what's mentioned in
[http://www.theguardian.com/technology/2015/aug/05/apple-
will...](http://www.theguardian.com/technology/2015/aug/05/apple-will-fix-mac-
os-x-bug-amid-security-concerns), and will be fixed soon.

------
cmurf
The top most thing is keeping the OS up to date. And I don't visit shady web
sites.

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.

~~~
linky123
Keeping the OS up to date wouldn't have helped with this.

~~~
noondip
10.9.5 is not even up to date. There are security fixes which were not
backported from OS X 10.10 Yosemite (the current release).

~~~
cmurf
Exploits, and high risk vulnerabilities are certainly being closed with
security updates. That's their purpose. Major changes aren't practical for
Apple, and they do everything they can to incentivize (badger) people into
upgrading to the current version.

