Duplicate SMB file_ids leading to Windows client cache poisoning

[Tom Talpey]

On 12/9/2021 3:40 PM, Andrew Walker wrote:
> 
> 
> On Thu, Dec 9, 2021 at 3:28 PM Tom Talpey via samba-technical 
> <samba-technical at lists.samba.org 
> <mailto:samba-technical at lists.samba.org>> wrote:
> 
>     On 12/9/2021 1:58 PM, Ralph Boehme wrote:
>      > Hi Tom,
>      >
>      > On 12/9/21 19:48, Tom Talpey wrote:
>      >> I really think you need a bulletproof mathematically correct
>      >> uniqueid generator here.
>      >
>      > Patches welcome. :)))
>      >
>      > I guess all we can get is an approximation.
> 
>     But, the penalty for a collision is data corruption! It's unacceptable
>     to wing it.
> 
>     Can't TDB help here? Stuff a number into the database and save it.
>     Increment it by one for each new fileid needed.
> 
>     Carve out a hundred, or a thousand, so you don't have to do a
>     transaction every new handle. Increment that by the carveout for
>     the next call. 64 bits will last you forever, so you could even
>     use it across server restart.
> 
>     Make it fancier, if monotonicity is too easily forged, or misused.
> 
>     Tom.
> 
> Tom,
> 
> I was glancing through MS-SMB and noticed that it states that file ids 
> must be unique, but may be re-used if the file is deleted. 
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/44c3cf8d-0931-4923-8fdc-738537ba70ba 

Death to SMB1. I dearly hope we're talking about SMB2/SMB3 here.

The SMB2_FILEID is a 2-part structure, 64 bits for each handle (id):
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/f1d9b40d-e335-45fc-9d0b-199a31ede4c3

SMB2 and SMB3 allow recovery of these after a disconnect, in certain
cases. So it's more complex.

> Is that not the case? Or maybe discouraged?

SMB1 loses all context on disconnect, so the fileid's are toast along
with the rest of the session state.

> Out of curiosity, why can't we use device/inode?

Device and inode simply map to the underlying file object (and they
may not be perfectly stable depending on implementation too). The
SMB2_FILEID conveys the handles which map the state of the "open";
this includes much more than the underlying file and its cached
contents.

I'm pretty sure the Windows SMB2/3 server just bumps a counter for
the volatile id's. Don't recall if or when it recycles.

Tom.