Smb2-protocol: [Smb2-protocol] FIDs
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
Date: Wed, 7 Dec 2005 21:19:18 +0000
Metze, Re your findings about the "weird" scoping of FIDs. It appears from your findings that a FID is scoped not by a Tree but by Server. That once you aquire a FID you can issue comnmands to access that FID through ANY tree you have mounted form the server? This raises some itneresting questions about the FID (bear with me while i extrapolate from NFS filehandles below). 1, If you aquire a FID to a file to one client, can you use that FID to access the file also across the IPC$ tree? (does the FID have to be present on the same filesystem as the TID or not?) ((in nfs you can do this)) 2, If you have two clients A and B and both have mapped the same share, If A aquires a FID (and keeps the file open), can B access the file be using the same FID that A got? I.e. Can B start doing I/O to the file based solely on the knowledge about a specific FID but without actually opening the file? ((in nfs you can do this)) 3, Does the authorization checks follow the FID or the session? If you have mapped the share twice, once by a normal user "test" and once by "Administrator", If then you create a file "foo" by administrator and assign it an ACL that only allows Administrator access and no one else, what happens if you copy that FID over to the "test" user (which should not have access to that file) and try to do I/O? ((this works in nfs, in nfs all security is performaed inside the LOOKUP call used to "discover" filehandles. If you as a user have alternative means to "discover" a filehandle wihtout using LOOKUP (or Create in SMB2) tyhen you have bypassed all security and can access any file)) (((if this is the case it would be an interesting attack vector))) Another thing is the content of the FID, it is definitely not a random blob like GUIDs are normally. Instead it appears to consist of 4 32 bit integers of which the last one is always (?) 0xffffffff. I.e. there is some structure imposed on the FID by the server. This is also something NFS servers always do. I would not be surprised if one would find that the first 12 bytes of the FID contain things such as 1, Filesystem/Volume ID number 2, Inode number 3, A generation number/counter that increments by one for each Create. If then the FID describes the filesystem/inode etc of the file what then about the last 4 bytes? Hmmm. Can you create a capture containing applications opening an AlternateDataStream and reading and an application that opens an old version (using whatever api they offer for reading old versions) of the file and read? Those four last bytes could be 0xffffffff meaning the file itself or something else depending on if it is an ADS or an old version that is opened.
- Follow-Ups:
- Re: [Smb2-protocol] FIDs
- From: Stefan (metze) Metzmacher
- Re: [Smb2-protocol] FIDs
- Prev by Date: Re: [Smb2-protocol] Re: TID's are per UID
- Next by Date: Re: [Smb2-protocol] FIDs
- Previous by thread: [Smb2-protocol] Re: TID's are per UID
- Next by thread: Re: [Smb2-protocol] FIDs
- Index(es):
- Get Wireshark
- Download
- Code of Conduct