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.
