netbios session service

[Allen, Michael B (RSCH)]

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.

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).

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

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?

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
varify 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.

Another 2 cents,

Michael B. Allen
http://jcifs.samba.org