svn commit: samba r4885 - in branches/SAMBA_4_0/source: include libcli libcli/nbt librpc librpc/idl librpc/ndr

[Christopher R. Hertel]

On Sat, Jan 22, 2005 at 09:11:37AM +1100, Andrew Tridgell wrote:
> Chris,
> 
>  > Again, I'm not sure how the attack you're describing works.
> 
> Imagine you have a WINS server, and clients that do predictable TRNs
> in wins lookups. Now imagine you have been a very conscientious
> administrator and used fixed names/ips in WINS to prevent WINS
> pollution attacks (or uses a dhcp->wins gateway).
> 
> An attacker would do this:
> 
>  - listen for dhcp/arp startup signatures of booting clients
>  - when it happens, predict the TRN that will be used for the initial
>    "where is my server" WINS lookup
>  - spoof a reply packet, using the WINS servers source IP, and the
>    predicted TRN id
> 
> With random TRN ids this becomes _much_ harder. Not impossible, but
> hard enough that the traffic flood will hopefully be noticed.

Floods...  You mean that the attacker would flood the wire with spoofed
responses because it wouldn't see (in a switched environment) the client's 
request?  Is that how this works?  I'm not sure why else the attacker 
would flood the wire.

Interesting.  What an odd attack!  Isn't it somewhat obscure since it is
only necessary if the NBNS won't accept Name Release Request packets?

Okay, another weird question (there's probably no reason to do things this
way but I'm interested in the theoretical issues here)... could you simply
start with a random TRN_ID?  My thinking:
  - If the attacker can see the queries then it's simply a race.  If they 
    answer first then they win.
  - If the attacker cannot see the queries then they would have to guess 
    the TRN_ID and, as you describe, flood the wire with spoofed 
    responses.

Interested...

>  > Question:  The function call you cited starts with NDR_.  How does
>  > NDR encoding relate to NBT?  Do you bypass the NDR encoding itself?
> 
> It uses "extended IDL/NDR" that pidl supports. The thing to notice is
> that NBT uses an encoding very similar to NDR, which is why its so
> easy.

Ah.  That's something I didn't know.  Kewl.  :)

> Before someone asks, the situation is quite different for the SMB
> protocol. Most of that is too irregular to be done as IDL/NDR (at
> least while keeping the IDL reasonably sane).

Is it irregular or just "different"?  That is, could another encoding be
specified (somehow) that would work?  What kinds of extensions would be 
required in order to accommodate some of the weirdities we know we'd face.

Yes, I am aware of the kinds of problems you're talking about.  Pad bytes 
in odd locations, etc.  Just curious about the possibilities.

The place to start, I suppose, would be to write some IDL for SMBs and 
(aside from the NDR encoding issue) see where we run into roadblocks.

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org