netdev - RE: [PATCH main 1/1] macsec: Fix Macsec replay protection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <IA1PR12MB63532F95E8921422D982220CABFF9@IA1PR12MB6353.namprd12.prod.outlook.com>
Date:   Tue, 10 Jan 2023 13:38:48 +0000
From:   Emeel Hakim <ehakim@...dia.com>
To:     Sabrina Dubroca <sd@...asysnail.net>
CC:     "dsahern@...nel.org" <dsahern@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Raed Salem <raeds@...dia.com>
Subject: RE: [PATCH main 1/1] macsec: Fix Macsec replay protection



> -----Original Message-----
> From: Sabrina Dubroca <sd@...asysnail.net>
> Sent: Tuesday, 10 January 2023 14:03
> To: Emeel Hakim <ehakim@...dia.com>
> Cc: dsahern@...nel.org; netdev@...r.kernel.org; Raed Salem
> <raeds@...dia.com>
> Subject: Re: [PATCH main 1/1] macsec: Fix Macsec replay protection
> 
> External email: Use caution opening links or attachments
> 
> 
> 2023-01-10, 11:23:26 +0000, Emeel Hakim wrote:
> >
> >
> > > -----Original Message-----
> > > From: Sabrina Dubroca <sd@...asysnail.net>
> > > Sent: Tuesday, 10 January 2023 12:02
> > > To: Emeel Hakim <ehakim@...dia.com>
> > > Cc: dsahern@...nel.org; netdev@...r.kernel.org; Raed Salem
> > > <raeds@...dia.com>
> > > Subject: Re: [PATCH main 1/1] macsec: Fix Macsec replay protection
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > 2023-01-10, 10:02:19 +0200, ehakim@...dia.com wrote:
> > > > @@ -1516,7 +1515,7 @@ static int macsec_parse_opt(struct link_util
> > > > *lu, int
> > > argc, char **argv,
> > > >               addattr_l(n, MACSEC_BUFLEN, IFLA_MACSEC_ICV_LEN,
> > > >                         &cipher.icv_len, sizeof(cipher.icv_len));
> > > >
> > > > -     if (replay_protect != -1) {
> > > > +     if (replay_protect) {
> > >
> > > This will silently break disabling replay protection on an existing device. This:
> > >
> >
> > Thanks for catching that.
> >
> > >     ip link set macsec0 type macsec replay off
> > >
> > > would now appear to succeed but will not do anything. That's why I
> > > used an int with
> > > -1 in iproute, and a U8 netlink attribute rather a flag.
> > >
> > > I think this would be a better fix:
> > >
> > >         if (replay_protect != -1) {
> > > -               addattr32(n, MACSEC_BUFLEN, IFLA_MACSEC_WINDOW, window);
> > > +               if (replay_protect)
> > > +                       addattr32(n, MACSEC_BUFLEN,
> > > + IFLA_MACSEC_WINDOW, window);
> > >                 addattr8(n, MACSEC_BUFLEN, IFLA_MACSEC_REPLAY_PROTECT,
> > >                          replay_protect);
> > >         }
> > >
> > > Does that work for all your test cases?
> >
> > The main test case works however I wonder if it should be allowed to
> > pass a window with replay off for example:
> > ip link set macsec0 type macsec replay off window 32
> >
> > because now this will silently ignore the window attribute
> >
> > a possible scenario:
> > we start with a macsec device with replay enabled and window set to 64
> > now we perform:
> > ip link set macsec0 type macsec replay off window 32 ip link set
> > macsec0 type macsec replay on
> >
> > we expect to move to a 32-bit window but we silently failed to do so.
> >
> > what do you think?
> 
> The kernel currently doesn't allow that. From macsec_validate_attr:
> 
>         if ((data[IFLA_MACSEC_REPLAY_PROTECT] &&
>              nla_get_u8(data[IFLA_MACSEC_REPLAY_PROTECT])) &&
>             !data[IFLA_MACSEC_WINDOW])
>                 return -EINVAL;
> 
> So we can set the size of the replay window, but it's ignored and will be overwritten
> when we enable replay protection.
> 
> We could check for window != -1 instead of replay_protect before adding
> IFLA_MACSEC_WINDOW, and I think that should take care of both cases.

Ack, the initial proposed fix is good enough since we can't re-set replay to on without
providing a window, we will fall on the test:

else if (window == -1 && replay_protect == 1) { 
                fprintf(stderr,
                        "replay protection enabled, but no window set. did you mean 'replay on window VALUE'?\n");
                return -1;
}

I will send a V2 with the proposed fix.

> >
> > >
> > > >               addattr32(n, MACSEC_BUFLEN, IFLA_MACSEC_WINDOW, window);
> > > >               addattr8(n, MACSEC_BUFLEN, IFLA_MACSEC_REPLAY_PROTECT,
> > > >                        replay_protect);
> > >
> > > --
> > > Sabrina
> >
> 
> --
> Sabrina