I noticed the following changelog entry in sudo 1.9.5p1. This caught my attention so I decided to look further. I was unable to find an advisory, PoC, or CVE for this vulnerability. Using the details from the changelog message and fix, I decided to write an exploit for it.

Using an Ubuntu 20.04.1 VM, I created a low privileged user named “lowpriv” and added a sudoedit rule for a root owned file /etc/test.txt. I also downloaded the source for sudo 1.9.5, compiled it, and installed it to /opt/sudo.

Show sudoedit rule.

Show the sudo version is 1.9.5.

With the test environment ready I ran sudoedit /etc/test.txt. I executed !id as a quick test which executes the id command in a shell however privileges are dropped by bash when the UID != EUID. Back to the drawing board.

I was able to successfully edit arbitrary files simply using the :e /etc/sudoers or :e /etc/shadow commands to escalate privileges, however that was too easy.
Looking for esoteric features that could potentially be leveraged, I discovered the libcall and libcallnr functions which allow you to execute a function from an external library. The one caveat is there can only be a single argument. There are a crazy amount of functions available to vim that I never realized. Check out https://vim.help/41-write-a-vim-script#41.6 for the full listing.
I tried calling a variety of functions with varying degrees of success but found a simple method by calling setuid() directly.
call libcallnr("libc.so.6","setuid",0)
After running sudoedit, use the following vim/ex command to change the UID to zero. This will ensure that shelling out will retain privileges because now UID==EUID.

Execute a bash shell with !bash.

Interactive root shell obtained. Woot!

I tested the same proof of concept with 1.9.5p1 and sudoedit properly drops privileges as expected.

Summary
If you upgraded to sudo 1.9.5 to fix CVE-2021-23240 or CVE-2021-23239, a new privilege escalation vulnerability was introduced in sudoedit and you should upgrade to 1.9.5p1.
Once in a while I look at recently fixed vulnerabilities to see if I can bypass the fix. In this case, the sudo project knew about this vulnerably but to my knowledge no advisory or CVE was created. I think this is odd that the issue was not communicated since a valid privilege escalation was patched. It’s unclear if another researcher reported it or if maintainers discovered it during their own testing. I also could not find a proof of concept so I decided to write one as a fun exercise.
I hope you enjoyed the short write up. Hit me me up on Twitter @0xm1rch if you have any questions or comments.