Is there a security attention key in FreeBSD?

S

shinchan

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?
 
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.
 
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.
 
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.
Click to expand...
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.
 
shinchan said:
Also, how much improvement can such a sequence actually bring in terms of security?
Click to expand...

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.
 
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.
 
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.
Click to expand...
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...
 
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.
Click to expand...
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.
 
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...
Click to expand...

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.
 
ANOKNUSA said:
If you can access a wheel user account, you have access to the root account.
Click to expand...
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?
 
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.
 
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.
 
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.
Click to expand...

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.
 
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.
 
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.
Click to expand...

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?
 
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.
 
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?
Click to expand...

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.
 
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.
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top