* https://security-tracker.debian.org/tracker/CVE-2023-22809
* https://ubuntu.com/security/CVE-2023-22809
* https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2023-22809
Debian has links to the others.
https://access.redhat.com/security/cve/CVE-2023-22809
Red Hat has quite a few services under the /security path.
By adding your own `--` in the `EDITOR` variable, `sudo` gets confused and thinks that `--` is the start of the `sudoedit` file arguments and thus happily copies and edits all the files after it.
edit: I now realize I have confused sudoedit with visudo
Just curious about arguments for this use case.
Permission complications.
Software may run as user:group, but you don't want to add humans to either, and so you allow them to edit a few files as that user or group from their own account (which also gives you auditing of changes). Some software insists on files (directories) have certain permissions so you're stuff with them.
Or you want a centralized place for permissions, so you put these sudoedit entries in LDAP which can be accessed anywhere in you network, and so you don't have to keep track of individual file permissions on a gazillion systems.
As to why you can't just update access privileges of the file, for most use cases you probably could do that. If you need something more complicated though you'll have to use some terrible ACL implementation like the one in sudo or Posix file ACLs.
The /etc/sudoers solution does have a usability advantage precisely in not being smeared all over the system. Even if “/etc/sudoers” and “usability” are words not often seen inside a single sentence.
[1]: https://github.com/sudo-project/sudo/commit/0274a4f3b403162a...
It has one job
* read file as priviledged user * copy it to temporary file * run editor as unpriviledged user * copy the changed file back
The fact lack of escaping somehow makes sudoedit try to edit file passed in EDITOR variable is extremely shoddy coding.
A system with more of an object capabilities model could have helped, though. The goal wasn't really "let the user run their editor as root (when they ask for it)", but "let the user work with this particular file from their editor (when they ask for it)".
Not to mention, C++ /can/ be memory safe if you use memory-safe routines.
I'm just waiting for articles to come in, this year.. "why 2023 was not the year of Rust". Not hating on Rust - just the evangelism.
sudo (1.9.9-1ubuntu2.2) jammy-security; urgency=medium
* SECURITY UPDATE: arbitrary file overwrite via sudoedit
- debian/patches/CVE-2023-22809.patch: do not permit editor arguments
to include -- in plugins/sudoers/editor.c, plugins/sudoers/sudoers.c,
plugins/sudoers/visudo.c.
- CVE-2023-22809
* SECURITY UPDATE: DoS via invalid arithmetic shift in Protobuf-c
- debian/patches/CVE-2022-33070.patch: only shift unsigned values in
lib/protobuf-c/protobuf-c.c.
- CVE-2022-33070
-- Marc Deslauriers <marc.deslauriers@ubuntu.com> Mon, 16 Jan 2023 07:36:33 -0500
In this example they inject running an editor against another file.
I'm guessing you can put arbitrary code in there or point it at a locally controlled executable too. But I'm not sure. Maybe sudoedit puts more scrutiny on that variable than most, non-security programs. At any rate many text editors have lots of modules and scripting and can presumably load and execute code as the privileged user.
The workaround is to change the sudo config file to remove the EDITOR environment variable and a few others.
Sudoedit does not run the editor as privileged user, that is kinda the whole point