Incorrect inbuf parsing in reply_tcon_and_X (reply.c)

Dina Fine dina at exanet.com
Tue Jul 11 12:36:41 GMT 2006


Hi

If the security is share then the inbuf data also includes the user
password.
In this case before taking the path (service path) from inbuf, the
pointer should be increased by passlen + 1 (instead of passlen).

Usually when a domain or ads security is used the password is NULL  in
tcon request and the passlen is  1. In this case the data buffer will
start with an empty space followed by service and device type as in the
following example:
[2006/07/11 15:00:34, 5, pid=17477] lib/util.c:show_msg(464)
  size=89
  smb_com=0x75
  smb_rcls=0
  smb_reh=0
  smb_err=0
  smb_flg=8
  smb_flg2=51201
  smb_tid=0
  smb_pid=27841
  smb_uid=101
  smb_mid=4
  smt_wct=4
  smb_vwv[ 0]=  255 (0xFF)
  smb_vwv[ 1]=    0 (0x0)
  smb_vwv[ 2]=    0 (0x0)
  smb_vwv[ 3]=    1 (0x1)
  smb_bcc=46
[2006/07/11 15:00:34, 3, pid=17477] lib/util.c:dump_data(2053)
  [000] 00 5C 00 5C 00 4E 00 4F  00 44 00 45 00 30 00 2E  .\.\.N.O
.D.E.0..
  [010] 00 54 00 57 00 49 00 53  00 54 00 45 00 52 00 5C  .T.W.I.S
.T.E.R.\
  [020] 00 49 00 50 00 43 00 24  00 00 00 41 3A 00        .I.P.C.$
...A:.

But if the security is share, then the data will also include the user
password, then empty space and only then the service path as in the
following example:
[2006/07/11 14:47:42, 5, pid=1134] lib/util.c:show_msg(464)
  size=113
  smb_com=0x75
  smb_rcls=0
  smb_reh=0
  smb_err=0
  smb_flg=8
  smb_flg2=51201
  smb_tid=0
  smb_pid=27773
  smb_uid=0
  smb_mid=3
  smt_wct=4
  smb_vwv[ 0]=  255 (0xFF)
  smb_vwv[ 1]=    0 (0x0)
  smb_vwv[ 2]=    0 (0x0)
  smb_vwv[ 3]=   24 (0x18)
  smb_bcc=70
[2006/07/11 14:47:42, 3, pid=1134] lib/util.c:dump_data(2053)
  [000] 9F A8 9F 2B DE 76 82 6B  36 F2 5D A1 08 AC B6 5F  ...+.v.k
6.]...._
  [010] 38 30 DB 71 8A 2B C3 74  00 5C 00 5C 00 4E 00 4F  80.q.+.t
.\.\.N.O
  [020] 00 44 00 45 00 30 00 2E  00 54 00 57 00 49 00 53  .D.E.0..
.T.W.I.S
  [030] 00 54 00 45 00 52 00 5C  00 49 00 50 00 43 00 24  .T.E.R.\
.I.P.C.$
  [040] 00 00 00 41 3A 00                                 ...A:.

In this case since the pointer (char *p) in increased only by passlen
will point one byte before the service path, e.g.
(dumping p)
[2006/07/11 14:47:42, 3, pid=1134] lib/util.c:dump_data(2053)
  [000] 00 5C 00 5C 00 4E 00 4F  00 44 00 45 00 30 00 2E  .\.\.N.O
.D.E.0..
  [010] 00 54 00 57 00 49 00 53  00 54 00 45 00 52 00 5C  .T.W.I.S
.T.E.R.\
  [020] 00 49 00 50 00 43 00 24  00 00 00 41 3A 00 00 00  .I.P.C.$
...A:...
  [030] 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........
........
  [040] 00 00 00 00 4C 41                                 ....LA

srvstr_pull_buf will success to pull the service path, but the next pull
fails and we get empty client device type for the request.

The solution will be to increase the p pointer one more byte in case the
password is not empty.

Thanks
Dina

P.S. By the way I found this using smbtorture TCONDEV test when the
security = share and guest is allowed.





More information about the samba-technical mailing list