Solved Resume after suspend vulnerable to break in

Stefan G.

New Member


Messages: 11

My Thinkpad T480 suspends and resumes successfully and with no problems. However, I noticed that if I hit Ctrl-C a few times during the resume process, I kill X and the screen saver and get a password-free access to the shell. This is a major vulnerability and I hope there is a fix for it. Has anyone been able to work out a security fix for this? At this point any other security measures like full disk encryption and firewalls are practically useless.

Using 12.2-RELEASE
 

tingo

Son of Beastie

Reaction score: 632
Messages: 2,534

If you leave your computer somewhere where other can have physical access to it, it is not secure - you can't trust it.
(I'm not saying that the vulnerability you have discovered isn't serious - it should be fixed)
 
OP
Stefan G.

Stefan G.

New Member


Messages: 11

You're saying that the rc.resume should already capture SIGINT, or that I should change it to do so?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 11,951
Messages: 38,395

I'm not sure where it should go, but that's the typical solution to prevent scripts from being interrupted. If the rc.resume script gets run when the laptop comes out of resume that would be the best place for it. But to be honest I'm not even sure if this is captured with any boot script. Someone could just turn the machine off, let it boot and interrupt that. Same risk. Or even better, simply boot to single user mode and get a nice root prompt without password.
 
OP
Stefan G.

Stefan G.

New Member


Messages: 11

The full disk encryption will stop anyone from booting if they don't know the encryption key. The single point of failure is the resume, because a lost or stolen laptop can be broken into in less than a minute. I'll try capturing SIGINT and report my findings back here.
 
OP
Stefan G.

Stefan G.

New Member


Messages: 11

Apparently, /etc/rc.resume runs after the actual resume, so setting up any traps or protections in it is too late. Does anyone know what actually runs the resume process? I've been unable to find anything in the manual or searching online.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 11,951
Messages: 38,395

Does anyone know what actually runs the resume process?
Good question, had to look it up actually. It seems to get kicked off through /etc/apmd.conf:
Code:
apm_event NORMRESUME {
        exec "/etc/rc.resume apm suspend";
}

apm_event STANDBYRESUME {
        exec "/etc/rc.resume apm standby";
}
 

T-Daemon

Daemon

Reaction score: 825
Messages: 1,675

I noticed that if I hit Ctrl-C a few times during the resume process, I kill X and the screen saver and get a password-free access to the shell.
Does it help when running startx ; exit? It should log out the user when X (and screen saver) is Ctrl-C killed. Instead of " exit" security/vlock can be used to lock the console.
 
OP
Stefan G.

Stefan G.

New Member


Messages: 11

Does it help when running startx ; exit? It should log out the user when X (and screen saver) is Ctrl-C killed. Instead of " exit" security/vlock can be used to lock the console.
Unfortunately, no. Closing the lid puts the laptop in S3. Opening it again briefly shows services coming back up in text mode. This last about 4-5 seconds. After that the OS state is restored back into X or wherever you left off before you closed the lid. During those 4-5 seconds, rapid hitting the Ctrl-C throws you in a password-free terminal shell logged in as the current user.
 

genneko

Member

Reaction score: 16
Messages: 52

Thanks for an interesting topic.
I can see the following lines in /etc/devd.conf on my 12.2 host.
Code:
notify 10 {
        match "system"          "ACPI";
        match "subsystem"       "Resume";
        action "/etc/rc.resume acpi $notify";
};

BTW, I'm also using T480.
 

vigole

Daemon

Reaction score: 1,415
Messages: 1,240

Fixing a bug starts with reproducing it - at least, on one other identical hardware with reasonably identical software.
Otherwise it's rather unwise to call it a vulnerability or security issue. I don't intend to dismiss the possibility, though.
Presently, all I can see is PEBCAK or an unfortunate anecdotal experience. Hence it's better to quit using such terms.
 
OP
Stefan G.

Stefan G.

New Member


Messages: 11

I can see the following lines in /etc/devd.conf on my 12.2 host.
I added
Code:
slock
to /usr/local/etc/devd/acpi_lock.conf which works great to lock X on suspend. However, the problem of killing X including the screen lock on the way back still persists.

I can see is PEBCAK or an unfortunate anecdotal experience.
Thanks for your input but I fail to see how this is PEBCAK on a freshly installed OS.

Attached is a screenshot of the wake up process. Ctrl-C begins to catch on right around where the bell pepper is and breaks X a bit after.

freebsd.jpg


Any thoughts?
 

T-Daemon

Daemon

Reaction score: 825
Messages: 1,675

However, the problem of killing X including the screen lock on the way back still persists.
Try locking the console with security/vlock immediate after the initialization of the X server, putting startx(1) (xinit(1)) in the background (instead of trying to automatic exit or lock if X is killed during resume, as suggested in my previous posting). You could try putting startx in the background only, but locking the console would put an extra security layer.

To avoid X server and in X running programs polluting the console with messages, redirect them somewhere else (the command can be abbreviated with an alias).

startx &> /dev/null & vlock

Alternatively redirect into a log file:

startx &> /tmp/xorg.log & vlock

suspend/resume/Ctrl-C repeatedly

This should make it impossible to SIGINT the X server (as startx is running as job in the background) and security/vlock doesn't catch SIGINT .

In case the above works out, and you prefer a log file, you might want to enable clear_tmp_enable="YES" in /etc/rc.conf or create a tmpfs(5) /tmp (see /etc/defaults/rc.conf) to avoid filling up /tmp.

Or as an alternative a login manager, eg. x11/xdm, should also prevent exposing a logged in, password free, startx initializing virtual console user shell.
 
OP
Stefan G.

Stefan G.

New Member


Messages: 11

Thanks! That worked.

startx &> /tmp/xorg.log & vlock

Using x11/xdm did not work, but that's okay because I don't like using graphical login managers.
 
Top