Heh, I just compiled my kernel with a similar patch too, will see if anything breaks tomorrow when I boot the machine again :D
I think we don’t need to do it that late – OpenBSD does it after copying args because that’s where they count argc, but it seems that we just receive the argc in do_execve already (at least I couldn’t quickly find any argc++ in the copy function). My current patch does it right after the MAC check.
The reason I did it where I did was so that the sysentvec’s copyout_strings can do its thing and we still take the result in the context in which is was meant. On amd64, the default exec_copyout_strings is used. However, there could be the case where some architecture uses a non-default exec_copyout_strings, thereby potentially modifying the argument count.
Following up: I just now realized I should’ve put that reasoning in the commit message itself. I’ll update the GitLab issue accordingly.
I’m also going to wait to MFC it to 13-STABLE/12-STABLE for a little bit. There’s a 14-CURRENT/amd64 package build going right now. Once that completes, I’ll start a new package build with this change included. Once that package build completes successfully, I’ll do the MFC.
Proof of concept exploit was really simple, and if anybody is interested, I created one yesterday - https://github.com/arthepsy/CVE-2021-4034. But I guess, today the Internet will flow with PoCs and they won’t be hard to find.
Nice. Yours looks broadly similar to the one that was making the rounds yesterday afternoon. They weren’t hard to find yesterday. I suspect they’ll be weaponized today :-)
It’s already been refined to this which is still super noisy but doesn’t need a compiler on the target system. I suspect that one is good enough to make a metasploit module.
This vulnerability is one of our most beautiful discoveries; to honor its memory, we recommend listening to DJ Pone’s “Falken’s Maze” (double pun intended) while reading this advisory.
I know CVEs nowadays have fancy catch phrases and logos, but this is the first I’ve seen with a recommended soundtrack.
It’s another freedesktop.org “thing”: polkit to d-bus to authentication agents to dialog boxes pop:ing up saying “hey in order to do this and that you need to give the password for this account/role/…”.
Taking a page from OpenBSD, I just committed a mitigation in HardenedBSD that would prevent exploitation of these kinds of bugs generally: https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/b6495ff2ff4135f951619c28aa321b6c5ad550b9
Heh, I just compiled my kernel with a similar patch too, will see if anything breaks tomorrow when I boot the machine again :D
I think we don’t need to do it that late – OpenBSD does it after copying args because that’s where they count
argc, but it seems that we just receive the argc indo_execvealready (at least I couldn’t quickly find anyargc++in the copy function). My current patch does it right after the MAC check.The reason I did it where I did was so that the sysentvec’s copyout_strings can do its thing and we still take the result in the context in which is was meant. On amd64, the default exec_copyout_strings is used. However, there could be the case where some architecture uses a non-default exec_copyout_strings, thereby potentially modifying the argument count.
Following up: I just now realized I should’ve put that reasoning in the commit message itself. I’ll update the GitLab issue accordingly.
I’m also going to wait to MFC it to 13-STABLE/12-STABLE for a little bit. There’s a 14-CURRENT/amd64 package build going right now. Once that completes, I’ll start a new package build with this change included. Once that package build completes successfully, I’ll do the MFC.
Ha, upstream has already landed this, doing it even earlier (
kern_execve) \o/Yup. I reverted their side of the patch in favor of ours. Theirs has the advantage of performance, while ours has the advantage of enhanced security.
Given that the likelihood of being affected by these types of vulnerabilities is pretty small, I think the performance tradeoff is fine.
Proof of concept exploit was really simple, and if anybody is interested, I created one yesterday - https://github.com/arthepsy/CVE-2021-4034. But I guess, today the Internet will flow with PoCs and they won’t be hard to find.
Nice. Yours looks broadly similar to the one that was making the rounds yesterday afternoon. They weren’t hard to find yesterday. I suspect they’ll be weaponized today :-)
It’s already been refined to this which is still super noisy but doesn’t need a compiler on the target system. I suspect that one is good enough to make a metasploit module.
I know CVEs nowadays have fancy catch phrases and logos, but this is the first I’ve seen with a recommended soundtrack.
I guess I’ll ask the obvious question: if this program just does the same thing sudo does, why does it exist?
It’s another freedesktop.org “thing”: polkit to d-bus to authentication agents to dialog boxes pop:ing up saying “hey in order to do this and that you need to give the password for this account/role/…”.