[jcifs] Domain Corruption Quantified (Win98/ME non-compliance with CIFS std)

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Matthew Tippett [SMTP:matthew.tippett at sympatico.ca]
> Sent:	Tuesday, December 03, 2002 8:23 AM
> To:	jcifs at lists.samba.org
> Subject:	Re: [jcifs] Domain Corruption Quantified (Win98/ME non-compliance with CIFS std)
> 
> 
> 
> Allen, Michael B (RSCH) wrot
> > 
> > When the next request comes along, the buffer already has some extra 
> > data placed into it and so when it parses the data, it puts 'crap' in 
> > the URL field.
> > 
> > 
> > 	Do you mean a domain in the domain enum response is not properly null
> > 	terminated? I'm not sure I understand. What field of what response exacty? Is
> > 	it the name member in the ServerInfo1 structure of NetServerEnum2 response
> > 	that's not null terminated property? Can you get a -Dlog=ALL if ethereal is not
> > 	picking this up properly?
> > 
> > 
> 
> No, the Negotiate response.
> 
> If you look at the capture in cifs-winme.pcap you can see that in the 
> negotiate response there is simply no domain.  If you capture a response 
> from a later version of windows, there is the domain (as per the CIFS 
> standard).
> 
> The NetServerEnum2 request was more of a distraction as it turned out, 
> the damage had already been done by the Negotiate.
> 
> With that extra bit of information, the rest of my previous email 
> remains true.
> 
	I see. This is actually just a bug in jCIFS. If the byteCount is not greater than
	the 8 byte challenge then we should not try and decode a domain name. This
	is easily fixed by throwing an if( byteCount > encryptionKeyLength ) ... else
	oemDomainName = new String() around that domain name decoder in
	readBytesWireFormat of SmbComNegotiateResponse. The question is -- what
	will happen when we pass "" as the domain name in the NetSeverEnum2? Can
	you try it?

	  http://users.erols.com/jcifs/jcifs-0.7.0b9dom.jar