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.
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.
many technologists have the whole suite of Apple products. The have invested thousands of their own money and years of their own time on Apple products. This changes their relationship to the corporation and leads them to defend their investments. To say "you made a bad choice" when someone has invested. so. much. will naturally lead to a defensive response.
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 a good contender, but in 10.2, you could hold down a key in the screen saver lock screen and overflow a buffer, crashing the screensaver and logging you in. Seriously. Not a root exploit but embarrassing.
> 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
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.
I'm not sure why you would bring up Windows 95. Aside from being two decades old, it never claimed to be secure or a multi-user OS. Security-wise, I don't see how it was worse than Apple's contemporary System 7.
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.