Re: [PATCH 6/7] cifs.upcall: use ip address passed by kernel to get server's hostname

On Sun, 16 Aug 2009 23:52:46 +0400
"Q (Igor Mammedov)" <[email protected]> wrote:
> 
> I'll try explain more clearly, what I've meant.
> 
> Providing that we could have compromised dns resolving, we could not
> trust forward nor reverse resolution, but the goal of attacker is in
> redirecting us his server.
> Case 1: using host name  A.B.C supplied at mount time
>    1.1 we have an IP of a  fake server because forward resolution was spoofed
>    1.2 we get a valid session key from KDC for A.B.C
>    Result: we can detect that packets a coming from a fake server, because
>   of an incorrect signature.
> 
> Case 2: using host name F.A.K.E from revers resolution
>    2.1 the same attack vector 1.1,  i.e. connect to a fake server's
> IP, and doing
>          revers resolution we are getting host name of a fake server.
>   2.2 we get a valid session key from KDC for F.A.K.E because of fake server
>         is a member of our domain.
>   Result: attacker forced us to use his server, nobody will even notice it.
> 
> I prefer using 'case 1' for my files. And if cifs is fixed to drop a session
> to a fake server, I will like it even more.
> 
> Case 2 are safe only in a hardened  network environment or with a secure
> dns setup.
> 

Ok, that makes sense. The attack vector is a little contrived, but I'm
ok with preventing it. Still though, the fact that you need prior
knowledge of what the host portion of the service principal should be
is terribly problematic.

Perhaps we should consider a "--trust-dns" flag or something that
allows people to enable using reverse resolves?

Any thoughts on other ways to prevent the problem where the hostname
needed isn't known?

> > There's a huge problem with the current scheme however. You need to
> > know the canonical name of the host in the service ticket and then
> > mount that. This is a huge source of confusion for users. Suppose I
> > have a host:
> >
> >        server.example.com
> >
> > ...and I have a principal that I need to get in order to mount it:
> >
> >        cifs/[email protected]
> >
> > ...now, suppose I try to mount up a share from that host, but use a
> > non-canonical hostname in the server section of the UNC:
> >
> >        //server/share
> >
> > ...it doesn't work. The upcall will try to assemble a principal name
> > like:
> >
> >        cifs/[email protected]
> 
> I haven't noticed this case because in AD domain, a machine
> account is registered with a fqdn and a hostname principals.
> (At least it is so in my company)
> So I were able to connect to //server/share
> 
> > ...similar problem if I try to mount a CNAME for the server. This is
> > also a problem when you want to mix krb5 and DFS. I don't believe the
> > current code sets the hostname.
> 
> The same thing, I someone wishes to provide access to a server via
> CNAMEs, he/she should create corresponding principals on KDC.
> This way it will not reduce security.
> 

The problem here is that it's not necessarily evident *why* the mount
is failing at this point. If there were a way to spew a printk or log
message that makes this evident then I'd be more conducive to it.

> >
> > I don't think so. The patch below also changes:
> >
> > #define DKD_MUSTHAVE_SET (DKD_HAVE_IP|DKD_HAVE_VERSION|DKD_HAVE_SEC)
> >
> > ...or am I missing something?
> 
> It just caught my eyes.
> Anyway I would initialized it, just in case.
> 

Yeah, defensive coding doesn't hurt. I'll plan to initialize that once we
come to consensus on what to do about the other problem.

-- 
Jeff Layton <[email protected]>