Jeffrey Altman wrote:
Jason Edgecombe wrote:
Ok, so the summary is that any file copied out of /afs while not
authenticated (system:anyuser) can be spoofed. If this correct?
The issue is subtly different. It is not which credentials you have
when copying the data out of the cache, the issue is which credentials
were used when the data was copied into the cache. That is why
performing the "fs flush" before reading data as an authenticated user
ensures that you will get the correct information when fs crypt is on.
This sounds something like dns cache poisoning, only the AFS cache is
being poisoned.
Ok, so local access is required for OPENAFS-SA-2007-001 to be exploited?
Can a non-root user exploit it?
Can this be done from a machine other than the client or server?
In theory yes. AFS is a network protocol. If you can place a machine
in between the cache manager and the file server and were able to
modify the existing traffic or pretend to be the file server, then
you could poison the contents of the cache.
This is no different than what could be done to any other network
protocol that does not provide for authentication and protection
against data modification.
Most widely deployed file systems have exactly the same issues.
However, this is not the issue that is addressed by the OPENAFS-SA-2007-001.
ok.
Can I run fs setcell in a startup script to get the same effect as
upgrading the client?
OPENAFS-SA-2007-001 can be addressed by issuing
fs setcell <cell> -nosuid
Cool.
Jason
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
