7 ms·

I think the idea behind ctrl-alt-delete is that it generates a non-maskable interrupt that can't be hooked from user-mode. In days past, this sort of thing was

I think the idea behind ctrl-alt-delete is that it generates a non-maskable interrupt that can't be hooked from user-mode. In days past, this sort of thing was called a secure attention key. https://en.wikipedia.org/wiki/Secure_attention_key https://en.wikipedia.org/wiki/Secure_attention_key And you're right, this needs to be a default part of any login handler. Why don't we use it when logging into a Linux console? The login prompt could easily be spoofed by a user-mode program.

rightos 9y ago
> I think the idea behind ctrl-alt-delete is that it generates a non-maskable interrupt that can't be hooked from user-mode. Keyloggers can still enter the winlogon session and log all keystrokes there, they need to run as a SYSTEM service, but it's very possible to do. I'm surprised this isn't better documented, but it's pretty much as simple as copying the token from the existing Winlogon process, adjusting the privileges appropriately and calling CreateProcessAsUser() with lpDesktop set to Winsta0\Winlogon.
- lmz 9y ago
  If you have keyloggers running as SYSTEM you've already lost.
  - rightos 9y ago
    True, the scenario in which ctrl+alt+del would help is one in which only a limited account had been compromised, but the SYSTEM level winlogon keylogger allows you to do things like turn local admin into network admin and it certainly doesn't require kernel mode access. I was more commenting on the requirement of kernel mode access or hijacking of special interrupts than on the usefulness in general.
- coldtea 9y ago
  >they need to run as a SYSTEM service, but it's very possible to do. That makes their threat a moot point...
acomjean 9y ago
>The login prompt could easily be spoofed by a user-mode program. On the VT100 terminals in the computer lab in college (back in the early 90s) someone was doing this. A shell script to harness logins, print it was unsuccessful and log out. . There was a key at the top of the vt-100 keyboard that would reset it. The "key" part was often pried off (accidental pressing was bad), but you could still press the nub left behind.
- dboreham 9y ago
  In my misspent youth I wrote a login trojan for VAX/VMS. It circumvented the "break" key trick that you are alluding to above. I had to drop down to Bliss-32 and use the $QIO syscall but it can be done. Once I had captured the sysadmin password and logged in once to prove my achievement I never ran it again. Learned many interesting things though. My task was made easier because DEC published the source code for the OS, albeit as Microfiche. I was therefore able to study the terminal handler code and figure out how to make a trojan that perfectly emulated the regular login behavior including all its timeouts and responses to various control keys. Oh, and the VAX-11/780 I had hacked into crashed due to a memory board fault in the minute after I had logged in with my snagged admin password. I spent the remainder of the weekend sweating that I had broken the VAX since I had no idea what had happened. I had just given myself all 32 of the VMS account privileges when it went down.
  - acomjean 9y ago
    > DEC published the source code for the OS, albeit as Microfiche. Wait.... What? Nice job decoding that.
    - dboreham 9y ago
      It was written in Bliss so not so hard if you understand BCPL or C. Also I was 17 and had a lot of time on my hands...
      - Someone 9y ago
michrassena 9y ago
Altering the user's environment is a vector around security. I hadn't considered the sudo angle before, but there's a tradition of invoking binaries from their full path to mitigate the problem. So instead of sudo on its own, you would use /usr/sbin/sudo, and make sure your PATH variable never contains the current directory. Better mitigations disallow executables in users' home folders.
- AstralStorm 9y ago
  Not really. Attacker can execute their own shell from your profile script. Who knows how it will handle paths. Depending on configuration, this can be prevented with noexec mount, selinux or SMACK. Grsecurity and RSBAC can prevent unwanted exec. Systems like apparmor, or grsecurity MAC, TOMOYO or YAMA do not work against executing wrong executables. IMA (signing and verifying files) can work too. All bets are off in case there is a local root exploit in kernel or any setuid app.
caf 9y ago
The Linux console does support a secure attention key that can't be trapped and will kill any process which has /dev/console open. root can configure it with /sbin/loadkeys. Not sure how distributions tend to configure it by default.
- yorwba 9y ago
  I just looked at the table with dumpkeys, but I'm not sure what I'd have to look for to identify that key. sudo dumpkeys | rg --only-matching '=.*' | sort | uniq doesn't show anything that stands out, except maybe for Boot and Break. (But I guess that's a line break?) What would the key do when pressed?
  - caf 9y ago
    The key will kill any process with the console open (which should then cause login to respawn) and log the killed processes. If you want to test it then this will set Ctrl-Alt-Esc as your SAK: echo "control alt keycode 1 = SAK" | loadkeys
