Ctl+Alt+Del twice at tty console login gives root access

[Niall Creech]

1. Ctrl-alt-f1 to switch to tty console from X.

2. At login prompt press ctrl-alt-del twice. this produces the message,
"The system has reached a state where there are no jobs running.
A shell will be spawned so that you may start such jobs that are necessary."

This leaves a functional root console, though it appears sometimes to not be functional, it does accept and execute commands.

[finalbeta (j-greenhouse)]

confirmed in edgy. Several other confirm this at : http://www.ubuntuforums.org/showthread.php?t=270620&page=2

[Mark Taylor (skymt0)]

Confirmed here (Edgy with latest updates, upgraded from Dapper).

[Joseph Price (pricechild)]

Confirmed.

I'm agreeing with the idea here: http://ubuntuforums.org/showpost.php?p=1576622&postcount=5

However this is still extremely bad, i could successfully run things such as starting gdm from this cl.

Pricey

[Stefan Glasenhardt (glasen)]

Confirmed.

I've got a full working root-console.

>>I'm agreeing with the idea here: >>http://ubuntuforums.org/showpost.php?p=1576622&postcount=5

Sorry, but this is stupid. There is absolutely no need for such a feature. If the system got ever screwed, you can use the "recovery mode" of Ubuntu. If this is not working you can use an emergency boot-cd.
Every "feature" that comprises system security in such a way, should be considered as a bug and should be fixed as fast as possible.

P.S. :

Imho, if this bug is a design flaw of upstart, it should be replaced by sysvinit until this flaw is fixed, even if this means that upstart will not be shipped with edgy.

[Constantine Evans (cevans)]

Removing /etc/event.d/sulogin will fix the problem, if I understand the situation correctly. However, it should be noted that this appears to be the intended behaviour.

Perhaps this could be changed from execing /sbin/sulogin to something that requires a username/pass that is in sudoers? It is quite unlikely that sudoers and shadow would be inaccessible, and if they were, the user could always boot into single-user.

[Scott James Remnant (Canonical) (canonical-scott)]

I assume that if you press Control-Alt-Delete just once, the machine reboots normally?

Could you run the following for me to confirm that you have the usual packages installed:

  dpkg-query -W upstart upstart-compat-sysv system-services startup-tasks

Please note that the bug here is that the system stalls, rather than rebooting. The fact you get a root shell is intended behaviour, and is NOT a security problem -- the person has physical access to the machine, so could just reboot it and stick init=/bin/sh on the kernel command-line to get the same effect.

[Scott James Remnant (Canonical) (canonical-scott)]

Cute, I can replicate this too.

You have to press Ctrl-Alt-Del pretty quickly to make it happen -- and interestingly it just kills off the gettys, and not a running X server.

[Niall Creech (sevenmachines-deactivatedaccount)]

# dpkg-query -W upstart upstart-compat-sysv system-services startup-tasks
upstart 0.2.7-4
upstart-compat-sysv 0.2.7-4
system-services 0.2.7-4
startup-tasks 0.2.7-4

[Niall Creech (sevenmachines-deactivatedaccount)]

i can understand that physical access to the machine will opens up a number of methods of gaining root access, pressing ctrl-alt-delete twice and getting a root console just seems a little bit too simple for my liking.

[Niall Creech (sevenmachines-deactivatedaccount)]

ctrl-alt-delete once does indeed reboot, though with no sign this is happening, probably why i kept pressing ctrl-alt-delete and got the root shell the first time

[Scott James Remnant (Canonical) (canonical-scott)]

Thanks, I can confirm this here as well. It looks like the effect of two shutdowns is cancelling each other out -- curious.

Could you try something for me ... in X run "sudo initctl events", when C-A-F1, then C-A-D twice

Switch back to X (A-F7) and you should see a list of events. I'm expecting something like:

  ctrlaltdel
  shutdown
  ctrlaltdel
  shutdown

