4 ms·

For something like that to work an attacker would have to add into ~/.ssh/config (on each intermediate server) lines mentioned in another recent post Contr

by xaduha 4y ago

For something like that to work an attacker would have to add into ~/.ssh/config (on each intermediate server) lines mentioned in another recent post ControlMaster auto ControlPath ~/.ssh/github.sock ControlPersist 999999999s ServerAliveInterval 0 without me noticing to sort of cache presence check. In which case they have access to my account already and presence or absence of 'ForwardAgent yes' makes no difference since they can add it if they want. A paranoid answer to that is to use something like /usr/bin/ssh -F /dev/null -A user@fqdn.example.org everytime without an alias, of course. And only plugging in your security key when you need it.

tialaramex 4y ago
Your description is very confusing, either I don't understand your explanation or you misunderstood. ForwardAgent is a decision for your client, so an attacker's change to some intermediate can't cause your client to set ForwardAgent. Lots of modern SSH users do not have ForwardAgent, at all, it's just not necessary for them, so an intermediate server doesn't have the opportunity to do anything with it. I also don't see how this is relevant anyway. My point was that although you will probably be asked to touch your FIDO token to authenticate to SSH servers, that's actually not technically the default, cheap tokens figured since WebAuthn is the majority use of FIDO, and since they're allowed to volunteer UP which WebAuthn wants, they can just ignore the UP flag on the request side and always do user presence testing. But the FIDO design does not require this, and so we can't know whether some/ all/ most tokens in say ten years time have this behaviour.
- xaduha 4y ago
  What I described there is a current, practical way to bypass subsequent presence checks in my particular security key (Google Titan NFC) which I tried out too. What you're talking about is that some hardware implementations might be lax about user presence checks which is true, but doesn't affect any particular user (e.g. me) if they know that their key doesn't allow logging in without it. > so we can't know whether some/ all/ most tokens in say ten years time have this behaviour. I've used some U2F applets like this one https://github.com/tsenger/CCU2F https://github.com/tsenger/CCU2F which bypass presence checks, so yes I'm aware it's not a requirement, but it basically has to be a vulnerability on the hardware/applet level. So I guess don't use NONAME hardware is your advice, is that it?
  - tialaramex 4y ago
    No, it's not about a "vulnerability". The FIDO Authenticator gets a request saying here's some parameters to sign, and most of it is much too high level for some cheap electronics to grasp (some of it is already just a SHA256 anyway, most of the rest can be just treated as bits with no particular meaning) but a handful of bitflags mean something to the authenticator. The authenticator must understand them, comply if able, and, if able and complying, set appropriate flags in the signed message. The two we most care about today for end users are UP and UV. UP "User Present" means I checked there's a user present, e.g. I flashed an LED and somebody tapped the button. UV "User Verified" means I checked my owner is present, e.g. I have a fingerprint reader and the fingerprint matched. Remember the main purpose people buy these things for is WebAuthn (the successor to U2F on web sites). For WebAuthn setting UP is always mandatory, your browser will, on every single request, set the UP flag, it always wants UP. It might set UV in some cases, but there aren't non-test public sites using this feature although it does exist in WebAuthn, it's obviously intended for the case where WebAuthn is both factors, e.g. something you have (the FIDO authenticator) and something you are (fingerprint to activate it) Now, OpenSSH uses the same FIDO authenticators, but while Google is happy you are using the Google Titan NFC for this that's not why they made it. OpenSSH chooses not to set UP by default. A remote server (I think) can tell the SSH client hey, I need UP, get me UP or else you can't log in. But without that UP is not set in the signature request. Most cheap authenticators today just ignore the UP flag in the request because it's easier to just assume it's always there since WebAuthn will always set UP. So even though OpenSSH actually says "No worries, I don't care if the user is present" these FIDO authenticators happen to require UP anyway, typically in the form of a touch sensor or hardware button. Since they're requiring UP I think they set the bitflag accordingly, if it was absent when required in WebAuthn you'd notice because nothing works [The WebAuthn spec. calls out verifying this flag is present as one of the steps to validate a signed response] You can definitely imagine a vendor focused on SSH ease-of-use would offer FIDO authenticators that care whether UP was requested and if it's not requested they don't need the extra press. For the vast majority of SSH users these products are more convenient, and if there's some case where they need UP the SSH protocol already can request that when you ask for it, so you should already be doing that if you want it, not relying on your device happening to do presence detection anyway. I do not have a crystal ball. So that's why I can't tell if the present situation (they tend to do UP anyway because it was easier) is also what the future looks like.

