On Mon, Jan 18, 2010 Joachim Schipper wrote:> What this patch does can be described as follows: > > Without: > you at local$ ssh somehost > Enter passphrase for RSA key 'foo': > you at somehost$ exit > $ ssh otherhost > Enter passphrase for RSA key 'foo': > you at otherhost$ > > With: > you at local$ ssh somehost > Enter passphrase for RSA key 'foo': > you at somehost$ exit > $ ssh otherhost > you at otherhost$ > > That is, it means you don't have to type the passphrase twice.This sounds very convenient. It also sounds very dangerous. Imagine an attacker has access to your account on a target system. They modify your authorized_keys file to add a command="" (or muck with your .bashrc or similar) to run this script when you connect: #!/bin/bash stty -echo echo -n "Enter passphrase for RSA key 'foo': " read GOTCHA stty echo echo echo "gotcha, passphrase is: '$GOTCHA'" [ And of course a real attack would stash or forward your passphrase, and just exec a shell so you think everything's normal. ] This is a concern with regular ssh setups as well: any time you ssh to a remote host using a passphrase-protected key, the remote host may try feeding you a bogus prompt and you might fall for it, thus giving away your passphrase (which is one of the problems with password-auth that key-auth is supposed to improve on). The ways to avoid ever falling into this trap: 1) Always ssh with -v, and read the verbose messages every time, so you are certain you know where the prompt originated. Not likely. 2) Always ssh-add your passphrases locally first, before ssh'ing anywhere. For best results, set BatchMode=yes by default in ~/.ssh/config so that you will never ever ever be prompted legitimately; the connection will simply fail until you remember to ssh-add. Therefore any time you are ever prompted when ssh'ing somewhere, you are being messed with. Your patch undermines 2). If it became a standard practice to "transparently add a passphrase to the agent the first time a key is used", then people will get used to the behavior that they sometimes have to enter their passphrase when ssh'ing somewhere, and sometimes don't. That will make them more willing victims. It's like sending users "secure" self-extracting encrypted archives, teaching people that it's sometimes OK after all to execute .exe's they receive in emails--undermines best-practice training and will end badly. -- Hank Leininger <hlein at korelogic.com> BE5D FCCA 673B D18B 98A9 3175 896E 3D4A 1B4D C5AC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 447 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20100128/42053ff6/attachment.bin>
> Imagine an attacker has access to your account on a target system.then all bets are off anyway.> The ways to avoid ever falling into this trap: > > 1) Always ssh with -v, and read the verbose messages every time, so you > are certain you know where the prompt originated. Not likely. > > 2) Always ssh-add your passphrases locally first, before ssh'ing > anywhere. For best results, set BatchMode=yes by default in > ~/.ssh/config so that you will never ever ever be prompted > legitimately; the connection will simply fail until you remember > to ssh-add. Therefore any time you are ever prompted when ssh'ing > somewhere, you are being messed with.3) don't turn the option on. nobody's proposing that it be on by default.
Joachim Schipper
2010-Jan-30 18:11 UTC
"phishing" (was: [patch] Automatically add keys to agent)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, Jan 28, 2010 at 04:59:45PM -0500, Hank Leininger wrote:> On Mon, Jan 18, 2010 Joachim Schipper wrote: > > What this patch does can be described as follows: > > > > Without: > > you at local$ ssh somehost > > Enter passphrase for RSA key 'foo': > > you at somehost$ exit > > $ ssh otherhost > > Enter passphrase for RSA key 'foo': > > you at otherhost$ > > > > With: > > you at local$ ssh somehost > > Enter passphrase for RSA key 'foo': > > you at somehost$ exit > > $ ssh otherhost > > you at otherhost$ > > > > That is, it means you don't have to type the passphrase twice. > > This sounds very convenient. > > It also sounds very dangerous. > > Imagine an attacker has access to your account on a target system. They > modify your authorized_keys [or .bashrc] to run [a script prompting > for a passphrase] when you connect.> This is a concern with regular ssh setups as well: [an attacker] may > try feeding you a bogus prompt and you might [enter your passphrase]. > The ways to avoid ever falling into this trap: > > 1) Always ssh with -v, and read the verbose messages every time, so you > are certain you know where the prompt originated. Not likely. > > 2) Always ssh-add your passphrases locally first, before ssh'ing > anywhere. For best results, set BatchMode=yes by default in > ~/.ssh/config so that you will never ever ever be prompted > legitimately; the connection will simply fail until you remember > to ssh-add. Therefore any time you are ever prompted when ssh'ing > somewhere, you are being messed with. > > Your patch undermines 2). If it became a standard practice to > "transparently add a passphrase to the agent the first time a key is > used", then people will get used to the behavior that they sometimes > have to enter their passphrase when ssh'ing somewhere, and sometimes > don't. That will make them more willing victims. (...)I'm sorry for the slow response; I'm in the last stage of writing my thesis, and that's always a busy time. If I understand you correctly, you argue that connecting to malicious hosts is currently secure, and will remain secure, but that it will become easier to convince people to send the passphrase for their key. You are right that this is a concern, but note that an attacker would only learn the passphrase to a key, which should be uninteresting without the key. More importantly, as you note, the current situation is no better. If you currently use keys, the attacker could send another 'Enter passphrase for <keyfile>' message to obtain the passphrase. (And of course, if you currently use passwords, an attacker could obtain your password!) You are not wrong, but isn't this point applicable to a much wider range of cases than those covered by my patch? And do you know why it hasn't been addressed yet? Joachim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (OpenBSD) iQIcBAEBCAAGBQJLZHZMAAoJEIReuCyNazusoEEQAJ7APRDrg+nUr6+F/jgGE7Iy PReeJnTppkSNrIYUBVs0HEnCXIzEpVdqS8S3e1aguEjpqeT6wPnqwQHC/0oRCAa+ Wfv0XiSDYxQvsJA6H693eRgFJgqKBRHfJCEZuYQRxgr77qMSVuQ1GbxGxKG2QpHc pd9VuaIAUCrggUuBbrmKYQhpmWls5b68Qov4OFQFiT7f+MO3sjYbXUFPk1qNjnYO 4N0nN25dllzhQ4d29DZ8CktF30+wJV1H+7zJZmGgHxSt/ONKZayBLBSKOYShZjRE ffPIeQdmL/GBRL7A1FLMELOsteyM82KWFIMXMiL/fJfspwuQyKWIXQIgQ9aJZm8k g4fMMRNDCu/dg8cx5MvS4xLZJ9FmKUTNfKVRU4tj1FL03a2B+qVCLq7yv6UsBULc a3Bh+BXbjCOXMzZp8MYrYUezkyokH3m2txP9nMqsttAIHcS4mEl6sl0c9vZxSYtv i8vivNA47U+QMpL81hBQktTSknoCszYaphYn00xyIDWsJwc+yyTQj8I1kMXdfQ2T RWGZ7z/IsjQ3OrRmOKjQaawhexRsqJdlnDGvUZ1Ee1bWAq/ygvH1ine6uwPrHPhd DeFXte5N1BkiBk8p1qXRpnCraqMYShQSzYSwMJoD1DS69l0e/kVt17KF7iTSoQUU jLYc2Hd9QBiXL0/42u4E =VvvO -----END PGP SIGNATURE-----
On 2010-01-29, joshua stein wrote:> > Imagine an attacker has access to your account on a target system.> then all bets are off anyway.Oh? On the _target_ system. SSH'ing into a possibly compromised system should not put your local system at risk. That's why agent and X11 forwarding default to off in the client, sftp is preferred over scp, etc. [ It would be an interesting exercise to trap ^D / exit / logout, and present a fake originalhost$ prompt, and see what you can collect from someone. From their SSH client version, you may be able to guess their OS's default shell & prompt. But that's another matter. ]> > The ways to avoid ever falling into this trap: > > > > 1) Always ssh with -v, and read the verbose messages every time, so you > > are certain you know where the prompt originated. Not likely. > > > > 2) Always ssh-add your passphrases locally first, before ssh'ing > > anywhere. For best results, set BatchMode=yes by default in[snip]> > 3) don't turn the option on. nobody's proposing that it be on by > default.My point was that this was already a concern, and that those are the ways to avoid being victimized currently. Adding the proposed feature without recognizing this risk could easily lead people to enabling it when it can get them into trouble. I do appreciate that the proposal is to default to 'no', but am concerned that people are talking about the convenience with no regard to the consequences. Thanks, -- Hank Leininger <hlein at korelogic.com> BE5D FCCA 673B D18B 98A9 3175 896E 3D4A 1B4D C5AC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 447 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20100201/a361f0a4/attachment.bin>