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.
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.
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
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...
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.
https://thehackernews.com/2013/08/apple-mac-os-x-vulnerabili...