by xaduha 4y ago

tialaramex 4y ago

Your description is very confusing, either I don't understand your explanation or you misunderstood. ForwardAgent is a decision for your client, so an attacker's change to some intermediate can't cause your client to set ForwardAgent. Lots of modern SSH users do not have ForwardAgent, at all, it's just not necessary for them, so an intermediate server doesn't have the opportunity to do anything with it. I also don't see how this is relevant anyway. My point was that although you will probably be asked to touch your FIDO token to authenticate to SSH servers, that's actually not technically the default, cheap tokens figured since WebAuthn is the majority use of FIDO, and since they're allowed to volunteer UP which WebAuthn wants, they can just ignore the UP flag on the request side and always do user presence testing. But the FIDO design does not require this, and so we can't know whether some/ all/ most tokens in say ten years time have this behaviour.

xaduha 4y ago
What I described there is a current, practical way to bypass subsequent presence checks in my particular security key (Google Titan NFC) which I tried out too. What you're talking about is that some hardware implementations might be lax about user presence checks which is true, but doesn't affect any particular user (e.g. me) if they know that their key doesn't allow logging in without it. > so we can't know whether some/ all/ most tokens in say ten years time have this behaviour. I've used some U2F applets like this one https://github.com/tsenger/CCU2F https://github.com/tsenger/CCU2F which bypass presence checks, so yes I'm aware it's not a requirement, but it basically has to be a vulnerability on the hardware/applet level. So I guess don't use NONAME hardware is your advice, is that it?
- tialaramex 4y ago
  No, it's not about a "vulnerability". The FIDO Authenticator gets a request saying here's some parameters to sign, and most of it is much too high level for some cheap electronics to grasp (some of it is already just a SHA256 anyway, most of the rest can be just treated as bits with no particular meaning) but a handful of bitflags mean something to the authenticator. The authenticator must understand them, comply if able, and, if able and complying, set appropriate flags in the signed message. The two we most care about today for end users are UP and UV. UP "User Present" means I checked there's a user present, e.g. I flashed an LED and somebody tapped the button. UV "User Verified" means I checked my owner is present, e.g. I have a fingerprint reader and the fingerprint matched. Remember the main purpose people buy these things for is WebAuthn (the successor to U2F on web sites). For WebAuthn setting UP is always mandatory, your browser will, on every single request, set the UP flag, it always wants UP. It might set UV in some cases, but there aren't non-test public sites using this feature although it does exist in WebAuthn, it's obviously intended for the case where WebAuthn is both factors, e.g. something you have (the FIDO authenticator) and something you are (fingerprint to activate it) Now, OpenSSH uses the same FIDO authenticators, but while Google is happy you are using the Google Titan NFC for this that's not why they made it. OpenSSH chooses not to set UP by default. A remote server (I think) can tell the SSH client hey, I need UP, get me UP or else you can't log in. But without that UP is not set in the signature request. Most cheap authenticators today just ignore the UP flag in the request because it's easier to just assume it's always there since WebAuthn will always set UP. So even though OpenSSH actually says "No worries, I don't care if the user is present" these FIDO authenticators happen to require UP anyway, typically in the form of a touch sensor or hardware button. Since they're requiring UP I think they set the bitflag accordingly, if it was absent when required in WebAuthn you'd notice because nothing works [The WebAuthn spec. calls out verifying this flag is present as one of the steps to validate a signed response] You can definitely imagine a vendor focused on SSH ease-of-use would offer FIDO authenticators that care whether UP was requested and if it's not requested they don't need the extra press. For the vast majority of SSH users these products are more convenient, and if there's some case where they need UP the SSH protocol already can request that when you ask for it, so you should already be doing that if you want it, not relying on your device happening to do presence detection anyway. I do not have a crystal ball. So that's why I can't tell if the present situation (they tend to do UP anyway because it was easier) is also what the future looks like.