[Niall Creech (sevenmachines-deactivatedaccount)]

unfortunately doing this brings down X using both fglrx and vesa drivers so im not sure i can get the initctl results. ive attached the running processes after ctrl-alt-del twice.

[Niall Creech (sevenmachines-deactivatedaccount)]

heres "initctl list" after Ctl+Alt+Del twice and then resurrecting with "telinit 3" if it helps

# initctl list
rc0 (stop) waiting
rc0-halt (stop) waiting
rc0-poweroff (stop) waiting
rc1 (stop) waiting
rc2 (stop) waiting
rc3 (stop) waiting
rc4 (stop) waiting
rc5 (stop) waiting
rc6 (stop) waiting
rcS (stop) waiting
rcS-sulogin (stop) waiting
logd (stop) waiting
tty1 (start) running, process 6412 active
tty2 (start) running, process 5403 active
tty3 (start) running, process 5406 active
tty4 (start) running, process 5409 active
tty5 (start) running, process 5412 active
tty6 (start) running, process 5414 active
sulogin (start) running, process 5201 active
rc-default (stop) waiting
control-alt-delete (stop) waiting

[Scott James Remnant (Canonical) (canonical-scott)]

I think that what's happening is that the second shutdown causes the first one to be cancelled (rc6 gets stopped on the shutdown event)

In theory the second shutdown should then work normally, however cancelling the first shutdown *does not* change the runlevel (it leaves it in 6) ... this means that /etc/init.d/rc doesn't bother running any of the rc6 scripts because there's no reason to.

Thus the system stalls, and you get a root shell.

[Niall Creech (sevenmachines-deactivatedaccount)]

after telinit back to runlevel 3 and X i get all the getty's back working fine. the 1st console now shows the login prompt but responds "command not found" when trying to log in and drops you into a root shell for as long as it takes to time out the login. i cant see what im typing in this root shell anymore but it still accepts root authorized commands

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2006-10-04 at 10:38 +0000, Dinxter wrote:

> after telinit back to runlevel 3 and X i get all the getty's back
> working fine. the 1st console now shows the login prompt but responds
> "command not found" when trying to log in and drops you into a root
> shell for as long as it takes to time out the login. i cant see what im
> typing in this root shell anymore but it still accepts root authorized
> commands
>
That's a known bug with that shell -- just type "exit"

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

Ok, I have confirmed what is happening here.

 - runlevel = 2, prevlevel=N
 - Control-Alt-Delete is pressed
 - ctrlaltdel event is emitted
 - control-alt-delete job is started
 - runs shutdown -r now
 - init receives SHUTDOWN request with "reboot" event
 - shutdown event is emitted
 - tty jobs are stopped
 - no jobs running, system is idle
 - reboot event is emitted
 - rc6 job is started
 - runlevel = 6, prevlevel=2
 - runs /etc/init.d/rc 6
 - begins iterating scripts

 - Control-Alt-Delete is pressed again
 - ctrlaltdel event is emitted
 - control-alt-delete job is started
 - runs shutdown -r now
 - init receives SHUTDOWN request with "reboot" event
 - shutdown event is emitted
 - running rc6 job is stopped
 - no jobs running, system is idle
 - reboot event is emitted
 - rc6 job is started
 - runlevel = 6, prevlevel = 6
 - runs /etc/init.d/rc 6
 - doesn't run K scripts because there was a K script in the "previous runlevel" and no S script
 - doesn't run S scripts because there was an S script in the "previous runlevel" and no K script in this
 - rc6 job exits normally

 - no jobs running, system has stalled
 - stalled event is emitted
 - sulogin job is started
 - runs /sbin/sulogin

[Scott James Remnant (Canonical) (canonical-scott)]

So the problem is that running "rc 6" when the "current runlevel" (as determined by /var/run/utmp) is 6 does nothing.

