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 07:58:48AM +1100, Andrew Tridgell wrote:
:
>  > - I'm a big fan of randomizing packet IDs, but I can't think of a good
>  >   reason to do so for NBT TRNs since (as far as I know) there's nothing
>  >   that makes use of packet sequence.  What is gained?
> 
> Nothing makes use of them? The name_trn_id is the key to matching
> response records to queries.

No, you misread my question...  The TRN numbers, yes.  Those are used.  
It's the *sequence* I'm asking about.  I cannot think of anything within
the protocol that relies on the sequencing of the packets.  That it, it
doesn't matter (to NBT) if you use randomly generated TRNs or not.

That being the case (unless I'm wrong) I'm trying to understand what the 
actual advantage is of using random numbers.

I did write testing code a while back that used random numbers (and a 
simple table to receive replies and avoid duplicates).  I couldn't figure 
a reason that random numbers were a benefit.

> The idtree code plus random() is ideal for this. Using idtree means
> that even if we have 20 thousand outstanding packets we still only
> take a instructions to find the matching record (no more linear linked
> lists for response records!).

I always meant to make that a splay tree.  :)

...but yes, that's the kind of thing I wrote for testing when I was doing 
my book.  Wonder where that code is now...

> It also makes name takeover attacks on switched networks that use wins
> much harder, as the attacker needs to send a huge number of packets to
> have a good chance of getting a hit.

How does that attack work?

This is what I was asking about, actually.  I wanted to know what the
advantage of randomization was.  As I understand it, this sort of takeover
attack can work if the attacker is simply faster at responding to a query
than the real owner of the name.

Let's see...  Were I to try such a thing:

Option 1:  In B mode, just answer the query first (and/or send a NAME
           CONFLICT DEMAND or NAME RELEASE DEMAND and hope that the real 
           owner will quietly sulk in the corner).

Option 2:  In P mode, send a registratration request to the NBNS.  It 
           will, most likely, query the real owner.  The evildoer's 
           options are to:
           - send the Name Conflict or Name Release Demand messages to
             the real owner, hoping to convince it that it has lost 
             ownership of the name (some Windows boxes accept these 
             messages).
           - spoof a name release request, then register the name.
           - send a Negative response to the NBNS, spoofing the real owner
             and hoping that the spoofed response will arive first.  In 
             this case, you'd have to know the TRN_ID of the query and 
             yes, you could gain a few ms if you could predict the TRN_ID.
             (Particularly helpful if you're not on the same subnet.)

So, of the attacks of which I am aware, that last one (the most difficult) 
is the only one in which I see an advantage to random TRN_ID's.

...so I'm probably missing something.  :)

> That makes it more likely the
> attack will be noticed. You can't make nbt completely secure, but this
> is about as close as you can get.

Again, I'm not sure how the attack you're describing works.

> that tiny bit of code generates the following debug log.
> 
> Received nbt packet of length 62 from 192.168.115.5:137
>     packet: struct nbt_name_packet
:
:
:

Right... but the testing code I've got in my library does the same thing
(well, something very similar).  I showed it to you two CIFS conferences
ago.  :)

Still, mine isn't auto-generated.  I hand-tooled it and it would need a 
little work to be as generic as the IDL/NDR decoding.

Question:  The function call you cited starts with NDR_.  How does
NDR encoding relate to NBT?  Do you bypass the NDR encoding itself?

> It's like having a little packet analyser built in, and makes
> debugging difficult problems _much_ easier. It all comes for free with
> pidl :-)

All good things.  As I tried to explain to Mr. Bartlett, I'm only trying 
to wrap my brain around it.

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