C00000BE hack-around

[Matt Chapman]

> The cause of this problem seems to be certain unicode strings stored
> internally in byte arrays as "a\0b\0" rather than "\0a\0b", so when
> trying to be converted to ascii strings, routines like unistrn2 get
> it wrong and return "\0\0" instead of "ab".
>
> This effects api_pipe_ntlmssp_verify() where information of user, domain
> and workstation is stored in unicode, and in check_oem_password() where
> the new password is also in unicode.

Yep, a quick grep for (uint16\*) shows we've got a lot of problems:

libsmb/smbencrypt.c:            struni2( (uint16*)(&data[512 -
new_pw_len]), passwd);
rpc_parse/parse_misc.c: struni2((uint16*)str->buffer, buf);
rpc_parse/parse_reg.c:  int len = struni2((uint16*)buf, os_type);
rpc_parse/parse_rpc.c:          struni2((uint16*)rsp->domain, domain);
rpc_parse/parse_rpc.c:          struni2((uint16*)rsp->user  , user  );
rpc_parse/parse_rpc.c:          struni2((uint16*)rsp->wks   , wks   );
rpc_server/srv_pipe.c:          fstrcpy(p->user_name,
unistrn2((uint16*)p->ntlmssp_resp.user  , p->ntlmssp_resp.hdr_usr  
.str_str_len/2));
rpc_server/srv_pipe.c:          fstrcpy(p->domain   ,
unistrn2((uint16*)p->ntlmssp_resp.domain,
p->ntlmssp_resp.hdr_domain.str_str_len/2));
rpc_server/srv_pipe.c:          fstrcpy(p->wks      ,
unistrn2((uint16*)p->ntlmssp_resp.wks   , p->ntlmssp_resp.hdr_wks  
.str_str_len/2));
smbd/chgpasswd.c:               pw =
unistrn2((uint16*)(&lmdata[512-uni_pw_len]), new_pw_len);

People PLEASE don't cast between character arrays and uint16 arrays.
Types are there for a reason!

Now if can indeed receive either Unicode or ASCII in these places, we
need to either propagate a Unicode flag down into the parsing routines
and add a Unicode/ASCII union to the structures where we can receive
either, or write some more Unicode -> ASCII conversion routines which
SVAL out of a buffer.

    Matt


--
Matt Chapman
m.chapman at student.unsw.edu.au