Spamming the Esc key on Karmic bootup causes fsck to quit, leaving a root shell on tty1

[Max Goodhart]

Binary package hint: mountall

Hi,

I discovered this bug on some stock amd64 installs of Ubuntu Karmic with ext4 root partitions. The installed mountall package is version 1.0.

During the normal bootup process, if the user rapidly presses the Esc key, they can catch the initial fsck during startup and cause it to quit. This leaves a maintenance shell running on tty1. X will then start. After GDM is finished loading, the root shell left by fsck can be accessed via CTRL-ALT-F1. Oddly, login is also started on the tty, so input intermittently switches between the login prompt and a root shell.

To reproduce:
1. Reboot.
2. Once usplash logo appears, repeatedly press Esc.
3. After GDM starts, press CTRL-ALT-F1.
4. Run commands in the root shell.

Note: I posted this to mountall because I assume mountall spawns the fsck that gets killed. If this is the wrong place for the bug, I apologize.

Regards,
-C

ProblemType: Bug
Architecture: amd64
Date: Mon Nov 2 23:25:20 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release Candidate amd64 (20091020.3)
Package: mountall 1.0
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: mountall
Uname: Linux 2.6.31-14-generic x86_64

[Johan Kiviniemi (ion)]

I don’t see the basis for marking this as a security vulnerability. The sulogin instance and getty starting on the same tty is a bug, though.

[Max Goodhart (chromakode)]

I flagged as a security vulnerability on the basis that this is a new and unexpected way of getting root on a machine.

While physical access -> root shell is not immediately a critical vulnerability, the concern with this way of getting root is the ease and speed of the process. No external tools are required, exploiting takes a matter of seconds, and the system operates normally after the process. This is particularly a concern for shared computers and computer labs. This trick will likely not be on the radar of sysadmins who have otherwise have taken appropriate precautions (locked BIOS, locked grub, etc) to avoid easy access.

[Johan Kiviniemi (ion)]

Sysadmins who have taken precautions to slightly slow down attackers with physical access could simply set a root password, in which case sulogin requests it.

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

Repeatedly spamming the Escape or Ctrl+C keys has always given you a root shell during boot

[Max Goodhart (chromakode)]

There is still a bug here. As Johan stated, sulogin and getty should not start on the same tty. When fsck is cancelled without an error, it should not open a maintenance shell.

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

There's no way to fix that

[Max Goodhart (chromakode)]

I am a bit troubled by your hastiness to close this bug. Why is it impossible to fix?

[Andreas Turriff (aturriff)]

Not to put too fine a point on it, but why does this not give you a root shell on other Linux distributions? At least, I could not make Gentoo or OpenSUSE provide me with that particular back door.

[Kees Cook (kees)]

"Repeatedly spamming the Escape or Ctrl+C keys has always given you a root shell during boot"

That's not true, actually. The problem is that hitting ESC kills fsck, which mountall reacts like like the drive is failed. In the failed drive case, it should run sulogin on a free tty. This is something that upstart needs to deal with (perhaps vt8?)