isc.sans.edu
Uhm, so, why do you typically use unprivileged service accounts for network services?
Uhm, the affected polkit executable would be pretty pointless without the suid bit, it's the one used to execute things "privileged". Removing the suid bit is mentioned somewhere as a temporary mitigation, but of course this will break some polkit functionality.
execve() without argv[0]. No idea whether the same would hold for FreeBSD. Best just test it, now that some exploit code is available?argc is always at least 1 is really a beginner's error 
pkexec doesn't seem to work on my system. If I try to pkexec whatever program I getError checking for authorization org.freedesktop.policykit.exec: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: get_kinfo_proc() failed for pid 77999: No such processsecurity.bsd.see_other_uids=0
security.bsd.see_other_gids=0
security.bsd.see_jail_proc=0
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_proc_debug=0
kern.randompid=1
github.com
github.com
I wrote the exploit yesterday after qualys shared the info on CVE-2021-4034. Due to the nature of the bug argc has to be 0, i.e we need to execute
execve(cmd, NULL, env). FreeBSD doesn't allow this -- execve returned error rendering this exploit unusable.#include <stdio.h>
#include <unistd.h>
int main() {
char* args[] = { "/bin/ls", "-la", NULL };
execve(*args, NULL, NULL);
perror("oops");
return 42;
}$ cc -o test test.c && ./test. Trace showsexecve("/bin/ls",0x0,0x0) ERR#14 'Bad address'Well, that's nice. Still doesn't change anything about the fact that relying on
argc >= 1 is a severe bug. But it seems it's a somewhat common one, so trying to prevent it makes sense.execve(*args, fake, NULL) where fake is defined as char* fake[] = { NULL };. Passing args like this doesn't trigger the polkit bug (edit: the code is buggy, but the exploit is not usable) but opened a discussion about sanitizing that too.
github.com
jitte@unmei:~ $ ~/CVE-2021-4034.c make
sh: /home/jitte/CVE-2021-4034.c: Permission denied
jitte@unmei:~ $Obviously, his promt ends at
$, so the command executed was ~/CVE-2021-4034.c make. Which makes no sense.vagrant@ubuntu-impish:~/CVE-2021-4034$ make
cc -Wall --shared -fPIC -o pwnkit.so pwnkit.c
cc -Wall cve-2021-4034.c -o cve-2021-4034
echo "module UTF-8// PWNKIT// pwnkit 1" > gconv-modules
mkdir -p GCONV_PATH=.
cp /usr/bin/true GCONV_PATH=./pwnkit.so:.
vagrant@ubuntu-impish:~/CVE-2021-4034$ ./cve-2021-4034
# whoami
root
# exit
argc >= 1 and therefore invalid (stack) accesses. It's perfectly possible a different exploit could be found using this same bug.argv[0], then you can say it's for sure not affected, cause that's preventing this bug in polkit from happening.Bug requires GLib, not glibc. As said in qualys report.
gconv-modules and triggers it by fopen() (Linux way).clerenv() is being called very early in the code. But there was an option to trigger it the way described.execve(cmd, fake, NULL) where fake[] = { NULL }. Also FreeBSD's ld.so has some extra env sanitation in place that makes this a problem.
.section .text
_start:
xorl %edx, %edx
xorl %esi, %esi
leaq shstr, %rdi
movl $59, %eax
syscall
movl %eax, %edi
movl $60, %eax
syscall
shstr: .asciz "/bin/sh"as -o test.o test.s && ld -o test test.o && brandelf -t Linux ./test# truss ./test
linux_execve("/bin/sh",0x0,0x0) ERR#-14 'Bad address'
linux_exit(0xfffffff2)
process exit, rval = 4294967282
#