The same bug would occur if you put "shutdown -h now" inside /etc/rc0.d, it would cancel the running shutdown, and then do nothing.

sysvinit handles this simply by not allowing a change from to the same runlevel as the current one. We could replicate that fix by making shutdown (and telinit) check the runlevel first -- currently they just send the event regardless.

There's another semi-bug here, if you press Ctrl-Alt-Del while "shutdown -h now" (not -r) is running, then the flip is from runlevel 0 to runlevel 6; this is something sysvinit allows -- and responds badly to. sysv-rc skips everything except the final S90reboot script because everything else exists in the previous runlevel.

upstart exhibits the same behaviour in that circumstance.

[Scott James Remnant (Canonical) (canonical-scott)]

My suggested fix is to add the following to the top of /etc/event.d/rc6 and /etc/event.d/rc0*

    set $(runlevel || true)
    if [ "$2" = "0" ] || [ "$2" = "6" ]; then
        runlevel --set "$1" || true
    fi

This means that if runlevel 0 or 6 are entered from either of those two runlevels, the PREVIOUS runlevel is restored. This will have the following behaviour:

 - Ctrl-Alt-Del pressed
 - runlevel = 2, prevlevel = N
 - rc6 runs
 - runlevel = 6, prevlevel = 2
 - runs /etc/init.d/rc 6

 - Ctrl-Alt-Del pressed
 - rc6 runs again
 - runlevel = 2, prevlevel = 6 (caused by the above script snippet)
 - runlevel = 6, prevlevel = 2 (caused by the start of the remainder of the script)
 - runs /etc/init.d/rc 6

The result will be that whenever halt or reboot are run from within runlevel 0 or runlevel 6, the entire /etc/rc0.d or /etc/rc6.d sequence is run.

This should give correct behaviour from "halt within halt", "reboot within reboot" AND "reboot within halt"

[Scott James Remnant (Canonical) (canonical-scott)]

The following would be neater, replace the current set call with

    set $(runlevel || true)
    if [ "$2" != "0" ] && [ "$2" != "6" ]; then
        set $(runlevel --set 6 || true)
    fi

That way we just don't bother storing the value in /var/run/utmp, and go with what's already there. /etc/init.d/rc overrides the value of RUNLEVEL with the argument its given, so the effect will be just that the PREVLEVEL remains unchanged.

[Scott James Remnant (Canonical) (canonical-scott)]

 upstart (0.2.7-5) edgy; urgency=low
 .
   * Don't set the current runlevel in /var/run/utmp to 0 or 6 if it is
     already either of those two values. That way we don't end up with
     either 0 or 6 in the PREVLEVEL variable, which can cause
     /etc/init.d/rc to be "efficient" and not bother doing
     anything. Ubuntu: #63852.

[Niall Creech (sevenmachines-deactivatedaccount)]

i added

set $(runlevel || true)
    if [ "$2" = "0" ] || [ "$2" = "6" ]; then
        runlevel --set "$1" || true
    fi

to the script section of the files you mentioned before and it does fix the problems of shutdown -h now and ctrl-alt-delete and of the double control-alt-delete.

is the neater solution to go into the same files as replacement for the complete script/end script sections?

[Scott James Remnant (Canonical) (canonical-scott)]

Not sure what you mean?

[Niall Creech (sevenmachines-deactivatedaccount)]

sorry, i carry out alterations to the same rc6, rc0* files but instead of adding,

 set $(runlevel || true)
    if [ "$2" = "0" ] || [ "$2" = "6" ]; then
        runlevel --set "$1" || true
    fi

i add,

  set $(runlevel || true)
    if [ "$2" != "0" ] && [ "$2" != "6" ]; then
        set $(runlevel --set 6 || true)
    fi

[Niall Creech (sevenmachines-deactivatedaccount)]

FIXED:
just to confirm this bug is fixed here on upgrade,
upstart-compat-sysv (0.2.7-4) to 0.2.7-5