- AstralStorm 9y ago
  If magic sysrq is enabled, this is alt+sysrq+k. (Usually sysrq is same key as printscreen)

rightos 9y ago

> I think the idea behind ctrl-alt-delete is that it generates a non-maskable interrupt that can't be hooked from user-mode. Keyloggers can still enter the winlogon session and log all keystrokes there, they need to run as a SYSTEM service, but it's very possible to do. I'm surprised this isn't better documented, but it's pretty much as simple as copying the token from the existing Winlogon process, adjusting the privileges appropriately and calling CreateProcessAsUser() with lpDesktop set to Winsta0\Winlogon.

lmz 9y ago
If you have keyloggers running as SYSTEM you've already lost.
- rightos 9y ago
  True, the scenario in which ctrl+alt+del would help is one in which only a limited account had been compromised, but the SYSTEM level winlogon keylogger allows you to do things like turn local admin into network admin and it certainly doesn't require kernel mode access. I was more commenting on the requirement of kernel mode access or hijacking of special interrupts than on the usefulness in general.
coldtea 9y ago
>they need to run as a SYSTEM service, but it's very possible to do. That makes their threat a moot point...

acomjean 9y ago

>The login prompt could easily be spoofed by a user-mode program. On the VT100 terminals in the computer lab in college (back in the early 90s) someone was doing this. A shell script to harness logins, print it was unsuccessful and log out. . There was a key at the top of the vt-100 keyboard that would reset it. The "key" part was often pried off (accidental pressing was bad), but you could still press the nub left behind.

dboreham 9y ago
In my misspent youth I wrote a login trojan for VAX/VMS. It circumvented the "break" key trick that you are alluding to above. I had to drop down to Bliss-32 and use the $QIO syscall but it can be done. Once I had captured the sysadmin password and logged in once to prove my achievement I never ran it again. Learned many interesting things though. My task was made easier because DEC published the source code for the OS, albeit as Microfiche. I was therefore able to study the terminal handler code and figure out how to make a trojan that perfectly emulated the regular login behavior including all its timeouts and responses to various control keys. Oh, and the VAX-11/780 I had hacked into crashed due to a memory board fault in the minute after I had logged in with my snagged admin password. I spent the remainder of the weekend sweating that I had broken the VAX since I had no idea what had happened. I had just given myself all 32 of the VMS account privileges when it went down.
- acomjean 9y ago
  > DEC published the source code for the OS, albeit as Microfiche. Wait.... What? Nice job decoding that.
  - dboreham 9y ago
    It was written in Bliss so not so hard if you understand BCPL or C. Also I was 17 and had a lot of time on my hands...
    - Someone 9y ago

michrassena 9y ago

Altering the user's environment is a vector around security. I hadn't considered the sudo angle before, but there's a tradition of invoking binaries from their full path to mitigate the problem. So instead of sudo on its own, you would use /usr/sbin/sudo, and make sure your PATH variable never contains the current directory. Better mitigations disallow executables in users' home folders.

AstralStorm 9y ago
Not really. Attacker can execute their own shell from your profile script. Who knows how it will handle paths. Depending on configuration, this can be prevented with noexec mount, selinux or SMACK. Grsecurity and RSBAC can prevent unwanted exec. Systems like apparmor, or grsecurity MAC, TOMOYO or YAMA do not work against executing wrong executables. IMA (signing and verifying files) can work too. All bets are off in case there is a local root exploit in kernel or any setuid app.

caf 9y ago

The Linux console does support a secure attention key that can't be trapped and will kill any process which has /dev/console open. root can configure it with /sbin/loadkeys. Not sure how distributions tend to configure it by default.

yorwba 9y ago
I just looked at the table with dumpkeys, but I'm not sure what I'd have to look for to identify that key. sudo dumpkeys | rg --only-matching '=.*' | sort | uniq doesn't show anything that stands out, except maybe for Boot and Break. (But I guess that's a line break?) What would the key do when pressed?
- caf 9y ago
  The key will kill any process with the console open (which should then cause login to respawn) and log the killed processes. If you want to test it then this will set Ctrl-Alt-Esc as your SAK: echo "control alt keycode 1 = SAK" | loadkeys
AstralStorm 9y ago
If magic sysrq is enabled, this is alt+sysrq+k. (Usually sysrq is same key as printscreen)