# Is there a security attention key in FreeBSD?



## shinchan (Jun 16, 2016)

I'm wondering if there's a secure attention key that aims to prevent a fake login from stealing account passwords in FreeBSD, similar to the `Ctrl+Alt+Del` sequence in Windows.
Also, how much improvement can such a sequence actually bring in terms of security?


----------



## kpa (Jun 16, 2016)

I've never heard of the ctrl+alt+del sequence being referred to as a "security feature" in windows. I have absolutely no idea what you're talking about really.


----------



## shinchan (Jun 16, 2016)

kpa said:


> I've never heard of the ctrl+alt+del sequence being referred to as a "security feature" in windows. I have absolutely no idea what you're talking about really.


It should be 'secure attention key', my mistake. I read about it on https://en.m.wikipedia.org/wiki/Secure_attention_key , and I understand it as a security feature, am I wrong with that?


----------



## kpa (Jun 16, 2016)

Sounds like a nice feature in theory but how is first pressing a keyboard sequence any different from just typing/selecting your user name and entering your password? If you assume that parts of the system are compromised how can you trust the supposedly "secure" login system?

I kinda get what the wikipedia article talks about but that would require special hardware support for displaying a login that can not be tampered with because it's triggered by the special key combination trough the hardware and can not be interfered by the operating system. FreeBSD has no support for such mechanism afaik.

Any software solution wouldn't be secure because you would then have to ask the classic question "who watches the watchers" to convince yourself that the solution is secure and you know where that leads.


----------



## shinchan (Jun 16, 2016)

kpa said:


> Sounds like a nice feature in theory but how is first pressing a keyboard sequence any different from just typing/selecting your user name and entering your password? If you assume that parts of the system are compromised how can you trust the supposedly "secure" login system?
> 
> I kinda get what the wikipedia article talks about but that would require special hardware support for displaying a login that can not be tampered with because it's triggered by the special key combination trough the hardware and can not be interfered by the operating system. FreeBSD has no support for such mechanism afaik.
> 
> Any software solution wouldn't be secure because you would then have to ask the classic question "who watches the watchers" to convince yourself that the solution is secure and you know where that leads.


From what I understand, the feature is only for the case where a normal user (as opposed to the root) is compromised, with the intruder still unable to change how the kernel reacts to `Ctrl+Alt+Del`, and hungrily waiting for the next `su`.

I think the difference between typing a special key sequence and username/password is that: the kernel does not know whether a user is entering a username/password, so it have to forward the keystrokes to the program(maybe a fake login) waiting for the input; while the kernel could simply invoke a predefined program if a secure attention sequence is detected.


----------



## ANOKNUSA (Jun 17, 2016)

shinchan said:


> Also, how much improvement can such a sequence actually bring in terms of security?



None that I can think of. It only protects against one kind of attack, and on a Unix system in which a fake login is installed the intruder has already gained a level of access beyond some lowly user's account.

It's probably much more profitable to attack the source code tree or package repository directly, where a key logger could be installed on an indefinite number of systems and run in the background, gathering more useful information than a user's system login credentials.


----------



## RichardM (Jun 17, 2016)

The SAK feature is a genuine security feature - it's not to do with someone gaining higher user access, but with a malicious user displaying what looks like a genuine login prompt. The next user at the terminal then logs in to the spoof prompt, the malicious program or script then harvests their password, displays some message such as "wrong password" and exits to the genuine login prompt. The user just thinks they have miss-typed their password and continues as though nothing untoward has happened. 

So it's really a "social engineering" security issue, like spoof bank emails. The SAK sequence works by the kernel picking up the key sequence, and killing all processes attached to the terminal, effectively resetting the login program (or X server) so you are sure you are talking to the real login program (or xdm/kdm login). The equivalent in Linux is the Magic SysRq keys.

The only use I can see is something like a public library network, there's little benefit among a group of trusted users.


----------



## shinchan (Jun 23, 2016)

ANOKNUSA said:


> None that I can think of. It only protects against one kind of attack, and on a Unix system in which a fake login is installed the intruder has already gained a level of access beyond some lowly user's account.
> 
> It's probably much more profitable to attack the source code tree or package repository directly, where a key logger could be installed on an indefinite number of systems and run in the background, gathering more useful information than a user's system login credentials.


Maybe the intruder could just compromise a user in the `wheel` group and modify his `$PATH` to present him with a fake `su`, so the intruder doesn't really have to install a fake `login` for the whole system, which roughly means that on a system without the SAK feature, compromise of a `wheel` user will lead to compromise of the whole system. Not sure if I'm understanding correctly though...


----------



## ShelLuser (Jun 23, 2016)

RichardM said:


> The only use I can see is something like a public library network, there's little benefit among a group of trusted users.


But even then this can be easily thwarted (somewhat): always change the active console to something else before you log on.

Personally I prefer relying on remote logins and only using the console when there's a real need such as upgrading the system. After which any login attempts are made in safe mode.


----------



## ANOKNUSA (Jun 23, 2016)

shinchan said:


> Maybe the intruder could just compromise a user in the  wheel group and modify his  $PATH to present him with a fake  su, so the intruder doesn't really have to install a fake  login for the whole system...



The "wheel" group  is defined by access the root account: users in the group are the only ones who can use su, and giving them that privilege is the only purpose of "wheel." If you can access a wheel user account, you have access to the root account. The exception would be accessing the account from a physical machine already logged into that account with an unlocked screen and keyboard, but that's quite possibly more difficult or costly than getting remote access.


