>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.

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.

> DEC published the source code for the OS, albeit as Microfiche.

Wait.... What?

Nice job decoding that.

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...

I think (s)he wonders how you read that.

My guess would be that you did using the microfiche reader at your university or at a library. Before digitization, such devices were fairly common wherever people had a lot of text to archive.

(Aside: https://en.wikipedia.org/wiki/Microform even has a photo of a “DuKane brand microfiche reader with source code printed on the films.”. I couldn’t read enough of the text on the envelope to decide whether that is true from the photograph

Oh yeah. I worked at a defense contractor so we had facilities to read and print out Microfiche.

30 or so years later I bought a huge stack of DEC microfiche on eBay so I could still do it if I wanted. I don't have equipment to read it though.

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.

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?

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

If magic sysrq is enabled, this is alt+sysrq+k. (Usually sysrq is same key as printscreen)

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.

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.

> 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.

If you have keyloggers running as SYSTEM you've already lost.

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.

>they need to run as a SYSTEM service, but it's very possible to do.

That makes their threat a moot point...