sudo should be written in a memory safe language, there is no reason for this kind of exploit to exist, there is no performance or other reason openwall.com/lists/oss-secu oh yeah if you have sudo installed anyone can become root you might want to upgrade.
Conversation
Replying to
I see memory safety as something of a distraction here. While the specific mechanism in this case involved unsafe access to heap, the underlying problem is complex logic & string processing of any sort with elevated privileges.
1
10
This could just as easily have been perfectly memory-safe but constructing the string to pass to the shell for arbitrary execution in a wrong way such that it admits bypassing policy.
2
10
Typical usage of sudo is entirely security theater and this is yet another nice example of how the attack surface added by security theater can cause harm. It's possible to use sudo to only permit running specific commands but... it's not usually a good way to approach anything.
1
3
An uncontained process running as the user can substitute a sudo command or intercept the user's password either with sudo or elsewhere. The typical usage is allowing users to run any command as root. What's the advantage of that supposed to be over having the root password?
1
1
The disadvantage is that any user on the system with access to the command can exploit vulnerabilities in it to take over the system. That includes applications running as their own user such as a web server, unless they have at least basic sandboxing beyond dedicated user/group.
1
1
I don't think the solution is rewriting sudo in a memory safe language but rather getting rid of it.
Better to handle every normal use case via a proper design for it (support user-specific app installs, etc.). Sysadmin can login as root via a virtual console. Works fine.
I tend to agree, but this has not been happening in a large number of environments (arguably automation is replacing many of these, and sudo is less installed in automated environments I would hope).
1
One option is privileged interfaces, the terminal running outside the normal user account environment to prevent substitution attacks, etc. Also using different tiers of privilege within the same account, so you can eg. protect script collections from tampering.
1
I like the capabilities design pattern. This should be applied more extensively. The Unix model should be refreshed into exposing more functionality as hardened API:s.
I don't know if PolicyKit is still a thing, IIRC it did conceptually similar things.
1
1
Show replies