NetShareEnum: disable sanity check for better compatibility with Windows

Sun Dec 6 06:31:13 MST 2009

Il giorno dom, 29/11/2009 alle 14.46 +0100, Volker Lendecke ha scritto:
> On Sun, Nov 29, 2009 at 02:15:18PM +0100, Giovanni Bajo wrote:
> > the attached patches increase Samba compatibility with Windows by
> > disabling a sanity check which prevents Samba from issuing an answer to
> > a NetShareEnum request in case of a corrupted (invalid) packet.
> > 
> > Long version. I have recently bought a Samsung BD-P3600 bluray player.
> > This unit has wired/wifi connection and a primitive/buggy support for
> > streaming files off Windows shares. It works well if the shares are on a
> > Windows PC, but it fails to detect shares on Linux and Mac OSX. I
> > investigated the problem and it turns out that the bluray player sends
> > an invalid packet:
> > 
> > 0000  00 1b fc 91 80 08 00 12  fb 2a d9 7c 08 00 45 00   ........ .*.|..E.
> > 0010  00 9e b8 2e 40 00 40 06  fe c2 c0 a8 01 17 c0 a8   .... at .@. ........
> > 0020  01 01 cc 54 00 8b 46 cc  34 d6 de 00 9f ae 80 18   ...T..F. 4.......
> > 0030  0b 68 01 e3 00 00 01 01  08 0a 00 00 99 c7 00 64   .h...... .......d
> > 0040  41 2d 00 00 00 66 ff 53  4d 42 25 00 00 00 00 08   A-...f.S MB%.....
> > 0050  01 00 00 00 00 00 00 00  00 00 00 00 00 00 01 00   ........ ........
> > 0060  3b 00 00 00 9f 00 0e 1a  00 00 00 63 00 ff ff 00   ;....... ...c....
> > 0070  00 00 00 00 00 00 00 00  00 1a 00 4c 00 00 00 66   ........ ...L...f
> > 0080  00 00 00 27 00 5c 50 49  50 45 5c 4c 41 4e 4d 41   ...'.\PI PE\LANMA
> > 0090  4e 00 00 00 57 72 4c 65  68 00 42 31 33 42 57 7a   N...WrLe h.B13BWz
> > 00a0  57 57 57 7a 42 39 42 00  01 00 ff ff               WWWzB9B. ....
> > 
> > Microsoft Windows Lanman Remote API Protocol
> >   Function Code: NetShareEnum (0)
> >   Parameter Descriptor: WrLeh
> >   Return Descriptor: B13BWzWWWzB9B
> >   Detail Level: 1
> >   Receive Buffer Length: 65535
> > 
> > This packet is malformed because, for level 1 query, the correct return
> > descriptor would be "B13BWz". I've attached the full wireshark dump, in
> > case it matters.
> > 
> > What happens is that Samba refuses to answer to this query because it
> > fails an internal sanity check; instead, Windows happily answers and the
> > conversation goes on.
> > 
> > I verified my fix against a samba2 server (this is what I'm running on
> > my DDWRT-based router), and forward-ported the same patch on samba3 and
> > samba4 trees by visual inspection.
> > 
> > This is my first contribution to Samba, so I'm looking for some guidance
> > for this patch to be accepted.
> 
> It seems that the descriptor they send is actually a level2
> descriptor. Can you get us a trace against a Windows box? I
> would be interested to see what they return in this case. Do
> they decide based upon the level or the descriptor?

Hi Volker,

sorry for the late reply. This is the packet returned by a Windows box
when queried with the malformed LANMAN request quoted above:

0000  00 12 fb 2a d9 7c 00 21  63 fe 8e 85 08 00 45 00   ...*.|.! c.....E.
0010  01 19 18 e5 40 00 80 06  5c b6 c0 a8 01 dc c0 a8   .... at ... \.......
0020  01 17 00 8b d9 da a3 31  12 99 e1 d2 01 fa 80 18   .......1 ........
0030  8d f8 d0 62 00 00 01 01  08 0a 00 01 bf b5 00 04   ...b.... ........
0040  86 ff 00 00 00 e1 ff 53  4d 42 25 00 00 00 00 88   .......S MB%.....
0050  01 00 00 00 00 00 00 00  00 00 00 00 00 00 01 08   ........ ........
0060  3b 00 02 08 9f 00 0a 08  00 a1 00 00 00 08 00 38   ;....... .......8
0070  00 00 00 a1 00 40 00 00  00 00 00 aa 00 00 00 00   ..... at .. ........
0080  5e ff 05 00 05 00 49 50  43 24 00 00 00 00 00 00   ^.....IP C$......
0090  00 00 00 00 03 00 f4 ff  00 00 44 4f 57 4e 00 00   ........ ..DOWN..
00a0  00 00 00 00 00 00 00 00  00 00 f3 ff 00 00 44 6f   ........ ......Do
00b0  77 6e 6c 6f 61 64 00 00  00 00 00 00 00 00 f2 ff   wnload.. ........
00c0  00 00 41 44 4d 49 4e 24  00 00 00 00 00 00 00 00   ..ADMIN$ ........
00d0  00 00 db ff 00 00 43 24  00 00 00 00 00 00 00 00   ......C$ ........
00e0  00 00 00 00 00 00 c2 ff  00 00 43 6f 6e 64 69 76   ........ ..Condiv
00f0  69 73 69 6f 6e 65 20 70  72 65 64 65 66 69 6e 69   isione p redefini
0100  74 61 00 41 6d 6d 69 6e  69 73 74 72 61 7a 69 6f   ta.Ammin istrazio
0110  6e 65 20 72 65 6d 6f 74  61 00 00 00 49 50 43 20   ne remot a...IPC 
0120  72 65 6d 6f 74 6f 00                               remoto. 

Wireshark decodes it as "NetShareEnum Response[malformed packet]". It
obviously is a level-1 answer (you can see that there are exactly 18
bytes between "IPC$" and "DOWN"). Wireshark tries to decoded it at
level-2 and fails.

So what happens is that Windows ignores the descriptor and trusts the
level. On the other hand, Wireshark seems to trust the descriptor more
and thus fails to decode the packet. In fact, it does not even mark the
query packet as malformed, though it obviously doesn't match the
specifications.

> And, would it be possible not to completely drop the check
> but to also allow the level2 descriptor for level1?

Sure, see the attached patch. I would say that my experiment proves that
the descriptor is ignored by Windows (at least for the NetShareEnum
query) and thus it is better to drop the check altogether, but anyway.

BTW, compared to last week, I have now also verified the fix against a
patched Samba3 server (previously, I had tested it on Samba2 only).

Thanks!
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: netshareenum.2.patch
Type: text/x-patch
Size: 1019 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20091206/85078a2e/attachment.bin>