----------



## shinchan (Jun 24, 2016)

ANOKNUSA said:


> If you can access a wheel user account, you have access to the root account.


Having difficulty understanding this. An intruder still need to steal the root password when they have access to a wheel account, don't they? And lack of SAK feature will facilitate this final step of getting the password?


----------



## atomicbeef (Jul 1, 2016)

shinchan said:


> Having difficulty understanding this. An intruder still need to steal the root password when they have access to a wheel account, don't they? And lack of SAK feature will facilitate this final step of getting the password?


If the system has security/sudo installed and configured to allow users in `wheel` to run commands as `root`, then no other password is needed to become `root`.


----------



## tingo (Jul 5, 2016)

atomicbeef said:


> If the system has security/sudo installed and configured to allow users in `wheel` to run commands as `root`, then no other password is needed to become `root`.


This is correct, although su and sudo are different things.


----------



## atomicbeef (Jul 5, 2016)

I should've been more clear in my last post. What I meant was that even though you need the `root` password to get access to the `root` account when using su(1), it is very common for sudo(8) to be installed and configured to allow users in `wheel` to run commands as `root`.


----------



## fossette (Jul 11, 2016)

It would be interesting to have such a sequence always trapped by the kernel, but I don't see how it can be implemented with the variety of user interfaces (TTY, GUI/WM and SSH).  Even with SSH, I wonder if the fingerprint it displays at first (when the IP address changes) couldn't just be printed by a criminal, and wait for my response.

Dominique.


----------



## BoggledByBSD (Jul 12, 2016)

atomicbeef said:


> If the system has security/sudo installed and configured to allow users in `wheel` to run commands as `root`, then no other password is needed to become `root`.



Just thought i'd comment on this, because I've always interpreted this as a vulnerability in sudo. If you time-costly and painstakingly set up visudo/sudoers though, sudo can only run specific commands.

A couple of super paranoid/secure bsd and linux's have ditched sudo, like OpenBSD has for doas, I imagine for this reason.


----------



## atomicbeef (Jul 12, 2016)

I don't see that as a vulnerability in sudo(8) at all. If someone were to break into an account in `wheel`, it doesn't really matter if they are restricted to only some commands because they would have full control of the system. The OpenBSD developers created `doas` because they perceived sudo(8) and its configuration to be too complex. The default behavior of `doas` is also identical to the behavior I described before.


----------



## BoggledByBSD (Jul 12, 2016)

atomicbeef said:


> I don't see that as a vulnerability in sudo(8) at all. If someone were to break into an account in `wheel`, it doesn't really matter if they are restricted to only some commands because they would have full control of the system. The OpenBSD developers created `doas` because they perceived sudo(8) and its configuration to be too complex. The default behavior of `doas` is also identical to the behavior I described before.



Isn't that why people who really want security do not use a wheel group in sudoers, but setup sudoers to only run certain things?


----------



## atomicbeef (Jul 12, 2016)

That is one approach, but like you said before, it's very inconvenient. When systems become so secure that too much convenience is sacrificed, they become less maintainable and less secure due to people turning off certain security features when they want to get work done.


----------



## kpa (Jul 12, 2016)

BoggledByBSD said:


> Isn't that why people who really want security do not use a wheel group in sudoers, but setup sudoers to only run certain things?



Access control by a group such as wheel is too coarse grained, it basically allows all or nothing. If someone really wants to have proper controls on what a user can run with elevated privileges there's no other way than denying everything by default and enabling access case by case.


----------



## Murph (Jul 12, 2016)

fossette said:


> It would be interesting to have such a sequence always trapped by the kernel, but I don't see how it can be implemented with the variety of user interfaces (TTY, GUI/WM and SSH).  Even with SSH, I wonder if the fingerprint it displays at first (when the IP address changes) couldn't just be printed by a criminal, and wait for my response.



For generic TTYs, there's really a couple of possible choices: BREAK, or cycling DCD/DTR in the case of a serial type connection.  That's not to make any claim that it would necessarily be feasible or practical to implement, only what I believe as the only choice which has a moderate chance of success for generic traditional Unix login.  Cycling DCD/DTR in the case of getty(8) on a serial line should generally ensure that existing processes are terminated and a fresh session is started by trusted parts of the OS.  In the case of an incoming modem connection, DCD cycling should be automatic (it should be tracking the carrier signal on the line).  In the case of a physical terminal, power cycling the terminal or otherwise causing a hardware reset of the DTE interface should cycle DCD/DTR.  Obviously, that assumes that suitable mastery has been applied to the dark art of getting the correct signalling pins connected on the serial ports.

For SSH, it is irrelevant, as you are making a new connection to a system daemon on a privileged port prior to authentication.  Man in the middle attacks or the daemon itself being compromised are completely different issues to avoiding a local spoofed login prompt.  The situation of walking up to an existing login prompt should simply never exist for SSH.  The fingerprint is secure as long as the underlying crypto is secure.  If any of the local system, local client, remote system, remote daemon, or private keys have been compromised there is a problem, otherwise it can't be spoofed.  The remote daemon does not send the fingerprint across as the critical identifier, it sends the complete public key across, which the local client typically condenses into a digest/fingerprint if/when it needs to present it to the user.  An attacker could easily send the same public key across, but should gain nothing without also being in possession of the corresponding private key.


----------



## rigoletto@ (Jul 13, 2016)

Something like Yubikey may fit the needs of OP about secure login.


----------

