51–60 of 61 posts
Earlier quoted context omitted.
Looking at the patch[1], probably not. There isn't really a lot of complex string handling involved; it's basically just forgetting to forbid "--". I don't really see how any language choice could help you with this. [1]: https://github.com/sudo-project/sudo/commit/0274a4f3b403162a...
goto statement in something as important as sudo? Seriously? Talk about bad practices.
Earlier quoted context omitted.
Looking at the patch[1], probably not. There isn't really a lot of complex string handling involved; it's basically just forgetting to forbid "--". I don't really see how any language choice could help you with this. [1]: https://github.com/sudo-project/sudo/commit/0274a4f3b403162a...
It shouldn't have to forbid that. The editor and privileged files shouldn't be in the same string. It should just be appending the list of temporary files to the editor command, and running that unprivileged.
edit: apparently things are more complex and sudoedit already runs the command unprivileged; the attack is in filename expansion in sudoedit itself.
Earlier quoted context omitted.
Sudo basically has an ACL-like system where you can specify exactly which users/groups can execute which commands as root. So you can say user foo can execute commands X, Y, and Z as root and user bar can execute commands W, Y, and Z as root, and neither user can use sudo to execute any other command as root. The ACL system isn't for sudoedit specifically, it's a general feature of sudo. As to why you can't just upda…
I recently got to reading the POSIX.1e (MAC & DAC) draft, and the DAC = ACL part is... surprisingly non-terrible. Still awkward and hampered by its existence as barely-visible metadata smeared over the whole system, as all ACLs are, but not at all the hopeless mess I expected coming from NT. (Even that might’ve been salvageable had Microsoft been willing to publish full documentation of all NT object permissions and…
I mean, ACL data is normally stored in filesysem metadata, nothing is 'smeared'.
I wonder if this bug in logic (instead of buffer overflows) would also have been less likely in a different language. Would it have been more obvious in a language where it's easier to work with dynamically allocated arrays and strings?
Earlier quoted context omitted.
I don't think that's what's happening. sudoedit does NOT run the editor as root, it copies the file to a temporary as root, runs the editor as you, and copies the temporary over the target file as root when you're done editing it (at least it's supposed to).
Looks like a misclick, but unsure which comment was intended for this reply.
The editor cannot be tricked into editing the wrong file as root by environment variables, because it is not running as root.
The security is an actual flaw in sudoedit, the wrapper script, not a fundamental issue with the environment you pass to the command.
I moved to https://man.openbsd.org/doas long ago.
Earlier quoted context omitted.
It shouldn't have to forbid that. The editor and privileged files shouldn't be in the same string. It should just be appending the list of temporary files to the editor command, and running that unprivileged.
You don't even need a temporary file; opening the file directly in sudoedit then passing /dev/fd/N to the spawned edit process after dropping privileges would work (a-la capabilities). But sudoedit being implemented in terms of sudo makes it hard. edit: apparently things are more complex and sudoedit already runs the command unprivileged; the attack is in filename expansion in sudoedit itself.
I wonder if this bug in logic (instead of buffer overflows) would also have been less likely in a different language. Would it have been more obvious in a language where it's easier to work with dynamically allocated arrays and strings?
Earlier quoted context omitted.
I recently got to reading the POSIX.1e (MAC & DAC) draft, and the DAC = ACL part is... surprisingly non-terrible. Still awkward and hampered by its existence as barely-visible metadata smeared over the whole system, as all ACLs are, but not at all the hopeless mess I expected coming from NT. (Even that might’ve been salvageable had Microsoft been willing to publish full documentation of all NT object permissions and…
> smeared all over the system I mean, ACL data is normally stored in filesysem metadata, nothing is 'smeared'.