3

UPDATE

set -x seems to produce some useful debugging information. systemctl is highly suspect as running systemctl list-units --full --all by itself causes the same reboot. Guess I'll be digging into that.

set -x
service [TAB]
    ...
    etc/init.d/unattended-upgrades /etc/init.d/unscd /etc/init.d/urandom
    + shopt -u nullglob
    + COMPREPLY+=($( systemctl list-units --full --all 2>/dev/null |                   awk '$1 ~ /\.service$/ { sub("\\.service$", "", $1); print $1 }' ))
    ++ systemctl list-units --full --all
    ++ awk '$1 ~ /\.service$/ { sub("\\.service$", "", $1); print $1 }'

    Broadcast message from root@server
        (/dev/pts/1) at 12:02 ...

    The system is going down for reboot NOW!
    + COMPREPLY=($( compgen -W '${COMPREPLY[@]#${sysvdirs[0]}/}' -- "$cur" ))
    ++ compgen -W '${COMPREPLY[@]#${sysvdirs[0]}/}' -- ''
    + [[ -e /etc/mandrake-release ]]
    Connection to server.mydomain.net closed by remote host.
    Connection to server.mydomain.net closed.

I have a virtual machine running Ubuntu 14.04 with latest patches. when I type service+ [TAB] the machine immediately reboots. Other bash completion seems to work fine eg: ls [TAB]. Only completion for service seems to be problematic. The system logs haven't revealed anything obvious yet. If I uninstall the bash-completion package, the problem goes away. Re-installing it, the problem is back. Any ideas where to look for troubleshooting this?

1 Answer 1

0

As it turns out. An admin replaced the /bin/systemctl binary with a shell script which contained the single command reboot. I have no idea why someone would do this but since two people have upvoted this question already, I thought I would answer. I don't even think that command is part of 14.04 (Checked a handful of other machines - it's not there) so that's even more bizarre.

The takeaway worth noting here is that set -x helped me find the problem.

3
  • 2
    You should probably treat this machine as compromised. With something like that done I wouldn't trust it in the slightest. Dec 20, 2017 at 18:46
  • @TimBrigham Especially since booby-trapping systemctl is the sort of thing an attacker might do to keep you from investigating what else had been tampered with... Dec 21, 2017 at 23:40
  • Totally agree however I'm not in a position to do much more than document what I fixed and make a recommendation. Jan 4, 2018 at 14:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .