[dina@exanet.com: Incorrect inbuf parsing in reply_tcon_and_X (reply.c)]

Jeremy Allison jra at samba.org
Tue Apr 17 02:07:56 GMT 2007


Very old post but I think relevent for 3.0.25.

Attached is my fix. I'm going to test tomorrow but if
good I'd like to add for 3.0.25rc2.

Jeremy.


----- Forwarded message from Dina Fine <dina at exanet.com> -----

From: Dina Fine <dina at exanet.com>
To: samba-technical at lists.samba.org
Subject: Incorrect inbuf parsing in reply_tcon_and_X (reply.c)

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.



----- End forwarded message -----
-------------- next part --------------
Index: smbd/reply.c
===================================================================
--- smbd/reply.c	(revision 22290)
+++ smbd/reply.c	(working copy)
@@ -468,13 +468,22 @@
  
 	if (global_encrypted_passwords_negotiated) {
 		password = data_blob(smb_buf(inbuf),passlen);
+		if (lp_security() == SEC_SHARE) {
+			/*
+			 * Security = share always has a pad byte
+			 * after the password.
+			 */
+			p = smb_buf(inbuf) + passlen + 1;
+		} else {
+			p = smb_buf(inbuf) + passlen;
+		}
 	} else {
 		password = data_blob(smb_buf(inbuf),passlen+1);
 		/* Ensure correct termination */
-		password.data[passlen]=0;    
+		password.data[passlen]=0;
+		p = smb_buf(inbuf) + passlen + 1;
 	}
 
-	p = smb_buf(inbuf) + passlen;
 	p += srvstr_pull_buf(inbuf, path, p, sizeof(path), STR_TERMINATE);
 
 	/*


More information about the samba-technical mailing list