On Mon, Nov 01, 2021 at 10:37:11AM -0700, dai.ngo@xxxxxxxxxx wrote: > > On 10/21/21 11:34 PM, dai.ngo@xxxxxxxxxx wrote: > >On 10/21/21 7:02 AM, Bruce Fields wrote: > >>On Wed, Oct 20, 2021 at 10:00:41PM -0700, dai.ngo@xxxxxxxxxx wrote: > >>>The attack can come from the replies of the source server or requests > >>>from the source server to the destination server via the back channel. > >>>One of possible attack in the reply is BAD_STATEID which was handled > >>>by the client code as mentioned by Olga. > >>> > >>>Here is the list of NFS requests made from the destination to the > >>>source server: > >>> > >>> EXCHANGE_ID > >>> CREATE_SESSION > >>> RECLAIM_COMLETE > >>> SEQUENCE > >>> PUTROOTFH > >>> PUTHF > >>> GETFH > >>> GETATTR > >>> READ/READ_PLUS > >>> DESTROY_SESSION > >>> DESTROY_CLIENTID > >>> > >>>Do you think we should review all replies from these requests to make > >>>sure error replies do not cause problems for the destination server? > >>That's the exactly the sort of analysis I was curious to see, yes. > > > >I will go through these requests to see if is there is anything that > >we need to do to ensure the destination does not react negatively > >on the replies. > > still need to be done. > > > > >> > >>(I doubt the PUTROOTFH, PUTFH, GETFH, and GETATTR are really necessary, > >>I wonder if there's any way we could just bypass them in our case. I > >>don't know, maybe that's more trouble than it's worth.) > > > >I'll take a look but I think we should avoid modifying the client > >code if possible. > > > >> > >>>same for the back channel ops: > >>> > >>> OP_CB_GETATTR > >>> OP_CB_RECALL > >>> OP_CB_LAYOUTRECALL > >>> OP_CB_NOTIFY > >>> OP_CB_PUSH_DELEG > >>> OP_CB_RECALL_ANY > >>> OP_CB_RECALLABLE_OBJ_AVAIL > >>> OP_CB_RECALL_SLOT > >>> OP_CB_SEQUENCE > >>> OP_CB_WANTS_CANCELLED > >>> OP_CB_NOTIFY_LOCK > >>> OP_CB_NOTIFY_DEVICEID > >>> OP_CB_OFFLOAD > >>There shouldn't be any need for callbacks at all. We might be able to > >>get away without even setting up a backchannel. But, yes, if the server > >>tries to send one anyway, it'd be good to know we do something > >>reasonable. > > > >or do not specify the back channel when creating the session somehow. > >I will report back. > > We can not disable the back channel of the SSC v4.2 mount since it might > share the same connection with a regular NFSv4.2 mount from the destination > to the source server. Hm. Well, now that I think of it, a backchannel is probably required for the SSC case anyway. (I think CB_RECALL_SLOT is mandatory to support?) --b.
