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