|
|
|
|
|
by hathawsh
2435 days ago
|
|
Are the examples in the advisory statement slightly incorrect? The first example seems to have the user name and host reversed: myhost alice = (ALL) /usr/bin/id
All the examples I've seen of sudoers files do it this way: alice myhost = (ALL) /usr/bin/id
This is important because the host is rarely used; the host field is usually replaced with ALL, meaning the host name is not important for the rule: alice ALL = (ALL) /usr/bin/id
I hope this isn't some new sudoers syntax.As I consider whether this bug impacts my company, I see two types of rules in our sudoers files: (1) rules that let already-privileged users do privileged things and (2) rules that let processes with minimal privileges make an exception to normal security rules. This bug doesn't impact rules for highly privileged users because they already have many ways to do whatever they want. This bug doesn't impact the second type of rules either because those rules specify exactly which user to change to; I tested the '-u#-1' trick with one of those rules on an unpatched sudo and sudo didn't allow it. The behavior I observed seems to match the advisory, which says the exploitable rules are those that don't specify a specific user to run as. Now I wonder: what kind of well-written rule would be exploitable? |
|