Bug #18802

Arbitrary shell remote execution on discovery image

Added by Lukas Zapletal about 1 year ago. Updated about 1 year ago.

Assigned To:Lukas Zapletal
Target version:Image 3.3.2
Difficulty:easy Pull request:
Bugzilla link:1429370
Story points-
Velocity based estimate-


It is possible to remote exec arbitrary shell code on discovered satellite note running foreman-discovery-image (all versions).

There is a API to initiate kexec command to replace kernel into Anaconda instlaler to start provisioning. This API is public, unauthenticated, plain HTTPS, accepts JSON, example:

"kernel": "boot/RedHat-5.11-x86_64-vmlinuz",
"initram": "boot/RedHat-5.11-x86_64-initrd.img",
"append": "ks=http://hao-xxxcom:8000/unattended/provision?token=23edd325-7fe4-4992-99ea-059296565b4a&static=yes kssendmac nicdelay=5 ip= netmask= gateway= dns= ksdevice=52:54:00:30:58:ba BOOTIF=00-52-54-00-30-58-ba"

The kexec command is composed and executed via Ruby system command (which indeed spawns a shell) and there is no shell escaping, the vulnerability is pretty clear. The reason why this happened is because the method was used only internally (for shutdown command) and then it was extended:


While this is remote execution and it is pretty serious, keep in mind that discovered hosts are LiveCD running from memory, there is no possible data leak directly from them. The hosts can be abused tho.


#1 Updated by Lukas Zapletal about 1 year ago

  • Status changed from New to Rejected

This was false alarm, Ruby system call does not spawn a shell when array is passed in, therefore there is no way escaping the command line arguments and discovery image is not vulnerable.

#2 Updated by Dominic Cleal about 1 year ago

  • Private changed from Yes to No

Also available in: Atom PDF