NetShareEnum: disable sanity check for better compatibility with Windows

Sun Jan 10 06:03:50 MST 2010

Il giorno dom, 06/12/2009 alle 14.31 +0100, Giovanni Bajo ha scritto:
> 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!

Hi,

I didn't get any reply on these patches. Can somebody please have a
look?

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