netbios session service

[Christopher R. Hertel]

On Jun 15,  6:28am, Allen, Michael B (RSCH) wrote:
> Subject: netbios session service
> About the session service bug:
>
> Regarding the confusion about session service connections to smbd by the nc
> program:
>
> Actually the netbios session service is _supposed to_ multiplex virtual
> netbios sessions over one TCP session.

Yup.  How those sessions are handled at the recieving end is an implementation
detail.

> Allllssso .... the netbios session service should keep a table of incoming
> connections
> indexed by the "calling name"(passed in the session request). A client that
> already has a connection should reuse the existing TCP session. It would
> presumably just start off with the SMB_COM_SESSION_SETUP_ANDX and could be
> issued at any time(meaning as other SMB messages transpire over a different
> virtual netbios session on the same TCP session).

If someone is just sending a stream of zeros there won't be any such commands
present.  The suggestion was made that the primary smbd do some quick triage on
packets as they arrive.

> BTW: I'm not making this up. This is part of the IETF draft specification on
> CIFS. see:
>
> http://racer-x.nts.umn.edu/jcifs/specs/draft-leach-cifs-v1-spec-02.html#s2.6
> 3

Please keep in mind that this document is a work of fiction.  It's the worst
kind of lie: a partial truth.

> So there should only be one netbios session request issued for any given
> TCP session. Although I haven't actually seen this happen. Can someone
> confirm or deny that this is the behavior? But it sounds like the parent
> smbd is just accepting a connection and then spawing a new deamon and
> passing it the socket info. Yes?

Looks like it.  Now I see where you're going with this.

> Ideally if this is to be fixed (I agree with Jerry that this is not a big
> deal though) then having the parent smbd read in the session request and
> verify it _before_ spawing a child smbd might be a good solution. This
> "generalizes the fix", as Dave put it, by requiring the attacker to provide
> a valid encoded netbios name(not easy) in the a session request and also
> brings you potentially closer to the spec in allowing you to add code to
> maintain a table of sessions and kill duplicates.
>
> Also instead of "stalling" the session is there the equevalent of a :
>
> yield_thread( current_thread )
>
> In other words put the session at the back of the "ready queue" before you
> close the socket? Then Samba will do work in the mean time before an
> attacker tries a reconnect.

Samba doesn't use any form of threading.  There is no way to guaruntee that a
given Unix flavor will support threads at all, so Samba has two options.  One
is to spawn whole processes (in which case the OS handles process state), the
other is to process packets round-robin-ish-ly.  This is what nmbd does.
 You'll note
that nmbd does spawn one child process.  This is to handle DNS lookups without
blocking processing of the other packets.

All of this is why I started jCIFS.  In Java, threads are just *there*.
 However, some Java implementations block *all* threads within a Java process
when a blocking system call is made (eg., gethostbyname()).  I have a
work-around for that, too.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services