svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh

[Benjamin Kaduk]

On Sun, 8 Mar 2015, Slawa Olhovchenkov wrote:

> On Thu, Mar 05, 2015 at 08:14:59PM -0500, Benjamin Kaduk wrote:
>
> > On Thu, 5 Mar 2015, Slawa Olhovchenkov wrote:
> >
> > > On Thu, Mar 05, 2015 at 10:11:43AM -0500, Benjamin Kaduk wrote:
> > >
> > > > On Thu, Mar 5, 2015 at 9:40 AM, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:
> > > >
> > > > Speaking as an upstream maintainer: don't use kerberized telnet.
> > >
> > > I am use this for test kerberos setup (check all setup correctly).
> >
> > I use ssh to test kerberos setups (I think sshd has better error message,
> > for one).
>
> I don't see any error message from ssh (about kerberos), ssh just ask
> password if any problem. What a problem? Silent.

I said sshd, not ssh.  ssh's output is not great; ssh -v just tells you
that it's moving on to the next mechanims (password), which you could
guess because it's asking for a password.

But the kerberos client generally doesn't get a very informative error
message anyway, since that could give too much information to an attacker
-- the really useful parts will always be on the server side.

> For debug ssh+kerberos I need stop sshd and run sshd with -D and -d.

You can easily start a new sshd on a high port and leave the old one
running.

> And in this case debug messages very stranges for me.

They will be less strange if you use it a lot :)

> Also, telnet use less dependes and less restrictions. This is good for
> step-to-step debug.

I'm not sure what dependencies are a concern given that ssh is in the base
system.

What does youre step-to-step debug procedure look like?
Mine is mostly just "use kinit to check that I can get a TGT", and then
"use ssh to check that I can get a working service ticket".  There could
be an intermediate "use kgetcred to check that I can get a service ticket
at all", but I usually skip it since I have lots of practice with ssh.
Are there other steps I am missing?

> > The problem with using telnet to test the kerberos setup is that if your
> > kerberos setup works with telnet, you have the DES enctypes (weak
> > cryptography) enabled.  This means that the whole setup, even things
> > other
>
> What you talk about DES? I don't see nothing about AES/DES/etc in krb5.conf.

It would be allow_weak_crypto most likely, not an explicit list.
See
https://svnweb.freebsd.org/base/head/crypto/heimdal/appl/telnet/libtelnet/kerberos5.c?revision=233294&view=markup#l247
for where the client forces DES to be used.

I also didn't mention the weak CFB cipher mode used, earlier.

> > than telnet, are suffering from the vulnerabilities of weak crypto.
> > Kerberos distributions have disabled DES by default for many years, now --
> > Apple has even completely removed the code for them from recent releases
> > of OS X!  Please see RFC 6649.
>
> I don't enable DES. And I have working kerberized telnet. What you
> talk about?

Supposedly there are patches to enable 3DES (but still CFB).
Perhaps you could show the 'klist -v' output to remove some confusion

> > > > I use kerberized ssh all the time; please tell me more about how it is
> > > > broken (a new thread would be best).
> > >
> > > kerberized ssh broken in SSO mode: you can't do ssh login to
> >
> > I have a very different idea of what "SSO mode" means: I run kinit on my
> > local machine and then use kerberos to authenticate to remote
> > services.  I
>
> SSO (for me) is from Windows world: you login in desktop and don't
> need to enter password anymore.

"desktop" is important -- it is a local machine.  It's not giving your
password to the remote server.

> > should never type my password at something which is not a trusted local
> > binary.
>
> As I know, you can't use kerberos outside controled perimeter (with
> working NTP sync, revers DNS and etc). I.e. from random [network]
> place you can't run kinit on local machine [notebook] and use kerberos
> to ssh login.
>
> For may case this is requirement.

I use kinit on my local machine and use kerberos to ssh login from all
sorts of weird environments.  The use of reverse DNS can be disabled;
libkrb5 can store a time offset to correct for some classes of clock
errors.

Maybe your KDC is firewalled off?  I know that trying to reason with
sysadmins can frequently be a lost cause, but the kerberos protocol is
explicitly designed to run over an untrusted network.

> And for untrusted binary -- why don't use kerberos with OTP?

It helps a little bit, but frankly, all the existing kerberos/OTP
solutions are not all that good.

> > > kerberized host (from outside world), input kerberos password and use
> > > kerberos ticket.
> >
> > "input kerberos password and use kerberos ticket" doesn't make sense --
> > you are not using your kerberos ticket; you are using your password.
> > PAM
>
> I am use kerberos ticket for passwordless login to internal hosts
> (after using password for login to gateway host).
>
> > is going off and getting a ticket, sure (and hopefully validating it
> > against the host keytab to avoid the Zanarotti attack!), but it is
> > starting with your password.  That is completely at odds with how Kerberos
> > is intended to be used.
>
> Sorry, I don't understand you. Can explain?

The basic idea of the attack is that if I know the password that sshd is
trying to validate, I can fake a response from the KDC which is encrypted
in the (key derived from that password) and make that response look like a
valid TGT.  In order to tell that the TGT it receives is actually from the
KDC, and not the attacker, sshd has to use that TGT to get a service
ticket it can validate (i.e., a service ticket for itself)

> > > This is issuse between PAM and ssh thread emulation.
> >
> > It does seem likely that this sort of thing would be an issue with PAM,
> > yes.  I am not particularly motivated to look into it, though.
>
> > I do recall some issue where sshd in capsicum mode was not allowed to read
> > the keytab in order to verify the supplied Kerberos credentials, which
> > required using UsePrivilegeSeparation=yes instead of the default value
> > (sandbox).  Perhaps that would affect the password mode of operation as
> > well.
>
> Currently, sshd for PAM (and kerberos PAM) fork child. Got ticket in
> this child. And try to save ticket in parent (unsuccessful, of
> course). As result -- I don't have valid ticket after ssh login.

So this is just an inconvenience, then, not a fatal flaw?  (If you're
willing to type your password at sshd, you can type it again at kinit
later.)

Anyway, this mode works in linux, so fixing it must just be a small matter
of programming.  I have too much on my plate to take it on, though.

-Ben